Skip to main content
This article covers how to configure a mutually exclusive setup that spans both Kameleoon Web Experimentation (client-side) and Kameleoon Feature Experimentation (server-side), when some of your mutually exclusive experiments run on one technology and some run on the other.
For the theory behind mutually exclusive groups, including when Kameleoon assigns visitors to a group and the tradeoffs to weigh first, refer to Mutually exclusive groups.

​
The scenario

Suppose you want to run three mutually exclusive experiments:
  • Two experiments run client-side through Kameleoon Web Experimentation (JavaScript-based).
  • One experiment runs server-side through Kameleoon Feature Experimentation (for example, through a backend SDK).
You need to ensure that visitors are only exposed to one of these experiments, even though different technologies activate them at different stages of the user journey.

​
Set up mutual exclusivity across both technologies

​
1. Start with the feature experiment

The feature experiment runs server-side and requires early targeting, before page load, so allocate traffic to it first.
  1. Create your feature experiment.
  2. Allocate 33% of the total traffic to this experiment, or any other percentage that matches your testing plan.
The remaining 67% of the traffic is then available for the two web experiments.

​
2. Create a mutually exclusive group for the web experiments

Create a mutually exclusive group for the two web experiments by following Create a mutually exclusive group for web experiments. This setup ensures visitors see only one of the two web experiments, never both.

​
3. Exclude feature experiment participants from the web experiments

To keep visitors bucketed into the feature experiment out of either web experiment, apply the following targeting condition to both web experiments:
  • Targeting condition: Campaigns → Feature flag → exclude visitors already exposed to any variation of your feature_experiment_name.
This condition preserves mutual exclusivity across both technologies.

​
4. Account for synchronization timing

By default, Kameleoon Web Experimentation makes a remote synchronization call on each page load to check whether the visitor already saw a feature experiment. Kameleoon uses this call to decide whether to include or exclude the visitor from a web experiment. If all three experiments run on the same page, this setup gets tricky: the web engine has to wait for the server-side exposure status before deciding whether to include the visitor in a web experiment, which can cause flickering or delayed content.
If the feature experiment and the web experiments trigger at different moments in the customer journey, for example on different pages, also add an exclusion targeting condition to the feature experiment that excludes visitors already exposed to one of the web experiments.
To eliminate flickering and decide in real time, expose the visitor’s feature experiment status directly on the front end, without waiting for a remote call.
  1. Use the SDK method getEngineTrackingCode().
  2. Insert the output in the HTML of the page, ideally in the <head> section.
This way, Kameleoon immediately knows whether the visitor already saw the feature experiment. Targeting becomes faster and more seamless as a result.