Managing mutually exclusive experiments is a common need when multiple experiments run in parallel. But what happens when some of these experiments are triggered client-side (via Kameleoon Web Experimentation) and others are triggered server-side (via Kameleoon Feature Experimentation)? This is a more advanced use case, but one that Kameleoon supports with the right setup. In this article, we’ll walk you through how to configure a mutually exclusive setup that spans both technologies.Documentation Index
Fetch the complete documentation index at: https://docs.kameleoon.com/llms.txt
Use this file to discover all available pages before exploring further.
The scenario
Suppose you want to run three mutually exclusive experiments:- Two experiments are triggered client-side using Kameleoon Web Experimentation (JavaScript-based).
- One experiment is triggered server-side using Kameleoon Feature Experimentation (for example, via a backend SDK).
Handling this use case
To ensure mutual exclusivity across both client-side and server-side experiments, follow these steps:1. Start with the feature experiment
Since the feature experiment is triggered server-side and requires early targeting (before page load), it’s best to allocate traffic to it first.- Create your Feature Experiment.
- Allocate 33% of the total traffic to this experiment (or any other percentage that matches your testing plan).
2. Create a mutually exclusive group for web experiments
Next, create a Mutually Exclusive Group for the two Web experiments. 👉 Follow this documentation: Prevent overlapping campaigns with Mutually Exclusive Groups. Preventing overlap ensures that visitors can only see one of the two Web experiments—never both.3. Add targeting conditions to exclude feature experiment participants
To ensure that users who are bucketed into the Feature Experiment do not enter either Web experiment, apply the following targeting condition to both Web experiments:- Targeting condition:
Campaigns → Feature Flag→ Exclude visitors who have been exposed to any variation of your “feature_experiment_name”.
4. Technical considerations
By default, Kameleoon Web Experimentation will perform a remote synchronization call on each page load to check whether the user has been exposed to a Feature Experiment. This call is how Kameleoon knows whether to include or exclude a user from a Web experiment. If the three experiments are running on the same page, this setup can be tricky, because the Web engine has to wait for the server-side exposure status before deciding whether to include the user in a Web experiment, which can result in flickering or delayed content.If the Feature Experiment and the Web Experiments are triggered at different moments in the customer journey (for example, on different pages), you’ll also need to add an exclusion targeting condition in the Feature Experiment to exclude visitors who have already been exposed to one of the Web Experiments.
Recommended solution
To eliminate flickering and ensure real-time decision-making, expose the user’s Feature Experiment status directly on the front end, without waiting for a remote call.- Use the SDK method:
getEngineTrackingCode(). - Insert the output in the HTML of the page, ideally in the
<head>section.
Summary
Mutually exclusive testing across client-side and server-side experiments is complex—but fully supported by Kameleoon when implemented correctly. Here’s a quick recap:- Start with the feature experiment and allocate its traffic share first.
- Use mutually exclusive groups to manage overlap between Web experiments.
- Exclude feature experiment participants from Web experiment targeting using campaign conditions.
- Use the tracking code method to eliminate delays and flicker if experiments overlap on the same page.