Impressions after migration
The way Optimizely Experimentation triggers impressions may change after migrating from Full Stack Experimentation (Legacy) to Feature Experimentation, depending on the types of experiments you run and your SDK implementation.
After migrating to Feature Experimentation from Full Stack Experimentation (Legacy), if you are running A/B tests and use the getEnabledFeatures
SDK method, action is required to ensure impressions are counted accurately after migrating.
Impressions in Full Stack Experimentation (Legacy)
In Full Stack Experimentation (Legacy), there are two different types of experiments you can run:
- A/B test – Experiment not tied to a specific feature. You can define variations and use the Optimizely Full Stack Experimentation SDK's
activate
method to return the appropriate variation for a user in the experiment. - Feature test – Experiment built on top of a feature. You can group feature variables into experiment variations and use the Optimizely Full Stack Experimentation SDK's
isFeatureEnabled
method to return the appropriate variables for a user. You can also use thegetEnabledFeatures
method to make decisions for the enabled features.
Note
You can find more details on the differences between an A/B test and a feature test in the Simplified data model documentation.
Optimizely triggers an impression for a user that qualifies for a running experiment when you call the activate
method for A/B tests or the isFeatureEnabled
or getEnabledFeatures
methods for feature tests, respectively.
Calling the isFeatureEnabled
or getEnabledFeatures
methods only return variables and send impressions for feature tests. Impressions are not sent for A/B tests with these methods.
Impressions in Feature Experimentation
In Feature Experimentation, experiments are flag rules built on top of a feature flag. More details are in the Simplified data model documentation.
Optimizely Experimentation triggers an impression when a user is exposed to a flag variation as part of an Optimizely experiment. The legacy methods listed above (activate
, isFeatureEnabled
, getEnabledFeatures
) are still fully supported after you migrate a project to Feature Experimentation.
Changes with impressions after migrating
If you use both the activate
and getEnabledFeatures
methods in an A/B test, you will see an increase in the number of impressions that Optimizely triggers after migrating.
After migrating to Feature Experimentation, your A/B test from Full Stack Experimentation (Legacy) becomes an A/B test flag rule under its own feature flag. The activate
method will still return the appropriate variation for a converted A/B test flag rule and trigger an impression as expected without any needed code changes. For information on migrating A/B tests, see Migrate legacy A/B test.
However, because an A/B test is now a flag rule built on top of a flag in Feature Experimentation, it is now included in the getEnabledFeatures
method after migrating. The getEnabledFeatures
method will return variations and trigger impressions for the A/B test flag rule.
Including a converted A/B test flag rule in both the activate
and getEnabledFeatures
methods may trigger Optimizely to send more impressions than before migrating.
Recommended approach
To ensure you are not unknowingly triggering impressions for converted A/B test flag rules, you should replace the activate
and getEnabledFeatures
methods with the decide
and decideAll
methods, respectively.
- The
decide
method returns decision results for a flag key for a user. - The
decideAll
method returns decision results for active (unarchived) flags for a user.
Note
You can disable decision events for
decide
anddecideAll
method calls using theDISABLE_DECISION_EVENT
option.
decide
method reference documentation
decide
method reference documentation- Android SDK
- C# SDK
- Flutter SDK
- Go SDK
- Java SDK
- JavaScript (Browser) SDK
- JavaScript (Node) SDK
- PHP SDK
- Python SDK
- React SDK (
useDecision
hook) - React Native SDK (
useDecision
hook) - Ruby SDK
- Swift SDK
decideAll
method reference documentation
decideAll
method reference documentation- Android SDK
- C# SDK
- Flutter SDK
- Go SDK
- Java SDK
- JavaScript (Browser) SDK
- JavaScript (Node) SDK
- PHP SDK
- Python SDK
- React SDK (
useDecision
hook) - React Native SDK (
useDecision
hook) - Ruby SDK
- Swift SDK
Update to the new methods
- Android SDK
- C# SDK
- Go SDK
- Java SDK
- JavaScript (Browser) SDK
- JavaScript (Node) SDK
- PHP SDK
- Python SDK
- React SDK
- React Native SDK
- Ruby SDK
- Swift SDK
If you encounter any issues transitioning to the decide
API, contact your Customer Success Manager, who will assist you to ensure an effective transition.
Updated 10 months ago