The availability of features may depend on your plan type. Contact your Customer Success Manager if you have any questions.

Dev guideAPI ReferenceUser Guide
Dev guideRecipesAPI Reference
Dev guideAPI ReferenceUser GuideLegal TermsGitHubDev CommunityOptimizely AcademySubmit a ticketLog In
Dev guide
Legal TermsGitHubDev CommunityOptimizely AcademySubmit a ticket

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.

Suggest Edits

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 the getEnabledFeatures 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 and decideAll method calls using the DISABLE_DECISION_EVENT option.

decide method reference documentation

decideAll method reference documentation

Update to the new methods

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 9 months ago