One visitor One test on FE&R

This article explains how to activate/deactivate the 1 visitor 1 test feature in FE&R campaigns and the prioritization mechanism.

Prerequisites: This option is available if you have implemented the Decision API or are using an SDK in DECISION API mode.

To learn more about it check our Decision API documentation and our SDK documentation.

• This option only affects Experiments (A/B Test). All Personalization and Feature management scenarios will continue to work as expected.

• This option is compatible with Bucket Allocation. Consider that if you put several experiments inside a bucket, your visitors will only see one of those experiments.

Activate One visitor One Test Option on Feature Experimentation and Rollout

• If you activate it while you have active experiments, it might create biases in your campaign results. We advise you to end all pending tests before enabling the option and launching new ones.

• Activating this option while conducting two experiments (one on your home page and another on the cart page) impacts traffic distribution. Visitors who view the home page before the cart will only experience the home page experiment, reducing traffic allocation for the cart experiment. Consequently, gathering adequate statistics for experiments on deeper pages (like product pages or conversion funnels) will take longer. This delay is exacerbated if combined with the bucket allocation feature.

To enable this option:

1

Go to User Profile > Feature Experimentation > Feature Experimentation Settings > Environment Settings.

2

In the Settings section, check the option 1 visitor 1 experiment.

• If you check the option: a visitor will see only one experiment at a time.

• If you uncheck the option: a visitor can see more than one experiment

This option targets the environment (Prod or Preprod). Check this option for all the relevant environments.

How does the prioritization mechanism work on Feature Experimentation and Rollout?

• The Decision API evaluates which campaigns are eligible for a visitor based on their context keys.

• It then sorts the eligible campaigns by creation date, from newest to oldest.

• The first campaign in this list is the one returned by the Decision API for that visitor.

• There is no additional prioritization logic beyond this order.

• If the visitor falls into untracked traffic for the first campaign (i.e., they aren't assigned to it due to traffic allocation), they may still be assigned to the next eligible campaign.

• The feature works the same, whatever the application or device, as long as the visitor stays the same.

• For more randomized traffic distribution, use the Bucket Allocation feature.