diff --git a/website/.validationignore b/website/.validationignore index ae5520f2f..3429ca7e2 100644 --- a/website/.validationignore +++ b/website/.validationignore @@ -84,14 +84,6 @@ /docs/requests.mdx /docs/service/status.mdx /docs/subscription-plan-limits.mdx -/docs/targeting/feature-flag-evaluation.mdx -/docs/targeting/percentage-options.mdx -/docs/targeting/targeting-overview.mdx -/docs/targeting/targeting-rule/flag-condition.mdx -/docs/targeting/targeting-rule/segment-condition.mdx -/docs/targeting/targeting-rule/targeting-rule-overview.mdx -/docs/targeting/targeting-rule/user-condition.mdx -/docs/targeting/user-object.mdx /api/**/*.mdx /versioned_docs/**/*.mdx \ No newline at end of file diff --git a/website/docs/targeting/feature-flag-evaluation.mdx b/website/docs/targeting/feature-flag-evaluation.mdx index c6433e667..a336b7a6a 100644 --- a/website/docs/targeting/feature-flag-evaluation.mdx +++ b/website/docs/targeting/feature-flag-evaluation.mdx @@ -6,7 +6,7 @@ description: This document offers an in-depth explanation of how the ConfigCat S # Feature Flag Evaluation -This document offers an in-depth explanation of how the SDK determines the value of a feature flag when executing the `GetValue` function. Understanding this process requires prior knowledge of targeting concepts. +This document offers an in-depth explanation of how the SDK determines the value of a feature flag when executing the `GetValue` function. Understanding this process requires prior knowledge of [targeting concepts](../targeting-overview). The feature flag's value is determined by: @@ -17,9 +17,9 @@ The feature flag's value is determined by: The feature flag's value always comes from exactly one rule, following this algorithm: 1. **Evaluation of Targeting Rules:** If Targeting Rules are present, the SDK evaluates them one by one, from top to bottom. It checks if all the conditions in the rule's IF part are met (i.e. all the conditions evaluate to true). - - If the conditions are met, the THEN part determines the value to return. Note: If the THEN part contains Percentage Options but the [Percentage Evaluation Attribute](../percentage-options#percentage-evaluation-attribute) is missing, the SDK will skip the Targeting Rule and continue with the next rule - even though the Targeting Rule's conditions are met! + - If the conditions are met, the THEN part determines the value to return. However, if the THEN part contains Percentage Options but the [Percentage Evaluation Attribute](../percentage-options#percentage-evaluation-attribute) is missing from the User Object, the SDK will skip the Targeting Rule and continue with the next rule - even though the Targeting Rule's conditions are met! - If the conditions aren't met, the SDK moves to the next Targeting Rule, or to step 2 (below) if there are no more Targeting Rules. -2. **Evaluation of Percentage Options:** If a *Percentage Options* rule exists, the SDK executes the [Evaluation of Percentage Options](#evaluation-of-percentage-options) algorithm to determine which Percentage Option applies to the user and returns the value associated with that option. If the necessary user attribute is missing, the SDK skips to step 3 (below). +2. **Evaluation of Percentage Options:** If a *Percentage Options* rule exists, the SDK executes the [Evaluation of Percentage Options](#evaluation-of-percentage-options) algorithm to determine which Percentage Option applies to the user and returns the value associated with that option. If the [Percentage Evaluation Attribute](../percentage-options#percentage-evaluation-attribute) is missing from the User Object, the SDK skips to step 3 (below). 3. **Returning simple value:** At this stage, the only remaining "rule" is the simple value specified at the end of the feature flag, which the SDK then returns. In the event of an unexpected error during evaluation, the SDK returns the [default value](../targeting-overview#default-value) passed to the `GetValue` function. @@ -46,80 +46,84 @@ In case the prerequisite flag is missing or there is a type mismatch between the ### Evaluation of a Segment Condition -The SDK looks up the segment referenced by the condition and evaluates the condition described by the segment similarly to [User Conditions](../targeting-rule/user-condition). Then, the result is checked against the comparator. In the case of `IS IN SEGMENT` the result of the Segment Condition will be the same as the result of the segment. The result will be negated in the case of `IS NOT IN SEGMENT`. +The SDK looks up the segment referenced by the condition and evaluates the condition described by the segment similarly to [User Conditions](../targeting-rule/user-condition). Then, the result is checked against the comparator. In the case of **IS IN SEGMENT**, the result of the Segment Condition will be the same as the result of the segment. In the case of **IS NOT IN SEGMENT**, the result will be negated. -If the segment evaluates to `cannot evaluate`, so is the Segment Condition. +If the segment evaluates to `cannot evaluate`, so does the Segment Condition. The evaluation process stops if the referenced segment is missing, and the SDK will return the [default value](../targeting-overview#default-value). (Though this can happen only when using the [flag overrides](../../sdk-reference/js#flag-overrides) feature with invalid data.) ## Evaluation of Percentage Options -[Percentage Options](../percentage-options) are designed to be consistent and sticky across all SDKs, which means that users with the same attributes fall in the same group and get the same feature flag value across the supported platforms. +[Percentage Options](../percentage-options) are designed to be *consistent* and *sticky* across all SDKs, which means that users with the same attributes fall in the same group and get the same feature flag value across the supported platforms as long as the percentage split is the same. The SDK looks up the [Percentage Evaluation Attribute](../percentage-options#percentage-evaluation-attribute) in the [User Object](../user-object), then: -- The SDK creates a hash from the combination of the Percentage Evaluation Attribute's value and the specific feature flag's key. +- The SDK creates a hash from the combination of the specific feature flag's key and the Percentage Evaluation Attribute's value. - The hashing algorithm assigns the user a number between 0 and 99. - The assigned number determines which group the user falls into, i.e. which Percentage Option applies to the user. The fact that the above algorithm is implemented across all SDKs guarantees [stickiness](../percentage-options#stickiness) and [consistency](../percentage-options#consistency). -By hashing the combination of the user attribute and the feature flag's key, we ensure diverse user groups for different feature flags. In other words, the algorithm prevents the same users from being assigned to the same Percentage Options for different feature flags. +By hashing the combination of the feature flag's key and the user attribute, we ensure diverse user groups for different feature flags. In other words, the algorithm prevents the same users from being assigned to the same Percentage Options for different feature flags. :::info The evaluation process is entirely implemented within the SDKs, meaning your users' sensitive data never leaves your system. The data flow is one-way – from ConfigCat CDN servers to your SDKs – and ConfigCat does not receive or store any attributes of the [User Object](../user-object) passed to the SDKs. This design prioritizes the privacy and security of user data. ::: -### Example Scenarios for Percentage Options +### Example scenarios for Percentage Options -Imagine you have two users, Jane and Joe, and you're experimenting with two different feature flags (`isTwitterSharingEnabled` and `isFacebookSharingEnabled`) that use percentage-based targeting. In these scenarios, we see how Percentage Options allow for a controlled and gradual rollout of features, ensuring a smooth transition for users like Jane and Joe. +Imagine you have two users, Jane and Joe, and you're experimenting with two different feature flags (**isTwitterSharingEnabled** and **isFacebookSharingEnabled**) that use percentage-based targeting. In these scenarios, we see how Percentage Options allow for a controlled and gradual rollout of features, ensuring a smooth transition for users like Jane and Joe. -First, the users are assigned a number between 0-99 based on the hash of their identifier and the feature flag's key. This number determines their eligibility for a feature based on the Percentage Options set on the Dashboard. +First, the users are assigned a number between 0 and 99 based on the hash of the feature flag's key and their identifier. According to the Percentage Options specified on the Dashboard, this number determines which group they are assigned to, i.e. whether or not the feature is enabled for them. + +Let's assume the hash algorithm produces the following numbers: | | isTwitterSharingEnabled | isFacebookSharingEnabled | | ---- | ------------------------------------------------------------------------- | --------------------------------------------------------------------------- | -| Jane | `hash('Jane' + 'isTwitterSharingEnabled') mod 100`
Results in **8** | `hash('Jane' + 'isFacebookSharingEnabled') mod 100`
Results in **64** | -| Joe | `hash('Joe' + 'isTwitterSharingEnabled') mod 100`
Results in **32** | `hash('Joe' + 'isFacebookSharingEnabled') mod 100`
Results in **12** | +| Jane | `hash('isTwitterSharingEnabled' + 'Jane') mod 100`
results in **8** | `hash('isFacebookSharingEnabled' + 'Jane') mod 100`
results in **64** | +| Joe | `hash('isTwitterSharingEnabled' + 'Joe') mod 100`
results in **32** | `hash(isFacebookSharingEnabled' + 'Joe') mod 100`
results in **12** | -1. **Initial Setup: 0% ON / 100% OFF** +1\. **Initial Setup: 0% ON / 100% OFF** | | isTwitterSharingEnabled
0% ON / 100% OFF | isFacebookSharingEnabled
0% ON / 100% OFF | | ---- | ---------------------------------------------- | ----------------------------------------------- | -| Jane | 8 >= 0
-> **OFF** | 64 >= 0
-> **OFF** | -| Joe | 32 >= 0
-> **OFF** | 12 >= 0
-> **OFF** | +| Jane | 8 >= 0
→ **OFF** | 64 >= 0
→ **OFF** | +| Joe | 32 >= 0
→ **OFF** | 12 >= 0
→ **OFF** | -2. **Adjustment to 10% ON / 90% OFF** +2\. **Adjustment to 10% ON / 90% OFF** In this case both feature flags are enabled for only 10% of users. | | isTwitterSharingEnabled
10% ON / 90% OFF | isFacebookSharingEnabled
10% ON / 90% OFF | | ---- | ---------------------------------------------- | ----------------------------------------------- | -| Jane | 8 < 10
-> **ON** | 64 >= 10
-> **OFF** | -| Joe | 32 >= 10
-> **OFF** | 12 >= 10
-> **OFF** | +| Jane | 8 < 10
→ **ON** | 64 >= 10
→ **OFF** | +| Joe | 32 >= 10
→ **OFF** | 12 >= 10
→ **OFF** | :::info -Despite both feature flags being set to 10% ON / 90% OFF, the `isTwitterSharingEnabled` feature flag is only enabled for Jane. Because Jane and Joe have different identifiers, they're assigned different numbers, determining their eligibility for each feature. +Despite both feature flags being set to 10% ON / 90% OFF, the **isTwitterSharingEnabled** feature flag is only enabled for Jane, while **isFacebookSharingEnabled** is disabled for both of them. This happens because the feature flag key is also involved in computing the hash. ::: -3. **Increasing `isTwitterSharingEnabled` to 40% ON / 60% OFF** +3\. **Increasing _isTwitterSharingEnabled_ to 40% ON / 60% OFF** | | isTwitterSharingEnabled
40% ON / 60% OFF | isFacebookSharingEnabled
10% ON / 90% OFF | | ---- | ---------------------------------------------- | ----------------------------------------------- | -| Jane | 8 < 40
-> **ON** | 64 >= 10
-> **OFF** | -| Joe | 32 < 40
-> **ON** | 12 >= 10
-> **OFF** | +| Jane | 8 < 40
→ **ON** | 64 >= 10
→ **OFF** | +| Joe | 32 < 40
→ **ON** | 12 >= 10
→ **OFF** | + +4\. **Rolling Back to a Safer 10% ON / 90% OFF** + +Same setup as in Step 2. -4. **Rolling Back to a Safer 10% ON / 90% OFF** -> Same setup as in Step 2. -There are cases when you want to roll back a feature flag to a safer state. In this case, you can change the Percentage Options to 10% ON / 90% OFF. The sticky nature of percentage-based targeting ensures that the same user base is served **ON** as in Step 2, not another random 10% of users. +There are cases when you want to roll back a feature flag to a safer state. In this case, you can change the Percentage Options to 10% ON / 90% OFF again. The sticky nature of percentage-based targeting ensures that the same user base is served **ON** as in Step 2, not another random 10% of users. | | isTwitterSharingEnabled
10% ON / 90% OFF | isFacebookSharingEnabled
10% ON / 90% OFF | | ---- | ---------------------------------------------- | ----------------------------------------------- | -| Jane | 8 < 10
-> **ON** | 64 >= 10
-> **OFF** | -| Joe | 32 >= 10
-> **OFF** | 12 >= 10
-> **OFF** | +| Jane | 8 < 10
→ **ON** | 64 >= 10
→ **OFF** | +| Joe | 32 >= 10
→ **OFF** | 12 >= 10
→ **OFF** | -5. **Final Step: Moving to 100% ON / 0% OFF** +5\. **Final Step: Moving to 100% ON / 0% OFF** -After testing the feature flags, you can safely move them to 100% ON. This ensures that all users are receiving the features. +After testing the feature flags, you can safely move them to 100% ON. This will enable the features for all users. | | isTwitterSharingEnabled
100% ON / 0% OFF | isFacebookSharingEnabled
100% ON / 0% OFF | | ---- | ---------------------------------------------- | ----------------------------------------------- | -| Jane | 8 < 100
-> **ON** | 64 < 100
-> **ON** | -| Joe | 32 < 100
-> **ON** | 12 < 100
-> **ON** | \ No newline at end of file +| Jane | 8 < 100
→ **ON** | 64 < 100
→ **ON** | +| Joe | 32 < 100
→ **ON** | 12 < 100
→ **ON** | \ No newline at end of file diff --git a/website/docs/targeting/percentage-options.mdx b/website/docs/targeting/percentage-options.mdx index 37e99b6ce..efd8e2bfe 100644 --- a/website/docs/targeting/percentage-options.mdx +++ b/website/docs/targeting/percentage-options.mdx @@ -1,150 +1,158 @@ --- id: percentage-options title: Percentage Options -description: Using Percentage Options, you can define that a certain percentage of users should receive a specific value for a feature flag or setting. This way, you can gradually release a new feature to a subset of users. +description: Using Percentage Options, you can define that a certain percentage of users should receive a specific value. This way, you can gradually release a new feature to a subset of users. --- ## What are Percentage Options? -Using *Percentage Options*, you can define that a certain percentage of users should receive a specific value for a feature flag or setting. This way, you can gradually release a new feature to a subset of users. Instead of releasing a feature to all users simultaneously, a specific percentage of users are selected to receive access to the feature. This allows developers to control and monitor the impact of the new feature in a controlled manner. +Using _Percentage Options_, you can define that a certain percentage of users should receive a specific value. + +This way, you can gradually release a new feature to a subset of users. Instead of releasing a feature to all users simultaneously, a specific percentage of users are selected to receive access to the feature. This allows developers to control and monitor the impact of the new feature in a controlled manner. ## How to add Percentage Options? -You can add Percentage Options to a feature flag on the Dashboard by clicking on the `+%` button. +You can add Percentage Options to a feature flag on the Dashboard by clicking on the **+%** button. -Add Percentage Option +Add percentage options ## How does it work? - Anatomy of Percentage Options -The grouping is random and based on the [User Object's](../user-object) `Identifier` attribute by default. You can also use [other user attributes](#percentage-evaluation-attribute) to evaluate the Percentage Options. Percentage Options are designed to be **consistent** and **sticky** across all SDKs, ensuring a reliable experience. -- **Sticky** means that the same user will always get the same value for a specific feature flag and for a certain Percentage Options setup. [Read more below](#stickiness). -- **Consistent** means that the same user will always get the same value for a specific feature flag across all SDKs. [Read more below](#consistency). +Percentage Options are a list of _% value_ and _served value_ pairs, where % values add up to 100. -If the required attribute is not present in the [User Object](../user-object), the ["To unidentified" value](../targeting-overview/#to-all-users--to-all-other--to-unidentified-value) will be returned. +According to the percentage split defined by the % values, it divides users into groups. The grouping is random and based on the [User Object's](../user-object) **Identifier** attribute by default. You can also use [other user attributes](#percentage-evaluation-attribute) as the basis of the grouping. -Read more about the technical details of the [percentage evaluation here](../feature-flag-evaluation/#evaluation-of-percentage-options). +If the attribute to use as the basis of the grouping is not present in the [User Object](../user-object), the ["To unidentified" value](../targeting-overview/#to-all-users--to-all-other--to-unidentified-value) will be returned. (Read more about the feature flag evaluation algorithm [here](../feature-flag-evaluation).) -Percentage Options are a list of **% value** and **Served value** pairs, where % values add up to 100. +Percentage Options are designed to be [sticky](#stickiness) and [consistent](#consistency) across all SDKs, ensuring a reliable experience. ### % value -Any number between 0 and 100 that represents a randomly allocated fraction of your users. +Any number between 0 and 100 that represents a randomly allocated group of your users. ### Served value -The value that will be served to the users who fall into the group determined by the percentage. +The value to return when the user falls into the group determined by the % value. -## Number of Percentage Options +### Number of Percentage Options -### On/Off Toggle +In the case of a feature flag (boolean setting), the number of options must be 2. One for the **ON** and one for the **OFF** state. -When the Setting Kind is On/Off Toggle, the number of options must be 2. One for the _On_ and one for the _Off_ state. +In the case of a string, integer or double setting, the maximum number of options [depends on your subscription plan](../../subscription-plan-limits). You can add options by clicking the **+% OPTION** button. -### Text and Number +## Percentage Options within Targeting Rules -When the Setting Kind is _Text_, _Whole Number_, or _Decimal Number_, the maximum number of options depends on your subscription plan. You can add/remove options by clicking the _Actions_ icon. +Percentage Options can be used in combination with Targeting Rules. -## Percentage Options in combination with Targeting Rules +In this case, the Percentage Options will be evaluated only when the Targeting Rule matches. In other words, the Percentage Options apply only to the users that matched the Targeting Rule. -Percentage Options can be used in combination with Targeting Rules. In this case, the Percentage Options will be evaluated only when the Targeting Rule matches. In other words, the Percentage Options apply only to the users that matched the Targeting Rule. +If the attribute to use as the basis of the grouping is not present in the [User Object](../user-object), the targeting rule will be skipped - despite the matching Targeting Rule. Read more about the feature flag evaluation algorithm [here](../feature-flag-evaluation). -![Percentage Options with Targeting Rules](/assets/targeting/percentage-options/percentage-options-with-targeting-rules.png) +Percentage options within targeting rules ## Percentage Evaluation Attribute -The *Percentage Evaluation Attribute* is the attribute that is used to split the users into groups. The Percentage Evaluation Attribute is the [User Object's](../user-object) `Identifier` attribute by default. You can also use other user attributes as the basis of the grouping (see an example use case below). +The _Percentage Evaluation Attribute_ is the user attribute by which users are grouped. It is the [User Object's](../user-object) **Identifier** attribute by default. You can also use other user attributes as the basis of the grouping (see the example use case [below](#percentage-options-based-on-other-user-attributes)). ### How to change the Percentage Evaluation Attribute? -Click the 3 dots on the top right corner of the feature flag and select the **Change Percentage Attribute** option. +Open the kebab menu in the top right corner of the feature flag and choose the **Change percentage attribute** item. -> Changing the Percentage Evaluation Attribute will apply to all Percentage Options within the feature flag (but only in the current environment). +:::info +The selected Percentage Evaluation Attribute applies to all Percentage Options within the feature flag - but only in the current environment. +::: -Change Percentage Attribute +Change percentage attribute ## Stickiness -Stickiness means that the same user will always get the same value for a specific feature flag, no matter the history of the feature flag. This is achieved by implementing a deterministic hashing algorithm based on the feature flag's key and the Percentage Evaluation Attribute. +_Stickiness_ means that the same user will always get the same value for the same percentage split in the case of a specific feature flag, regardless of the history of the feature flag. This is achieved by implementing a deterministic hashing algorithm based on the feature flag's key and the Percentage Evaluation Attribute. + +For example, if you have a feature flag with a Percentage Option of **20% ON**, then you change the Percentage Option to **40% ON**, and then back to **20% ON**, the same 20% of users will get the **ON** value for the feature flag just like the first time. -*For example, if you have a feature flag with a Percentage Option of `20%` `ON`, then you change the Percentage Option to `40%` `ON`, and then back to `20%` `ON`, the same `20%` of users will get the `ON` value for the feature flag just like the first time.* +For a demonstration of this concept, see this [example scenario](../feature-flag-evaluation#example-scenarios-for-percentage-options). ## Consistency -Consistency means that the same user will always get the same value for a specific feature flag, no matter which SDK they use. This is achieved by using the same hashing algorithm across all SDKs. +_Consistency_ means that the same user will always get the same value for the same percentage split in the case of a specific feature flag, no matter which SDK is used. This is achieved by using the same hashing algorithm across all SDKs. -*For example, if you have a feature flag with a Percentage Option of `20%` `ON`, then the same `20%` of users will get the `ON` value across all SDKs. No matter if a user is on iOS, Android, or Web, they will always get the same value for the feature flag.* +For example, if you have a feature flag with a Percentage Option of **20% ON**, then the same 20% of users will get the **ON** value across all SDKs. No matter if a user is on iOS, Android, or Web, they will always get the same value for the feature flag. ## Randomness -The same user might get different values for the same Percentage Options setup in the case of different feature flags. This is because the hashing algorithm is based on the combination of the feature flag's key and the Percentage Evaluation Attribute. The key of each feature flag is different, so the hash will be as well. +The same user might get different values for the same percentage split in the case of different feature flags. This is because the hashing algorithm is based on the combination of the feature flag's key and the Percentage Evaluation Attribute. Since feature flag keys are unique, the resulting hashes will usually be different as well. -*For example, if you have two feature flags with Percentage Options of `20%` `ON`, then a different `20%` of users will get the `ON` value for each feature flag.* +For example, if you have two feature flags with Percentage Options of **20% ON**, then a different 20% of users will get the **ON** value for each feature flag. ## Examples -### Simple phased rollout / Canary release / Percentage rollout Scenario +### Simple phased rollout / Canary release / Percentage rollout scenario #### Context -Our demo company, Whisker Co. is about to release a new feature called `Park Weather Info`. The stakeholders want to make sure that the new feature will be received well by the customers. +Our demo company, Whisker Co. is about to release a new feature called **Park Weather Info**. The stakeholders want to make sure that the new feature is received well by the customers. #### Goal -To get some feedback from our customers before releasing it to everyone, we initially want to make the feature available to `20%` of the customers only. +To get some feedback from our customers before releasing it to everyone, we initially want to make the feature available to 20% of the customers only. #### Solution -Let's create a feature flag called `Enable Park Weather Info` with Percentage Options set to `20%` `ON` and `80%` `OFF`. +Let's create a feature flag called **Enable Park Weather Info** with Percentage Options set to **20% ON** and **80% OFF**. -![Targeting Example 1](/assets/targeting/percentage-options/example1.png) +Simple phased rollout example -### A/B/n Testing Scenario +### A/B/n testing scenario #### Context -The marketing specialists at Whisker Co. want to introduce a discount method to encourage more purchases in the webshop. They have multiple ideas but, without data, they can't decide which is the most effective. +The marketing specialists at Whisker Co. want to introduce a discount strategy to boost webshop purchases. They have several ideas but lack the statistical data needed to determine which would be most effective. #### Goal -To learn which is the most effective discount method, we want to perform an A/B/C test. +To learn which is the most effective discount strategy, we want to perform an A/B/C test. #### Solution -We need a string or integer setting for this task because we need to represent 3 different variations. Let's create a string setting named `Discount Type` (as textual values tell more than numbers). +We need a string or integer setting for this task because we need to represent 3 different variations. Let's create a string setting named **Discount Type** (as textual values tell more than numbers). The go-to feature for A/B testing is Percentage Options. So let's add one with 3 options, each covering 1/3rd of our customers. -![Targeting Example 2](/assets/targeting/percentage-options/example2.png) +A/B/n testing example + +:::info +To make all this useful, that is, to measure the effectiveness of the different strategies, we also need to integrate with an analytics service like [Amplitude](../../integrations/amplitude) or [Mixpanel](../../integrations/mixpanel) and update our application to send feature flag evaluation results to it. +::: -### Complex phased rollout / Canary release / Percentage rollout Scenario +### Complex phased rollout / Canary release / Percentage rollout scenario #### Context -Whisker Co. is about to release a new feature called `Park Weather Info`. The stakeholders want to make sure that releasing the new feature will go smoothly and it will be received well by the customers. +Whisker Co. is about to release a new feature called **Park Weather Info**. The stakeholders want to make sure that the release of the new feature goes smoothly and it is received well by the customers. #### Goal -To do some in-house testing and also get some feedback from our customers before releasing it to everyone, we initially want to make the feature available to the employees and to `20%` of the customers only. +To do some in-house testing and also get some feedback from our customers before releasing it to everyone, we initially want to make the feature available to the employees and to 20% of the customers only. #### Solution -Let's create a feature flag called `Enable Park Weather Info` with a Targeting Rule that matches employees at Whisker Co. and Percentage Options set to `20%` `ON` and `80%` `OFF` for the rest of the users (i.e. for the customers). +Let's create a feature flag called **Enable Park Weather Info** with a Targeting Rule that matches the employees at Whisker Co. and Percentage Options set to **20% ON** and **80% OFF** for the rest of the users (i.e. for the customers). -![Targeting Example 3](/assets/targeting/percentage-options/example3.png) +Complex phased rollout example ### Platform-specific phased rollout #### Context -Whisker Co. is about to release a new feature called `Cafe Notifications` in their mobil app, which has an Android and an iOS version. We know that the user base of the iOS app is much larger than the Android app. The stakeholders want to make sure that the new feature will be received well by the customers. +Whisker Co. is about to release a new feature called **Cafe Notifications** in their mobile app, which has an Android and an iOS version. We know that the user base of the iOS app is much larger than the Android app. The stakeholders want to make sure that the new feature is received well by the customers. #### Goal To get some feedback from our customers before releasing it to everyone, we initially want to make the feature available to a limited number of customers only. We also want to release the feature to roughly the same number of Android and iOS users. #### Solution -Let's create a feature flag called `Cafe Notifications` with two Targeting Rules: one that matches Android users and one that matches iOS users. Then change the THEN part of both to Percentage Options. Finally, set the percentages so that the feature is enabled for roughly the same number of users (e.g. 60% for `Android` users, 20% for `iOS` users). +Let's create a feature flag called **Cafe Notifications** with two Targeting Rules: one that matches Android users and one that matches iOS users. Then change the THEN part of both to Percentage Options. Finally, let's set the percentages so that the feature is enabled for roughly the same number of users (e.g. 60% for Android users, 20% for iOS users). -![Targeting Example 4](/assets/targeting/percentage-options/example4.png) +Platform-specific phased rollout example -### Percentage Options based on other User Attributes +### Percentage Options based on other user attributes #### Context -Let's imagine that at Whisker Co., we have a custom attribute named `Tenant ID` that is used to identify the tenants of our customers. +Let's imagine that at Whisker Co., we have a custom attribute named **Tenant ID** that is used to identify the tenants of our customers. #### Goal -We want to release a new feature, `Park Weather Info`, to 20% of our customers based on their `Tenant ID`. +We want to release a new feature, **Park Weather Info**, to 20% of our customers based on their **Tenant ID**. #### Solution -Let's create a feature flag called `Enable Park Weather Info` with Percentage Options set to `20%` `ON` and `80%` `OFF`. Finally, set the Percentage Evaluation Attribute to `Tenant ID`. +Let's create a feature flag called **Enable Park Weather Info** with Percentage Options set to **20% ON** and **80% OFF**. Finally, let's set the Percentage Evaluation Attribute to **Tenant ID** as described [here](#percentage-evaluation-attribute). -![Targeting Example 4](/assets/targeting/percentage-options/example5.png) \ No newline at end of file +Custom percentage attribute example \ No newline at end of file diff --git a/website/docs/targeting/targeting-overview.mdx b/website/docs/targeting/targeting-overview.mdx index 0b0a39d9d..ec356026e 100644 --- a/website/docs/targeting/targeting-overview.mdx +++ b/website/docs/targeting/targeting-overview.mdx @@ -6,9 +6,9 @@ description: Overview of the ConfigCat targeting feature with examples. Targeting allows you to enable or disable a feature for specific users or groups of users in your application. Typical use cases are: -- Beta testing -- A/B testing -- Phased rollouts, canary releases +- [Beta testing](../../glossary#beta-testing) +- [A/B testing](../../glossary#ab-testing) +- [Phased rollouts, canary releases](../../glossary#canary-release) ## How does it work? @@ -19,7 +19,7 @@ Targeting allows you to enable or disable a feature for specific users or groups ## What is what? -![Targeting Overview](/assets/targeting/targeting-overview/targeting.png) +Targeting Overview ### Feature Flag / Setting @@ -37,7 +37,8 @@ simplicity because feature flags are the most common type of settings. ### Targeting Rule A _Targeting Rule_ consists of a collection of conditions and a value to serve. If the conditions are met (the Targeting -Rule _matches_), the value is served to the user. More about [Targeting Rules here](../targeting-rule/targeting-rule-overview). +Rule _matches_), the value is served, i.e. returned as the result of the feature flag evaluation. More about +Targeting Rules [here](../targeting-rule/targeting-rule-overview). ### Condition @@ -47,9 +48,9 @@ A _condition_ is a logical expression that can be evaluated to true or false. Th ### Percentage Options -_Percentage Options_ are used to split users into groups that will receive a specific value for the feature flag. -The groups are allocated based on the ratio of the percentages. Percentage Options are often used for A/B testing or -phased rollouts. More about [Percentage Options here](../percentage-options). +_Percentage Options_ divide users into groups, each receiving a specific value. +The groups are allocated according to the specified percentage split. Percentage Options are often used for A/B testing or +phased rollouts. More about Percentage Options [here](../percentage-options). ### "To all users" / "To all other" / "To unidentified" value @@ -63,30 +64,30 @@ value will be returned in case the SDK fails to fetch the config or some other e ### User Object -A _User Object_ is a collection of _user attributes_ that describe the properties of a user. Referencing these attributes -in conditions allows you to define rules for targeting users. More about the [User Object here](../user-object). +A _User Object_ is a collection of _user attributes_ that store the properties of a user. Referencing these attributes +in conditions allows you to define rules for targeting users. More about the User Object [here](../user-object). ## Examples -### Phased rollout / Canary release / Percentage rollout Scenario +### Phased rollout / Canary release / Percentage rollout scenario #### Context -Our demo company, Whisker Co. is about to release a new feature called `Park Weather Info`. The stakeholders want to make -sure that releasing the new feature will go smoothly and it will be received well by the customers. +Our demo company, Whisker Co. is about to release a new feature called **Park Weather Info**. The stakeholders want to make +sure that the release of the new feature goes smoothly and it is received well by the customers. #### Goal To make sure that the new feature is working as expected before releasing it to everyone, we initially want to make the -feature available to the employees and to `20%` of the customers only. +feature available to the employees and to 20% of the customers only. #### Solution -Let's create a feature flag called `Enable Park Weather Info` with a Targeting Rule that matches the employees at -Whisker Co. and Percentage Options set to `20%` `ON` and `80%` `OFF` for the rest of the users (i.e. for the customers). +Let's create a feature flag called **Enable Park Weather Info** with a Targeting Rule that matches the employees at +Whisker Co. and Percentage Options set to **20% ON** and **80% OFF** for the rest of the users (i.e. for the customers). Here is what such a feature flag looks like on the Dashboard: -![Phased rollout Example](../../static/assets/targeting/targeting-overview/phased-rollout.png) +Phased rollout example Here is how we get the value of the feature flag in your application: @@ -97,7 +98,7 @@ const userObject = new configcat.User( '867428724', // Email - used by the Targeting Rule's User Condition to determine whether // the user is an employee at Whisker Co. - 'isaac@whisker.example', + 'isaac@whisker.cc', ); // Get the value of the feature flag diff --git a/website/docs/targeting/targeting-rule/flag-condition.mdx b/website/docs/targeting/targeting-rule/flag-condition.mdx index 5f6a84f44..059698960 100644 --- a/website/docs/targeting/targeting-rule/flag-condition.mdx +++ b/website/docs/targeting/targeting-rule/flag-condition.mdx @@ -6,7 +6,7 @@ description: A Flag Condition is a condition that is based on the comparison of ## What is a Flag Condition? What is a prerequisite flag? -A *Flag Condition* is a condition that is based on the comparison of another feature flag's value and a preset value (*comparison value*). In other words, a Flag Condition creates a dependency between the feature flag containing the condition (*dependent flag*) and another feature flag (*prerequisite flag*, aka. master feature flag, master switch, inter-dependent feature flag, global toggle, etc.) +A _Flag Condition_ is a condition that is based on the comparison of another feature flag's value and a preset value (_comparison value_). In other words, a Flag Condition creates a dependency between the feature flag containing the condition (_dependent flag_) and another feature flag (_prerequisite flag_, aka. master feature flag, master switch, inter-dependent feature flag, global toggle, etc.) This allows you to control the value of multiple feature flags by changing the value of a single, central feature flag. Prerequisite flags are useful for managing complex feature dependencies and ensuring a smooth user experience during feature rollouts. @@ -20,27 +20,27 @@ For more details on the evaluation of Flag Conditions, please refer to [Feature ## How to set a Flag Condition? -You can set a Flag Condition for a feature flag on the ConfigCat Dashboard. The prerequisite flag can be any feature flag already defined in the same config on the Dashboard. In the case of settings other than feature flags (boolean settings), you can also set a comparison value to which the prerequisite flag's value will be compared. +You can add a Flag Condition to a feature flag on the Dashboard by clicking on the **+IF** ("Add targeting rule") button. -set flag condition +The prerequisite flag can be any feature flag already defined in the same config on the Dashboard. In the case of settings other than feature flags (boolean settings), you can also set a comparison value to which the prerequisite flag's value will be compared. + +Add prerequisite ## Anatomy of a Flag Condition #### Prerequisite is a feature flag (boolean setting) -{/* ![Flag Condition anatomy 1](/assets/targeting/targeting-rule/flag-condition/flag-condition-anatomy1.png) */} -Flag Condition anatomy 1 +Flag condition anatomy (feature flag) #### Prerequisite is a string, integer or double setting -{/* ![Flag Condition anatomy 2](/assets/targeting/targeting-rule/flag-condition/flag-condition-anatomy2.png) */} -Flag Condition anatomy 2 +Flag condition anatomy (non-boolean setting) A Flag Condition consists of the following: -- **Prerequisite flag key**: The key of the feature flag (or setting) on which the condition is based. -- **Comparator**: The comparison operator that defines the relation between the prerequisite flag's value and the comparison value. See the available comparators below. -- **Comparison value**: Available only when the prerequisite flag is a string, integer or double setting. The value that the prerequisite flag's value is compared to. +- **_Prerequisite flag key_:** The key of the feature flag or setting on which the condition is based. +- **_Comparator_:** The comparison operator that defines the relation between the prerequisite flag's value and the comparison value. See the available comparators below. +- **_Comparison value_:** The preset value to which the prerequisite flag's value is compared. Available only when the prerequisite flag is a string, integer or double setting. The value that the prerequisite flag's value is compared to. -### Comparators +### Comparator Different comparators are available for different types of prerequisites. @@ -65,8 +65,8 @@ When the prerequisite is a string, integer or double setting, the following comp #### Context Our demo company, Whisker Co. has a mobile app, which, among other things, can show the cat-friendly cafés in the neighborhood. -The app can send notifications about the users' favorite cafés. This feature is not available to everyone though, it's enabled using the `Enable Cafe Notifications` feature flag. -There is another feature that allows users to rate cafés, whose availability is controlled similarly, via the `Enable Cafe Ratings` feature flag. +The app can send notifications about the users' favorite cafés. This feature is not available to everyone though, it's enabled using the **Enable Cafe Notifications** feature flag. +There is another feature that allows users to rate cafés, whose availability is controlled similarly, via the **Enable Cafe Ratings** feature flag. #### Goal We want to make sure that users only receive notifications about their favorite cafés if they can rate them. @@ -74,7 +74,7 @@ We want to make sure that users only receive notifications about their favorite #### Solution ConfigCat offers a built-in way to solve this problem without the need of extra coding: prerequisite flags. -We can achieve our goal by adding a Targeting Rule containing a Flag Condition to `Enable Cafe Notifications`, then referencing `Enable Cafe Ratings` in the condition and setting the comparator to `IS ON`, meaning that the `Enable Cafe Notifications` feature flag will be enabled only if the `Enable Cafe Ratings` feature flag is ON. +We can achieve our goal by adding a Targeting Rule containing a Flag Condition to **Enable Cafe Notifications**, then referencing **Enable Cafe Ratings** in the condition and setting the comparator to **IS ON**, meaning that the **Enable Cafe Notifications** feature flag will be enabled only if the **Enable Cafe Ratings** feature flag is ON. On the Dashboard: -![Flag Condition example](/assets/targeting/targeting-rule/flag-condition/flag-condition-example.png) \ No newline at end of file +Flag condition example \ No newline at end of file diff --git a/website/docs/targeting/targeting-rule/segment-condition.mdx b/website/docs/targeting/targeting-rule/segment-condition.mdx index 146dced67..bdc83e074 100644 --- a/website/docs/targeting/targeting-rule/segment-condition.mdx +++ b/website/docs/targeting/targeting-rule/segment-condition.mdx @@ -6,41 +6,42 @@ description: Segments allow you to define user groups based on any user attribut ## What is a Segment Condition? What is a segment? -A *Segment Condition* is a condition that is based on the evaluation of a segment. A *segment* is a reusable, predefined [User Condition](../user-condition). +A _Segment Condition_ is a condition that is based on the evaluation of a segment. A _segment_ is approximately a reusable, predefined [User Condition](../user-condition). -Segments allow you to define user groups based on any user attributes. You can reference segments in Targeting Rules. When you update a segment definition, the changes will be reflected automatically in all the Targeting Rules that reference it. +Segments allow you to define user groups based on any user attribute. You can reference segments in Targeting Rules. When you update a segment definition, the changes will be reflected automatically in all the Targeting Rules that reference it. -*For example, you can define a segment called "Beta Testers" and use that segment for all features you want to be available to beta testers.* +For example, you can define a segment called **Beta Testers** and use that segment for all features you want to be available to beta testers. One segment belongs to one product and can be used in multiple feature flags within the same product. ## How does the Segment Condition work? -The segment is evaluated with the [User Object](../../user-object), and the result is checked against the comparator you set on the Dashboard. In the case of `IS IN SEGMENT`, the result of the Segment Condition will be the same as that of the segment. The result will be negated in the case of `IS NOT IN SEGMENT`. +The segment is evaluated with the [User Object](../../user-object), and the result is checked against the comparator you set on the Dashboard. In the case of **IS IN SEGMENT**, the result of the Segment Condition will be the same as that of the segment. In the case of **IS NOT IN SEGMENT**, the result will be negated. For more details on the evaluation of Segment Conditions, please refer to [Feature Flag Evaluation](../../feature-flag-evaluation). ## How to set a Segment Condition? -You can add a Targeting Rule with a Segment Condition on the Dashboard by clicking on the `+IF` ("Add Targeting Rule") button. +You can add a Segment Condition to a feature flag on the Dashboard by clicking on the **+IF** ("Add targeting rule") button. -Add Segment Condition +Target a segment ## Where can I define segments? -You can define your segments on the [ConfigCat Dashboard under the Segments tab](https://app.configcat.com/product/segments). - -![Add segment](/assets/targeting/targeting-rule/segment-condition/add-segment.png) +You can define your segments on the ConfigCat Dashboard, on the [Segments page](https://app.configcat.com/product/segments). +Add segment ## Anatomy of a Segment Condition -Segment Condition anatomy +Segment condition + +A Segment Condition consists of two parts: -A *Segment Condition* consists of two parts: +- **_Segment comparator_:** The comparison operator defines the relation between the user and the segment. See the available comparators below. +- **_Segment_:** The segment that the condition is based on. -- **Segment comparator:** The comparison operator defines the relation between the user and the segment. -- **Segment:** The segment that the condition is based on. +### Segment comparator | Comparator | Description | | ----------------- | ------------------------------------------------------- | @@ -53,74 +54,74 @@ A *Segment Condition* consists of two parts: | -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | | Name | The name of the segment. | | Description | The description of the segment. It's a good idea to add a hint that helps you remember what the segment is for. | -| Comparison attribute | The attribute that the segment is based on. Could be "User ID", "Email", "Country" or any custom attribute. | +| Comparison attribute | The attribute that the segment is based on. Can be **Identifier** (user ID), **Email**, **Country**, or any custom attribute. | | Comparator | The comparison operator. Defines the relation between the comparison attribute and the comparison value. | -| Comparison value | The value that the attribute is compared to. Could be a string, a number, a semantic version or a comma-separated list, depending on the comparator. | +| Comparison value | The value that the attribute is compared to. Can be a string, a number, a semantic version or a comma-separated list, depending on the comparator. | ### Comparison attribute -A property of your user (e.g. _email address_, _geographic location_). Your application should pass the attribute values (e.g. *jane@example.com*, _Europe_) to the ConfigCat SDK as a [User Object](../../user-object). +A property of your user (e.g. email address, geographic location). Your application should pass the attribute values (e.g. `'jane@example.com'`, `'Europe'`) to the ConfigCat SDK as a [User Object](../../user-object). -There are 3 predefined attributes. Additionally, you can define your **_custom attributes_** as well: +There are 3 predefined attributes. Additionally, you can define your custom attributes as well: -| Comparison attribute name | Description | -| ------------------------- | ------------------------------------------------------------------------------------ | -| `Identifier` | Usually, it is a unique user identifier in your application. | -| `Email` | The e-mail address of your user. | -| `Country` | Might be useful for testing a new feature only in one country. | -| `Custom` | **_Define any attribute (e.g. `OS version`), by typing its name into the textbox._** | +| Comparison attribute name | Description | +| ------------------------- | ------------------------------------------------------------------------------------------------- | +| Identifier | Usually, it is a unique user identifier in your application. | +| Email | The e-mail address of your user. | +| Country | The location of your user. Might be useful for testing a new feature in specific countries only. | +| Custom | Any additional attribute (e.g. **OS version**). Can be defined by typing its name into the textbox. | -### Comparison Value +### Comparison value -Any string, number, or comma-separated list. Will be compared to the selected _Comparison attribute_ using the _Comparator_. **Max Length: 65535 chars**. +Any string, number, or comma-separated list. Will be compared to the selected comparison attribute using the comparator. **Max. length: 65535 characters.** ### Comparator -#### Confidential Text Comparators +#### Confidential text comparators -We recommend using confidential text comparators when targeting users based on their sensitive data (like email address, name, etc). +We recommend using confidential text comparators when targeting users based on their sensitive data (like email address, name, etc.) In this case, the feature flag evaluation is performed using the SHA256 hashes of the values to ensure that the comparison values are not exposed. This can cause an increase in the size of the config JSON file and the overall network traffic. Yet it is not recommended to use the cleartext version of the confidential comparators unless the increased network traffic becomes an issue. -The following comparators expect the *Comparison attribute* to be a string value and the *Comparison value* to be a string or a list of strings. +The following comparators expect the comparison attribute to be a string value and the comparison value to be a string or a list of strings. The comparison is case-sensitive. -| Comparator | Description | -| ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | -| IS ONE OF (hashed) | Checks whether the comparison attribute is equal to any of the comparison values. (_Comparison value_ should be a comma-separated list.) | -| IS NOT ONE OF (hashed) | Checks whether the comparison attribute is not equal to any of the comparison values. (_Comparison value_ should be a comma-separated list.) | +| Comparator | Description | +| ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | +| IS ONE OF (hashed) | Checks whether the comparison attribute is equal to any of the comparison values. (Comparison value is interpreted as a comma-separated list.) | +| IS NOT ONE OF (hashed) | Checks whether the comparison attribute is not equal to any of the comparison values. (Comparison value is interpreted as a comma-separated list.) | #### Text comparators -The following comparators expect the *Comparison attribute* to be a string value and the *Comparison value* to be a string or a list of strings. +The following comparators expect the comparison attribute to be a string value and the comparison value to be a string or a list of strings. The comparison is case-sensitive. :::info -Consider using Confidential text comparators if you plan to target users by their sensitive data, e.g.: email address or company domain. +Consider using confidential text comparators if you plan to target users based on their sensitive data, e.g. email address or company domain. ::: -| Comparator | Description | -| ---------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | -| CONTAINS (cleartext) | Checks whether the comparison attribute contains the comparison value as a substring. | -| DOES NOT CONTAIN (cleartext) | Checks whether the comparison attribute does not contain the comparison value as a substring. | -| IS ONE OF (cleartext) | Checks whether the comparison attribute is equal to any of the comparison values. (_Comparison value_ should be a comma-separated list.) | -| IS NOT ONE OF (cleartext) | Checks whether the comparison attribute is not equal to any of the comparison values. (_Comparison value_ should be a comma-separated list.) | +| Comparator | Description | +| ---------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | +| CONTAINS (cleartext) | Checks whether the comparison attribute contains the comparison value as a substring. | +| DOES NOT CONTAIN (cleartext) | Checks whether the comparison attribute does not contain the comparison value as a substring. | +| IS ONE OF (cleartext) | Checks whether the comparison attribute is equal to any of the comparison values. (Comparison value is interpreted as a comma-separated list.) | +| IS NOT ONE OF (cleartext) | Checks whether the comparison attribute is not equal to any of the comparison values. (Comparison value is interpreted as a comma-separated list.) | #### Semantic version comparators -The following comparators expect the *Comparison attribute* to be a string containing a valid semantic version and the *Comparison value* to be a semantic version or a list of semantic versions. +The following comparators expect the comparison attribute to be a string containing a valid semantic version and the comparison value to be a semantic version or a list of semantic versions. -Evaluation is based on the SemVer Semantic Version Specification. +Comparison is performed according to the Semantic Versioning specification. -| Comparator | Description | -| ---------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| IS ONE OF (semver) | Checks whether the comparison attribute interpreted as a semantic version is equal to any of the comparison values. (_Comparison value_ should be a comma-separated list of semantic versions.) | -| IS NOT ONE OF (semver) | Checks whether the comparison attribute interpreted as a semantic version is not equal to any of the comparison values. (_Comparison value_ should be a comma-separated list of semantic versions.) | -| < (semver) | Checks whether the comparison attribute interpreted as a semantic version is less than the comparison value. | -| <= (semver) | Checks whether the comparison attribute interpreted as a semantic version is less than or equal to the comparison value. | -| > (semver) | Checks whether the comparison attribute interpreted as a semantic version is greater than the comparison value. | -| >= (semver) | Checks whether the comparison attribute interpreted as a semantic version is greater than or equal to the comparison value. | +| Comparator | Description | +| ---------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| IS ONE OF (semver) | Checks whether the comparison attribute interpreted as a semantic version is equal to any of the comparison values. (Comparison value is interpreted as a comma-separated list of semantic versions.) | +| IS NOT ONE OF (semver) | Checks whether the comparison attribute interpreted as a semantic version is not equal to any of the comparison values. (Comparison value is interpreted as a comma-separated list of semantic versions.) | +| < (semver) | Checks whether the comparison attribute interpreted as a semantic version is less than the comparison value. | +| <= (semver) | Checks whether the comparison attribute interpreted as a semantic version is less than or equal to the comparison value. | +| > (semver) | Checks whether the comparison attribute interpreted as a semantic version is greater than the comparison value. | +| >= (semver) | Checks whether the comparison attribute interpreted as a semantic version is greater than or equal to the comparison value. | #### Number comparators -The following comparators expect the *Comparison attribute* and the *Comparison value* to be numbers. +The following comparators expect the comparison attribute and the comparison value to be numbers. | Comparator | Description | | ------------------ | ------------------------------------------------------------------------------------------------------------------------- | @@ -133,18 +134,18 @@ The following comparators expect the *Comparison attribute* and the *Comparison ## Examples -### Beta Testing Scenario +### Beta testing scenario #### Context The developers at our demo company, Whisker Co. just finished implementing a nice new feature which allows users to personalize the layout of the webshop. It's time for a beta test. #### Goal -We want to make the `Personalized Layout` feature of the webshop available to the beta testers. +We want to make the **Personalized Layout** feature of the webshop available to the beta testers. #### Solution -We could simply achieve our goal using a Targeting Rule with a User Condition. However, `Personalized Layout` is certainly not the last feature developed at Whisker Co., so it's a good idea to create a segment named e.g. `Beta Testers` for our beta testers. This makes it easier for us to release further features for beta testing in the future. +We could simply achieve our goal using a Targeting Rule with a User Condition. However, **Personalized Layout** is certainly not the last feature developed at Whisker Co., so it's a good idea to create a segment named e.g. **Beta Testers** for our beta testers. This makes it easier for us to release further features for beta testing in the future. -After creating the segment, we can complete our task by adding a Targeting Rule containing a Segment Condition to `Enable Personalized Layout`, then referencing the `Beta Testers` segment in the condition and setting the comparator to `IS IN SEGMENT`. +After creating the segment, we can complete our task by adding a Targeting Rule containing a Segment Condition to **Enable Personalized Layout**, then referencing the **Beta Testers** segment in the condition and setting the comparator to **IS IN SEGMENT**. On the Dashboard: -![Segment Condition example](/assets/targeting/targeting-rule/segment-condition/beta-testers.png) \ No newline at end of file +Beta testing example \ No newline at end of file diff --git a/website/docs/targeting/targeting-rule/targeting-rule-overview.mdx b/website/docs/targeting/targeting-rule/targeting-rule-overview.mdx index 0105fe12a..074e2f1b3 100644 --- a/website/docs/targeting/targeting-rule/targeting-rule-overview.mdx +++ b/website/docs/targeting/targeting-rule/targeting-rule-overview.mdx @@ -1,14 +1,16 @@ --- id: targeting-rule-overview title: Targeting Rule Overview -description: Targeting Rules allow you to set different feature flag or setting values for specific users or groups of users in your application. +description: Targeting Rules allow you to set different feature flag values for specific users or groups of users in your application. --- # Targeting Rule ## What is a Targeting Rule? -*Targeting Rules* allow you to set different feature flag or setting values for specific users or groups of users in your application. You can set conditions based on user attributes, feature flags, or segments within a Targeting Rule. +_Targeting Rules_ allow you to set different feature flag values for specific users or groups of users in your application. + +You can set conditions based on user attributes, feature flags, or segments within a Targeting Rule. ### AND and OR relationships @@ -18,30 +20,30 @@ The Targeting Rules are in an **OR** relationship, meaning that the Targeting Ru ## How to add a Targeting Rule? -You can add a Targeting Rule to a feature flag on the Dashboard by clicking on the `+IF` ("Add Targeting Rule") button. Add more Targeting Rules by clicking on the `+OR` button at the bottom of the Targeting Rule. +You can add a Targeting Rule to a feature flag on the Dashboard by clicking on the **+IF** ("Add targeting rule") button, then more Targeting Rules by clicking on the **+OR** button at the bottom of the last Targeting Rule. -![Add Targeting Rule](/assets/targeting/targeting-rule/add-rule.png) +Add targeting rule ## How does it work? - Anatomy of a Targeting Rule -A Targeting Rule consists of an **IF part** and a **THEN part**. +A Targeting Rule consists of an _IF part_ and a _THEN part_. -![Targeting Rule anatomy](/assets/targeting/targeting-rule/targeting-rule.png) +Targeting rule anatomy ### IF part -The *IF part* contains the conditions, which are logical expressions that evaluate to true or false. +The _IF part_ contains the conditions, which are logical expressions that evaluate to true or false. The conditions are in an **AND** relationship, meaning that all of them must evaluate to true for the Targeting Rule to match. -The conditions can be added to the Targeting Rule on the Dashboard. There are three types of conditions: +The conditions can be added to the Targeting Rule on the Dashboard, using the **+AND** ("Add AND condition") button. There are three types of conditions: - [User Condition](../user-condition) - A condition that is based on some property of the user. - [Flag Condition (Prerequisite)](../flag-condition) - A condition that is based on the value of another feature flag. - [Segment Condition](../segment-condition) - A condition that is based on a segment. ### THEN part -The *THEN part* contains either a value or Percentage Options that will be used to determine the result of the feature flag when the Targeting Rule matches. +The _THEN part_ contains either a value or Percentage Options that will be used to determine the result of the feature flag when the Targeting Rule matches. ## Multiple Targeting Rules and ordering The order of Targeting Rules matters because they are in an **OR** relationship, meaning that the Targeting Rule which matches first in order, from top to bottom, will provide the value of the feature flag. @@ -50,7 +52,7 @@ The order of Targeting Rules matters because they are in an **OR** relationship, The order of the Targeting Rules can be changed on the Dashboard by dragging and dropping the Targeting Rules. -![Change Targeting Rule order](/assets/targeting/targeting-rule/reorder.png) +Change targeting rule order ## Examples @@ -60,20 +62,20 @@ The order of the Targeting Rules can be changed on the Dashboard by dragging and In our demo company (Whisker Co.) we have a new feature in our mobile app that notifies frequent shopper cat owners about the cat-friendly cafés in the neighborhood. #### Goal -Since this feature is new, we want to make sure that only frequent shoppers and cat owners who have the right version of the app receive these notifications. The earlier versions of the app don't have this feature, so we want to make sure that anyone higher than version 3.0.0 receives the notifications. +Since this feature is new, we want to make sure that only frequent shoppers and cat owners who have the right version of the app receive these notifications. The earlier versions of the app don't have this feature, so we want to make sure that only those who are running version 3.0.0 or higher receive the notifications. #### Solution -We can achieve this by adding a Targeting Rule to the `Enable Cafe Notifications` feature flag. The Targeting Rule will have two conditions: -- User Condition: `AppVersion` is greater than `3.0.0` -- Segment Condition: `Frequent Shoppers` +We can achieve this by adding a Targeting Rule to the **Enable Cafe Notifications** feature flag. The Targeting Rule will have two conditions: +- a Segment Condition, which requires that the user is in segment **Frequent Shoppers**, +- a User Condition, which requires that the user attribute **AppVersion** is greater than or equal to **3.0.0**. On the Dashboard: -![Targeting Rule example](/assets/targeting/targeting-rule/and-example.png) +AND relationship example In the code: ```js const userObject = new configcat.User(userId, userEmail, undefined, { - AppVersion: `3.1.2` + AppVersion: '3.1.2' }); const value = await configCatClient.getValueAsync("enableCafeNotifications", false, userObject); diff --git a/website/docs/targeting/targeting-rule/user-condition.mdx b/website/docs/targeting/targeting-rule/user-condition.mdx index 0bae17a19..d78780976 100644 --- a/website/docs/targeting/targeting-rule/user-condition.mdx +++ b/website/docs/targeting/targeting-rule/user-condition.mdx @@ -6,55 +6,57 @@ description: A User Condition is a condition that is based on the comparison of ## What is a User Condition? -A *User Condition* is a condition that is based on the comparison of a user attribute and a preset value (*comparison value*). It allows you to define Targeting Rules which target users based on their properties. +A _User Condition_ is a condition that is based on the comparison of a user attribute (_comparison attribute_) and a preset value (_comparison value_). + +It allows you to define Targeting Rules which target users based on their properties. ## How does the User Condition work? -The *comparison attribute*'s value from the [User Object](../../user-object) is compared to the *comparison value* you set on the Dashboard. The comparison is done according to the selected comparator and will result in true or false. This will be the result of the condition. +The comparison attribute's value from the [User Object](../../user-object) is compared to the comparison value you set on the Dashboard. The comparison is done according to the selected comparator and will result in true or false. This will be the result of the condition. For more details on the evaluation of User Conditions, please refer to [Feature Flag Evaluation](../../feature-flag-evaluation). ## How to set a User Condition? -You can add a Targeting Rule with a condition on the Dashboard by clicking on the `+IF` ("Add Targeting Rule") button. Add more conditions by clicking on the `+AND` button. +You can add a User Condition to a feature flag on the Dashboard by clicking on the **+IF** ("Add targeting rule") button, then more conditions by clicking on the **+AND** ("Add AND condition") button. -add user condition +Target users ## Anatomy of a User Condition -![User Condition anatomy](/assets/targeting/targeting-rule/user-condition/user-condition-anatomy.png) +User condition anatomy -A *User Condition* consists of three parts: +A User Condition consists of three parts: -- **Comparison attribute:** The user attribute on which the condition is based. Could be "User ID", "Email", "Country", or any custom attribute. -- **Comparator:** The comparison operator that defines the relation between the comparison attribute and the comparison value. -- **Comparison value:** The preset value to which the comparison attribute is compared. Depending on the comparator, could be a string, a list of strings, a number, a semantic version, a list of semantic versions or a date. +- **_Comparison attribute_:** The user attribute on which the condition is based. Can be **Identifier** (user ID), **Email**, **Country**, or any custom attribute. +- **_Comparator_:** The comparison operator that defines the relation between the comparison attribute and the comparison value. See the available comparators [here](#comparator). +- **_Comparison value_:** The preset value to which the comparison attribute is compared. Depending on the comparator, can be a string, a list of strings, a number, a semantic version, a list of semantic versions or a date. -### Comparison Attribute +### Comparison attribute -A property of your user (e.g. _email address_, _geographic location_). Your application should pass the attribute values (e.g. *jane@example.com*, _Europe_) to the ConfigCat SDK as a [User Object](../../user-object). +A property of your user (e.g. email address, geographic location). Your application should pass the attribute values (e.g. `'jane@example.com'`, `'Europe'`) to the ConfigCat SDK as a [User Object](../../user-object). -There are 3 predefined attributes. Additionally, you can define your **_custom attributes_** as well: +There are 3 predefined attributes. Additionally, you can define your custom attributes as well: -| Comparison attribute name | Description | -| ------------------------- | ------------------------------------------------------------------------------ | -| `Identifier` | Usually, it is a unique user identifier in your application. | -| `Email` | The e-mail address of your user. | -| `Country` | Might be useful for testing a new feature only in one country. | -| `Custom` | Define any attribute (e.g. `OS version`), by typing its name into the textbox. | +| Comparison attribute name | Description | +| ------------------------- | ------------------------------------------------------------------------------------------------- | +| Identifier | Usually, it is a unique user identifier in your application. | +| Email | The e-mail address of your user. | +| Country | The location of your user. Might be useful for testing a new feature in specific countries only. | +| Custom | Any additional attribute (e.g. **OS version**). Can be defined by typing its name into the textbox. | -### Comparison Value +### Comparison value -A string, a list of strings, a number, a semantic version, a list of semantic versions or a date value. Will be compared to the selected _Comparison attribute_ using the _Comparator_. The length of the _Comparison value_ is limited, and the limit depends on your subscription plan. See the [plan limits page](../../../subscription-plan-limits) for more details. +A string, a list of strings, a number, a semantic version, a list of semantic versions or a date value. Will be compared to the selected comparison attribute using the comparator. The length of the comparison value is limited, and the limit depends on your subscription plan. See the [Subscription Plan Limits page](../../../subscription-plan-limits) for more details. ### Comparator -#### Confidential Text Comparators +#### Confidential text comparators -We recommend using confidential text comparators when targeting users based on their sensitive data (like email address, name, etc). +We recommend using confidential text comparators when targeting users based on their sensitive data (like email address, name, etc.) In this case, the feature flag evaluation is performed using the SHA256 hashes of the values to ensure that the comparison values are not exposed. This can cause an increase in the size of the config JSON file and the overall network traffic. Yet it is not recommended to use the cleartext version of the confidential comparators unless the increased network traffic becomes an issue. -The following comparators expect the *Comparison attribute* to be a string value and the *Comparison value* to be a string or a list of strings. The comparison is case-sensitive. +The following comparators expect the comparison attribute to be a string value and the comparison value to be a string or a list of strings. The comparison is case-sensitive. | Comparator | Description | | ------------------------------- | ------------------------------------------------------------------------------------------ | @@ -67,12 +69,12 @@ The following comparators expect the *Comparison attribute* to be a string value | ENDS WITH ANY OF (hashed) | Checks whether the comparison attribute ends with any of the comparison values. | | NOT ENDS WITH ANY OF (hashed) | Checks whether the comparison attribute does not end with any of the comparison values. | -#### Text Comparators +#### Text comparators -The following comparators expect the *Comparison attribute* to be a string value and the *Comparison value* to be a string or a list of strings. The comparison is case-sensitive. +The following comparators expect the comparison attribute to be a string value and the comparison value to be a string or a list of strings. The comparison is case-sensitive. :::info -Consider using Confidential text comparators if you plan to target users by their sensitive data, e.g.: email address or company domain. +Consider using confidential text comparators if you plan to target users based on their sensitive data, e.g. email address or company domain. ::: | Comparator | Description | @@ -89,11 +91,11 @@ Consider using Confidential text comparators if you plan to target users by thei | NOT CONTAINS ANY OF (cleartext) | Checks whether the comparison attribute does not contain any comparison values as a substring. | -#### Semantic Version Comparators +#### Semantic version comparators -The following comparators expect the *Comparison attribute* to be a string containing a valid semantic version and the *Comparison value* to be a semantic version or a list of semantic versions. +The following comparators expect the comparison attribute to be a string containing a valid semantic version and the comparison value to be a semantic version or a list of semantic versions. -Evaluation is based on the SemVer Semantic Version Specification. +Comparison is performed according to the Semantic Versioning specification. | Comparator | Description | | ---------------------- | ---------------------------------------------------------------------------------------------------------------------------- | @@ -105,9 +107,9 @@ Evaluation is based on the SemVer | >= (semver) | Checks whether the comparison attribute interpreted as a semantic version is greater than or equal to the comparison value. | -#### Number Comparators +#### Number comparators -The following comparators expect the *Comparison attribute* and the *Comparison value* to be numbers. +The following comparators expect the comparison attribute and the comparison value to be numbers. | Comparator | Description | | ------------------ | -------------------------------------------------------------------------------------------------------------------------- | @@ -119,18 +121,18 @@ The following comparators expect the *Comparison attribute* and the *Comparison | >= (number) | Checks whether the comparison attribute interpreted as a decimal number is greater than or equal to the comparison value. | -#### Date and Time Comparators +#### Date and time comparators -The following comparators expect the *Comparison attribute* to be a date value (a second-based [Unix timestamp](https://en.wikipedia.org/wiki/Unix_time) or a platform-specific date object), and the *Comparison value* to be a date. +The following comparators expect the comparison attribute to be a date value (a second-based [Unix timestamp](https://en.wikipedia.org/wiki/Unix_time) or a platform-specific date object) and the comparison value to be a date. | Comparator | Description | | ---------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | BEFORE | Checks whether the comparison attribute interpreted as a second-based [Unix timestamp](https://en.wikipedia.org/wiki/Unix_time) is less than the comparison value. | | AFTER | Checks whether the comparison attribute interpreted as a second-based [Unix timestamp](https://en.wikipedia.org/wiki/Unix_time) is greater than the comparison value. | -#### Array Comparators +#### Array comparators -The following comparators expect the *Comparison attribute* to be an array of strings (or an array of strings serialized to JSON), and the *Comparison value* to be a list of strings. The comparison is case-sensitive. +The following comparators expect the comparison attribute to be an array of strings (or an array of strings serialized to JSON) and the comparison value to be a list of strings. The comparison is case-sensitive. | Comparator | Description | | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | @@ -139,19 +141,19 @@ The following comparators expect the *Comparison attribute* to be an array of st ## Examples -### Black Friday Sale +### Black Friday sale #### Context Black Friday is coming and we want to offer a special discount to our users. #### Goal -The deals should become available at midnight on Black Friday. We want to make sure that the users can't access the deals before that. And the deal should be available for the whole weekend. +The deals should become available at midnight on Black Friday. We want to make sure that the users can't access the deals before that. Also, the deals should be available for the whole weekend. #### Solution -Let's use the AFTER comparator to check whether the current time is after midnight on Black Friday AND the current time is BEFORE midnight on Sunday. +Let's use the **AFTER** comparator to check whether the current time is after midnight on Black Friday AND the current time is **BEFORE** midnight on Sunday. On the Dashboard: -![Black Friday Sale Example](/assets/targeting/targeting-rule/user-condition/black-friday-example.png) +Black Friday sale example In the code: ```js @@ -170,20 +172,19 @@ const value = await configCatClient.getValueAsync("enableBlackFridayDeals", fals We use ConfigCat in our Angular frontend application to control the availability of a feature. #### Goal -We want to enable this feature for users from certain companies. To do the job, we would need to use the `CONTAINS` or `NOT CONTAINS` comparators. +We want to enable this feature for users from certain companies. To do the job, we would need to use the **CONTAINS** or **NOT CONTAINS** comparators. However, there is no confidential version of these comparators and we are well aware that, for privacy reasons, it's not a good idea to use cleartext comparators for applications running in the browser. How can we solve this? #### Solution -Let's work around the problem by extracting the domain part of the email and pass it as a custom attribute named e.g. `domain` to the ConfigCat SDK. +Let's work around the problem by extracting the domain part of the email and passing it as a custom attribute named **Domain** to the ConfigCat SDK. This way we can define the desired Targeting Rule using confidential comparators only. On the Dashboard: -{/* User Condition Example */} -![User Condition Example](/assets/targeting/targeting-rule/user-condition/user-condition-example1.png) +Confidential CONTAINS example In the code: @@ -191,8 +192,12 @@ In the code: const userDomain = userEmail.split('@').pop(); const userObject = new configcat.User(userId, userEmail, undefined, { - { domain: userDomain } + { Domain: userDomain } }); const value = await configCatClient.getValueAsync(key, defaultValue, userObject); -``` \ No newline at end of file +``` + +:::info +Since the introduction of [Config V2](../../../advanced/config-v2), this workaround is no longer needed: in a V2 config, you can simply use the hashed version of the **ENDS WITH ANY OF** comparator. +::: \ No newline at end of file diff --git a/website/docs/targeting/user-object.mdx b/website/docs/targeting/user-object.mdx index b8b0450bb..f9d7a88a1 100644 --- a/website/docs/targeting/user-object.mdx +++ b/website/docs/targeting/user-object.mdx @@ -1,14 +1,16 @@ --- id: user-object title: User Object -description: The User Object is a collection of *user attributes* that describe the properties of a user. The User Object is essential for targeting. +description: The User Object is a collection of user attributes that store various pieces of information about a user. The User Object is essential for targeting. --- -The *User Object* is a collection of *user attributes* that describe the properties of a user. The *User Object* is necessary to evaluate [Targeting Rules](../targeting-rule/targeting-rule-overview) and [Percentage Options](../percentage-options). -It allows you to pass the user attributes that are referenced in the rules of the feature flag to the ConfigCat SDK. The User Object represents a user in your application. +The _User Object_ represents a user in your application. It is a collection of *user attributes* that store various pieces of information about the user. + +The User Object is necessary to evaluate [Targeting Rules](../targeting-rule/targeting-rule-overview) and [Percentage Options](../percentage-options). +It allows you to pass the user attributes that are referenced in the rules of the feature flag to the ConfigCat SDK. :::info -The *User Object* is essential if you'd like to use ConfigCat's [Targeting](../targeting-overview) feature. +The User Object is essential if you'd like to use ConfigCat's [Targeting](../targeting-overview) feature. ::: ## The relationship between the User Object and Targeting Rules @@ -19,23 +21,23 @@ The *User Object* is essential if you'd like to use ConfigCat's [Targeting](../t ## Security and privacy concerns -ConfigCat was designed with security and privacy in mind. The evaluation process is entirely implemented within the SDKs, meaning **your users' sensitive data never leaves your system**. The data flow is one-way – from ConfigCat CDN servers to your SDKs – and ConfigCat does not receive or store any attributes of the User Object passed to the SDKs. This design prioritizes the privacy and security of user data. +ConfigCat was designed with security and privacy in mind. The feature flag evaluation process is entirely implemented within the SDKs, meaning **your users' sensitive data never leaves your system**. The data flow is one-way – from ConfigCat CDN servers to your SDKs – and ConfigCat does not receive or store any attributes of the User Object passed to the SDKs. This design prioritizes the privacy and security of user data. ## Anatomy of the User Object -The data that can be stored in the User Object: +The User Object offers the following properties to store user data: | Attribute | Description | | ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Identifier | **REQUIRED.** We recommend adding a UserID, Email address, or SessionID. | -| Email | Optional. By adding this parameter, you can create Email address-based targeting. e.g.: Only turn on a feature for users with @example.com addresses. | -| Country | Optional. Fill this for location or country-based targeting. e.g.: Turn on a feature for users in Canada only. | -| Custom | Optional. This parameter will let you create targeting based on any user data you like. e.g: Age, Subscription type, User role, Device type, App version number, etc. | +| Identifier | **REQUIRED.** We recommend using a user ID, email address, or session ID. | +| Email | Optional. Setting this allows you to target users based on their email address. E.g.: "Turn on a feature for users with **@example.com** addresses only." | +| Country | Optional. Specify this for location or country-based targeting. E.g.: "Turn on a feature for users in Canada only." | +| Custom | Optional. A map/dictionary that lets you set custom user attributes to target users based on any user data. E.g.: age, subscription type, user role, device type, app version, etc. | ### Code example ```js -let userObject = new configcat.User( +const userObject = new configcat.User( '#UNIQUE-USER-IDENTIFIER#', // Identifier attribute (Required) 'john@example.com', // Email attribute (Optional) 'United Kingdom', // Country attribute (Optional) @@ -48,40 +50,42 @@ let userObject = new configcat.User( ### Identifier attribute -Unique identifier of a user in your application. This is a **REQUIRED** attribute which enables ConfigCat to differentiate your users from each other and to evaluate the feature flag values for Percentage Options. +The unique identifier of a user in your application. This is a **REQUIRED** attribute, which enables ConfigCat to differentiate your users from each other and to evaluate Targeting Rules and Percentage Options. -Our recommendation as an identifier: +Our recommendation for an identifier: -- User ID - If you have one in your application, you can use the same User ID with ConfigCat. -- Email address - In most cases, adding an email address works perfectly here, as long as it is unique. -- SessionId - This is useful for targeting users who are not logged in to your application. +- User ID - If such an ID is available in your application, you can as well use it with ConfigCat. +- Email address - In most cases, using an email address works perfectly - as long as it is unique. +- Session ID - This is useful for targeting users who are not logged in to your application. ### Custom attributes -To use custom attributes, you need to pass a User Object containing the `custom` attribute to the ConfigCat SDK. +To use custom attributes, you need to pass a User Object containing the `custom` property to the ConfigCat SDK. -> The custom attribute's value can be multiple types. e.g.: string, number, date, array of strings, etc. Check the [SDK reference](../../sdk-reference/overview) for more details. +:::info +The custom attribute's value can be of multiple types: e.g. string, number, date, array of strings, etc. Check the [SDK reference](../../sdk-reference/overview) for more details. +::: ## Examples ### Enable a feature for most valuable customers only #### Context -Our demo company, Whisker Co. developed a new feature called `Personalized Layout` to enhance the user experience of their most valuable customers. +Our demo company, Whisker Co. developed a new feature called **Personalized Layout** to enhance the user experience of their most valuable customers. #### Goal -We want to enable the `Personalized Layout` feature but only for customers with the `Pro` subscription type. +We want to enable the **Personalized Layout** feature but only for customers with a **Pro** subscription. #### Solution -To achieve this goal, we need a custom attribute named e.g. `SubscriptionType`, which stores the subscription type of the customer. +To achieve this goal, we need a custom attribute named e.g. **SubscriptionType**, which stores the subscription type of the customer. -This allows us to define a Targeting Rule that turns on the feature for the customers whose `SubscriptionType` attribute is `Pro`. Finally, we need to make sure that the "To all others" value is OFF so the feature is turned off for the rest of the customers. +This allows us to define a Targeting Rule that turns on the feature for the customers whose **SubscriptionType** attribute is **Pro**. Finally, we need to make sure that the "To all others" value is **OFF** so the feature is turned off for the rest of the customers. #### Dashboard -![User Object example](/assets/targeting/user-object/user-object-example.png) +Most valuable customers example #### Code -Add the `SubscriptionType` custom attribute to the User Object in your application code. +Add the **SubscriptionType** custom attribute to the User Object in your application code. ```js const userObject = new configcat.User(userId, undefined, undefined, { diff --git a/website/static/assets/targeting/percentage-options/abn-testing-example_192dpi.png b/website/static/assets/targeting/percentage-options/abn-testing-example_192dpi.png new file mode 100644 index 000000000..5a44e83bc Binary files /dev/null and b/website/static/assets/targeting/percentage-options/abn-testing-example_192dpi.png differ diff --git a/website/static/assets/targeting/percentage-options/add-percentage-option.png b/website/static/assets/targeting/percentage-options/add-percentage-option.png deleted file mode 100644 index 9e1e52aa7..000000000 Binary files a/website/static/assets/targeting/percentage-options/add-percentage-option.png and /dev/null differ diff --git a/website/static/assets/targeting/percentage-options/add-percentage-options_192dpi.png b/website/static/assets/targeting/percentage-options/add-percentage-options_192dpi.png new file mode 100644 index 000000000..d309811a7 Binary files /dev/null and b/website/static/assets/targeting/percentage-options/add-percentage-options_192dpi.png differ diff --git a/website/static/assets/targeting/percentage-options/change-percentage-attribute.png b/website/static/assets/targeting/percentage-options/change-percentage-attribute.png deleted file mode 100644 index 167f85d06..000000000 Binary files a/website/static/assets/targeting/percentage-options/change-percentage-attribute.png and /dev/null differ diff --git a/website/static/assets/targeting/percentage-options/change-percentage-attribute_192dpi.png b/website/static/assets/targeting/percentage-options/change-percentage-attribute_192dpi.png new file mode 100644 index 000000000..df36b73a0 Binary files /dev/null and b/website/static/assets/targeting/percentage-options/change-percentage-attribute_192dpi.png differ diff --git a/website/static/assets/targeting/percentage-options/complex-phased-rollout-example_192dpi.png b/website/static/assets/targeting/percentage-options/complex-phased-rollout-example_192dpi.png new file mode 100644 index 000000000..803947791 Binary files /dev/null and b/website/static/assets/targeting/percentage-options/complex-phased-rollout-example_192dpi.png differ diff --git a/website/static/assets/targeting/percentage-options/custom-percentage-attribute-example_192dpi.png b/website/static/assets/targeting/percentage-options/custom-percentage-attribute-example_192dpi.png new file mode 100644 index 000000000..f0a9edc4c Binary files /dev/null and b/website/static/assets/targeting/percentage-options/custom-percentage-attribute-example_192dpi.png differ diff --git a/website/static/assets/targeting/percentage-options/example1.png b/website/static/assets/targeting/percentage-options/example1.png deleted file mode 100644 index 8052baa29..000000000 Binary files a/website/static/assets/targeting/percentage-options/example1.png and /dev/null differ diff --git a/website/static/assets/targeting/percentage-options/example2.png b/website/static/assets/targeting/percentage-options/example2.png deleted file mode 100644 index 3608105be..000000000 Binary files a/website/static/assets/targeting/percentage-options/example2.png and /dev/null differ diff --git a/website/static/assets/targeting/percentage-options/example3.png b/website/static/assets/targeting/percentage-options/example3.png deleted file mode 100644 index 7e7ae2307..000000000 Binary files a/website/static/assets/targeting/percentage-options/example3.png and /dev/null differ diff --git a/website/static/assets/targeting/percentage-options/example4.png b/website/static/assets/targeting/percentage-options/example4.png deleted file mode 100644 index 5a7ed769b..000000000 Binary files a/website/static/assets/targeting/percentage-options/example4.png and /dev/null differ diff --git a/website/static/assets/targeting/percentage-options/example5.png b/website/static/assets/targeting/percentage-options/example5.png deleted file mode 100644 index 81efb1d75..000000000 Binary files a/website/static/assets/targeting/percentage-options/example5.png and /dev/null differ diff --git a/website/static/assets/targeting/percentage-options/percentage-options-with-targeting-rules.png b/website/static/assets/targeting/percentage-options/percentage-options-with-targeting-rules.png deleted file mode 100644 index b155e204b..000000000 Binary files a/website/static/assets/targeting/percentage-options/percentage-options-with-targeting-rules.png and /dev/null differ diff --git a/website/static/assets/targeting/percentage-options/percentage-options-within-targeting-rule_192dpi.png b/website/static/assets/targeting/percentage-options/percentage-options-within-targeting-rule_192dpi.png new file mode 100644 index 000000000..5cdd8210f Binary files /dev/null and b/website/static/assets/targeting/percentage-options/percentage-options-within-targeting-rule_192dpi.png differ diff --git a/website/static/assets/targeting/percentage-options/platform-specific-phased-rollout-example_192dpi.png b/website/static/assets/targeting/percentage-options/platform-specific-phased-rollout-example_192dpi.png new file mode 100644 index 000000000..31e7cc5bb Binary files /dev/null and b/website/static/assets/targeting/percentage-options/platform-specific-phased-rollout-example_192dpi.png differ diff --git a/website/static/assets/targeting/percentage-options/simple-phased-rollout-example_192dpi.png b/website/static/assets/targeting/percentage-options/simple-phased-rollout-example_192dpi.png new file mode 100644 index 000000000..67a7438b5 Binary files /dev/null and b/website/static/assets/targeting/percentage-options/simple-phased-rollout-example_192dpi.png differ diff --git a/website/static/assets/targeting/targeting-overview/phased-rollout-example_192dpi.png b/website/static/assets/targeting/targeting-overview/phased-rollout-example_192dpi.png new file mode 100644 index 000000000..803947791 Binary files /dev/null and b/website/static/assets/targeting/targeting-overview/phased-rollout-example_192dpi.png differ diff --git a/website/static/assets/targeting/targeting-overview/phased-rollout.png b/website/static/assets/targeting/targeting-overview/phased-rollout.png deleted file mode 100644 index 17ac765cf..000000000 Binary files a/website/static/assets/targeting/targeting-overview/phased-rollout.png and /dev/null differ diff --git a/website/static/assets/targeting/targeting-overview/targeting.png b/website/static/assets/targeting/targeting-overview/targeting.png deleted file mode 100644 index bfe55fc30..000000000 Binary files a/website/static/assets/targeting/targeting-overview/targeting.png and /dev/null differ diff --git a/website/static/assets/targeting/targeting-overview/what-is-what_192dpi.png b/website/static/assets/targeting/targeting-overview/what-is-what_192dpi.png new file mode 100644 index 000000000..7fd6a97d1 Binary files /dev/null and b/website/static/assets/targeting/targeting-overview/what-is-what_192dpi.png differ diff --git a/website/static/assets/targeting/targeting-rule/add-rule.png b/website/static/assets/targeting/targeting-rule/add-rule.png deleted file mode 100644 index 10190cd7d..000000000 Binary files a/website/static/assets/targeting/targeting-rule/add-rule.png and /dev/null differ diff --git a/website/static/assets/targeting/targeting-rule/add-targeting-rule_192dpi.png b/website/static/assets/targeting/targeting-rule/add-targeting-rule_192dpi.png new file mode 100644 index 000000000..8c04ecc7e Binary files /dev/null and b/website/static/assets/targeting/targeting-rule/add-targeting-rule_192dpi.png differ diff --git a/website/static/assets/targeting/targeting-rule/and-example.png b/website/static/assets/targeting/targeting-rule/and-example.png deleted file mode 100644 index a882607d5..000000000 Binary files a/website/static/assets/targeting/targeting-rule/and-example.png and /dev/null differ diff --git a/website/static/assets/targeting/targeting-rule/and-example_192dpi.png b/website/static/assets/targeting/targeting-rule/and-example_192dpi.png new file mode 100644 index 000000000..72f4bb060 Binary files /dev/null and b/website/static/assets/targeting/targeting-rule/and-example_192dpi.png differ diff --git a/website/static/assets/targeting/targeting-rule/flag-condition/add-prerequisite_192dpi.png b/website/static/assets/targeting/targeting-rule/flag-condition/add-prerequisite_192dpi.png new file mode 100644 index 000000000..7e33dd0d7 Binary files /dev/null and b/website/static/assets/targeting/targeting-rule/flag-condition/add-prerequisite_192dpi.png differ diff --git a/website/static/assets/targeting/targeting-rule/flag-condition/flag-condition-anatomy1.png b/website/static/assets/targeting/targeting-rule/flag-condition/flag-condition-anatomy1.png deleted file mode 100644 index fc153e82e..000000000 Binary files a/website/static/assets/targeting/targeting-rule/flag-condition/flag-condition-anatomy1.png and /dev/null differ diff --git a/website/static/assets/targeting/targeting-rule/flag-condition/flag-condition-anatomy1_192dpi.png b/website/static/assets/targeting/targeting-rule/flag-condition/flag-condition-anatomy1_192dpi.png new file mode 100644 index 000000000..7189ffed7 Binary files /dev/null and b/website/static/assets/targeting/targeting-rule/flag-condition/flag-condition-anatomy1_192dpi.png differ diff --git a/website/static/assets/targeting/targeting-rule/flag-condition/flag-condition-anatomy2.png b/website/static/assets/targeting/targeting-rule/flag-condition/flag-condition-anatomy2.png deleted file mode 100644 index cf46bdbe5..000000000 Binary files a/website/static/assets/targeting/targeting-rule/flag-condition/flag-condition-anatomy2.png and /dev/null differ diff --git a/website/static/assets/targeting/targeting-rule/flag-condition/flag-condition-anatomy2_192dpi.png b/website/static/assets/targeting/targeting-rule/flag-condition/flag-condition-anatomy2_192dpi.png new file mode 100644 index 000000000..8c1201230 Binary files /dev/null and b/website/static/assets/targeting/targeting-rule/flag-condition/flag-condition-anatomy2_192dpi.png differ diff --git a/website/static/assets/targeting/targeting-rule/flag-condition/flag-condition-example.png b/website/static/assets/targeting/targeting-rule/flag-condition/flag-condition-example.png deleted file mode 100644 index d5f45d36f..000000000 Binary files a/website/static/assets/targeting/targeting-rule/flag-condition/flag-condition-example.png and /dev/null differ diff --git a/website/static/assets/targeting/targeting-rule/flag-condition/flag-condition-example_192dpi.png b/website/static/assets/targeting/targeting-rule/flag-condition/flag-condition-example_192dpi.png new file mode 100644 index 000000000..177cb29cc Binary files /dev/null and b/website/static/assets/targeting/targeting-rule/flag-condition/flag-condition-example_192dpi.png differ diff --git a/website/static/assets/targeting/targeting-rule/flag-condition/flag-condition.png b/website/static/assets/targeting/targeting-rule/flag-condition/flag-condition.png deleted file mode 100644 index 219043432..000000000 Binary files a/website/static/assets/targeting/targeting-rule/flag-condition/flag-condition.png and /dev/null differ diff --git a/website/static/assets/targeting/targeting-rule/reorder.png b/website/static/assets/targeting/targeting-rule/reorder.png deleted file mode 100644 index f01ed1e59..000000000 Binary files a/website/static/assets/targeting/targeting-rule/reorder.png and /dev/null differ diff --git a/website/static/assets/targeting/targeting-rule/segment-condition/add-segment-condition.png b/website/static/assets/targeting/targeting-rule/segment-condition/add-segment-condition.png deleted file mode 100644 index 9e0f3f286..000000000 Binary files a/website/static/assets/targeting/targeting-rule/segment-condition/add-segment-condition.png and /dev/null differ diff --git a/website/static/assets/targeting/targeting-rule/segment-condition/add-segment.png b/website/static/assets/targeting/targeting-rule/segment-condition/add-segment.png deleted file mode 100644 index 48a849697..000000000 Binary files a/website/static/assets/targeting/targeting-rule/segment-condition/add-segment.png and /dev/null differ diff --git a/website/static/assets/targeting/targeting-rule/segment-condition/add-segment_192dpi.png b/website/static/assets/targeting/targeting-rule/segment-condition/add-segment_192dpi.png new file mode 100644 index 000000000..3810bf7cf Binary files /dev/null and b/website/static/assets/targeting/targeting-rule/segment-condition/add-segment_192dpi.png differ diff --git a/website/static/assets/targeting/targeting-rule/segment-condition/beta-testers.png b/website/static/assets/targeting/targeting-rule/segment-condition/beta-testers.png deleted file mode 100644 index 69e226fa4..000000000 Binary files a/website/static/assets/targeting/targeting-rule/segment-condition/beta-testers.png and /dev/null differ diff --git a/website/static/assets/targeting/targeting-rule/segment-condition/beta-testing-example_192dpi.png b/website/static/assets/targeting/targeting-rule/segment-condition/beta-testing-example_192dpi.png new file mode 100644 index 000000000..1892b36f7 Binary files /dev/null and b/website/static/assets/targeting/targeting-rule/segment-condition/beta-testing-example_192dpi.png differ diff --git a/website/static/assets/targeting/targeting-rule/segment-condition/segment-condition-anatomy.png b/website/static/assets/targeting/targeting-rule/segment-condition/segment-condition-anatomy.png deleted file mode 100644 index 01ce7d30f..000000000 Binary files a/website/static/assets/targeting/targeting-rule/segment-condition/segment-condition-anatomy.png and /dev/null differ diff --git a/website/static/assets/targeting/targeting-rule/segment-condition/segment-condition-anatomy_192dpi.png b/website/static/assets/targeting/targeting-rule/segment-condition/segment-condition-anatomy_192dpi.png new file mode 100644 index 000000000..7cf5c1458 Binary files /dev/null and b/website/static/assets/targeting/targeting-rule/segment-condition/segment-condition-anatomy_192dpi.png differ diff --git a/website/static/assets/targeting/targeting-rule/segment-condition/target-segment_192dpi.png b/website/static/assets/targeting/targeting-rule/segment-condition/target-segment_192dpi.png new file mode 100644 index 000000000..c29782714 Binary files /dev/null and b/website/static/assets/targeting/targeting-rule/segment-condition/target-segment_192dpi.png differ diff --git a/website/static/assets/targeting/targeting-rule/targeting-rule-anatomy_192dpi.png b/website/static/assets/targeting/targeting-rule/targeting-rule-anatomy_192dpi.png new file mode 100644 index 000000000..07c58c96b Binary files /dev/null and b/website/static/assets/targeting/targeting-rule/targeting-rule-anatomy_192dpi.png differ diff --git a/website/static/assets/targeting/targeting-rule/targeting-rule-reorder_192dpi.png b/website/static/assets/targeting/targeting-rule/targeting-rule-reorder_192dpi.png new file mode 100644 index 000000000..2028aa2a6 Binary files /dev/null and b/website/static/assets/targeting/targeting-rule/targeting-rule-reorder_192dpi.png differ diff --git a/website/static/assets/targeting/targeting-rule/targeting-rule.png b/website/static/assets/targeting/targeting-rule/targeting-rule.png deleted file mode 100644 index 5bac4f7a2..000000000 Binary files a/website/static/assets/targeting/targeting-rule/targeting-rule.png and /dev/null differ diff --git a/website/static/assets/targeting/targeting-rule/user-condition/black-friday-example.png b/website/static/assets/targeting/targeting-rule/user-condition/black-friday-example.png deleted file mode 100644 index 5289e2aa6..000000000 Binary files a/website/static/assets/targeting/targeting-rule/user-condition/black-friday-example.png and /dev/null differ diff --git a/website/static/assets/targeting/targeting-rule/user-condition/black-friday-example_192dpi.png b/website/static/assets/targeting/targeting-rule/user-condition/black-friday-example_192dpi.png new file mode 100644 index 000000000..17d16a52c Binary files /dev/null and b/website/static/assets/targeting/targeting-rule/user-condition/black-friday-example_192dpi.png differ diff --git a/website/static/assets/targeting/targeting-rule/user-condition/confidential-contains-example_192dpi.png b/website/static/assets/targeting/targeting-rule/user-condition/confidential-contains-example_192dpi.png new file mode 100644 index 000000000..045174d13 Binary files /dev/null and b/website/static/assets/targeting/targeting-rule/user-condition/confidential-contains-example_192dpi.png differ diff --git a/website/static/assets/targeting/targeting-rule/user-condition/target-users_192dpi.png b/website/static/assets/targeting/targeting-rule/user-condition/target-users_192dpi.png new file mode 100644 index 000000000..a27cf208f Binary files /dev/null and b/website/static/assets/targeting/targeting-rule/user-condition/target-users_192dpi.png differ diff --git a/website/static/assets/targeting/targeting-rule/user-condition/user-condition-anatomy.png b/website/static/assets/targeting/targeting-rule/user-condition/user-condition-anatomy.png deleted file mode 100644 index 97f1ca23e..000000000 Binary files a/website/static/assets/targeting/targeting-rule/user-condition/user-condition-anatomy.png and /dev/null differ diff --git a/website/static/assets/targeting/targeting-rule/user-condition/user-condition-anatomy_192dpi.png b/website/static/assets/targeting/targeting-rule/user-condition/user-condition-anatomy_192dpi.png new file mode 100644 index 000000000..98e81d0a9 Binary files /dev/null and b/website/static/assets/targeting/targeting-rule/user-condition/user-condition-anatomy_192dpi.png differ diff --git a/website/static/assets/targeting/targeting-rule/user-condition/user-condition-example1.png b/website/static/assets/targeting/targeting-rule/user-condition/user-condition-example1.png deleted file mode 100644 index 1b228c883..000000000 Binary files a/website/static/assets/targeting/targeting-rule/user-condition/user-condition-example1.png and /dev/null differ diff --git a/website/static/assets/targeting/targeting-rule/user-condition/user-condition.png b/website/static/assets/targeting/targeting-rule/user-condition/user-condition.png deleted file mode 100644 index 71afff775..000000000 Binary files a/website/static/assets/targeting/targeting-rule/user-condition/user-condition.png and /dev/null differ diff --git a/website/static/assets/targeting/user-object/most-valueable-customers-example_192dpi.png b/website/static/assets/targeting/user-object/most-valueable-customers-example_192dpi.png new file mode 100644 index 000000000..4953e35c3 Binary files /dev/null and b/website/static/assets/targeting/user-object/most-valueable-customers-example_192dpi.png differ diff --git a/website/static/assets/targeting/user-object/user-object-example.png b/website/static/assets/targeting/user-object/user-object-example.png deleted file mode 100644 index 157fbc3f2..000000000 Binary files a/website/static/assets/targeting/user-object/user-object-example.png and /dev/null differ