Comment Configurer des Groupes d'Expériences Mutuellement Exclusifs dans Optimizely

Lorsque des équipes produit et croissance mènent de multiples tests A/B simultanés sur une même page web, un tunnel de commande ou un parcours utilisateur stratégique, le risque de collision de trafic devient critique. Si un visiteur est exposé à deux tests superposés en même temps, les effets d'interaction (Interaction Effects) rendent impossible l'identification du changement ayant généré les conversions. De plus, les distorsions de trafic peuvent déclencher une disparité des ratios d'échantillonnage (Sample Ratio Mismatch, SRM).

Dans Optimizely, la réponse technique à cette problématique repose sur la configuration de Groupes d'Exclusion (Exclusion Groups). Un groupe d'exclusion agit comme un conteneur de trafic qui regroupe plusieurs expériences et segmente l'audience à l'aide d'un algorithme de hachage déterministe partagé. Un utilisateur assigné à l'Expérience A ne sera jamais exposé à l'Expérience B au sein du même groupe.

Quand Utiliser les Groupes d'Exclusion (et Quand les Éviter)

L'exclusion mutuelle préserve la validité statistique des résultats, mais implique un arbitrage direct : la dilution du trafic. Répartir une audience finie entre plusieurs tests réduit la taille de l'échantillon de chaque expérience, ce qui prolonge significativement le temps nécessaire pour atteindre la significativité statistique.

Les équipes d'expérimentation doivent évaluer chaque situation avec discernement :

Fonctionnement Interne de l'Exclusion Mutuelle dans Optimizely

Par défaut, Optimizely évalue chaque expérience de façon autonome. Pour chaque test, la plateforme associe l'identifiant de l'utilisateur (User ID ou Bucketing ID) à l'identifiant de l'expérience (Experiment ID), applique la fonction de hachage déterministe MurmurHash3, et attribue le visiteur à l'un des 10 000 segments de trafic (de 0 à 9 999).

Puisque les tests indépendants reposent sur des bases de calcul différentes, un même internaute peut se retrouver simultanément dans des segments actifs de plusieurs tests concurrents.

Lorsqu'une expérience est rattachée à un Groupe d'Exclusion (Exclusion Group), Optimizely modifie sa méthode de segmentation :

1. Domaine de Hachage Partagé : La fonction de hachage évalue d'abord l'identifiant de l'utilisateur avec l'ID du Groupe d'Exclusion.
2. Cloisonnement Déterministe : Les 10 000 segments sont partagés exclusivement entre les expériences membres en fonction des pourcentages de trafic définis.
3. Isolation Stricte : Si un visiteur tombe dans l'intervalle attribué à l'Expérience A, il n'est éligible qu'à cette dernière, et le système l'exclut d'emblée des Expériences B et C de ce groupe.

Ordre de Priorité et d'Évaluation (Evaluation Order)

Dans Optimizely Feature Experimentation et Web Experimentation, la prise de décision suit une séquence rigoureuse avec évaluation en court-circuit :

1. Statut de la Règle : Vérifie si le flag ou l'expérience est en cours d'exécution.
2. Variations Forcées (Forced Variations) : Priorité maximale (utilisées pour la recette et le débogage).
3. Liste d'Autorisation (User Allowlisting) : Assignation explicite d'identifiants utilisateurs.
4. Service de Profil Utilisateur (User Profile Service, UPS) : Récupère les assignations mémorisées lors de sessions antérieures.
5. Ciblage d'Audience (Audience Targeting) : Vérifie la conformité des attributs utilisateurs avec l'audience ciblée.
6. Évaluation du Groupe d'Exclusion : Vérifie si l'utilisateur est déjà affecté à un autre test du groupe ; si oui, il est exclu.
7. Attribution du Trafic et des Variations (Traffic Allocation) : Assigne l'utilisateur à une variation spécifique (A ou B) selon les pourcentages définis dans l'expérience.

Guide Pas à Pas : Optimizely Web Experimentation

Pour les équipes menant des tests côté client ou sur la couche Edge :

1. Créer le Groupe d'Exclusion

1. Dans le tableau de bord d'Optimizely Web Experimentation, rendez-vous dans la section Experiments.
2. Cliquez sur l'onglet Exclusion Groups. (Remarque : Si votre compte utilise Optimizely Personalization, rendez-vous dans Optimizations > Exclusion Groups).
3. Cliquez sur le bouton Create New Exclusion Group.
4. Saisissez un Nom (Name) explicite (ex. Checkout_Funnel_Q2_Exclusion) et une Description facultative.

2. Ajouter les Expériences et Allouer les Pourcentages de Trafic

1. Sélectionnez les expériences en brouillon à intégrer au groupe.
2. Définissez la répartition du trafic total du groupe entre les différentes expériences :
   • Par exemple, 50% pour l'Expérience 1 et 50% pour l'Expérience 2 ;
   • Ou conservez une part de contrôle non attribuée (ex. 40% pour l'Expérience 1, 40% pour l'Expérience 2 et 20% de réserve).
3. Cliquez sur Create Exclusion Group pour enregistrer.

3. Valider les Critères de Déclenchement

Vérifiez que toutes les expériences regroupées partagent des règles d'URL et des conditions de déclenchement compatibles pour éviter toute asymétrie de distribution.

Guide Pas à Pas : Optimizely Feature Experimentation

Pour les développeurs et ingénieurs opérant côté backend, microservices et applications mobiles :

1. Créer le Groupe dans le Tableau de Bord des Flags

1. Accédez à la section Flags et sélectionnez l'onglet Exclusion Groups.
2. Cliquez sur Create New Exclusion Group.
3. Renseignez le nom et la description du groupe.
4. Choisissez l'environnement cible (Environment, ex. Production ou Staging, les groupes étant strictement rattachés à un environnement).
5. Cliquez sur Create Exclusion Group.

2. Rattacher les Règles d'Expérience au Groupe

1. Retournez dans la liste des Flags et ouvrez le feature flag concerné.
2. Choisissez l'environnement approprié et accédez à l'Experiment Rule.
3. Dans la section Configure Rule, repérez le menu déroulant : "Add this experiment to the following exclusion group".
4. Sélectionnez le groupe d'exclusion créé précédemment.
5. Indiquez la part de trafic du groupe consommée par cette règle.
6. Cliquez sur Save Experiment.
7. Répétez l'opération pour toutes les règles d'expériences devant rester mutuellement exclusives.

3. Configuration Automatisée via l'API REST

Pour les déploiements continus (CI/CD), la gestion peut s'effectuer directement via l'API REST d'Optimizely :

• Création du groupe : POST /v2/groups avec le corps {"name": "Cart_Redesign_Group", "environment_key": "production"}.
• Liaison des règles : PATCH /v2/groups/{group_id} en renseignant le rule_id de l'expérience.
• Audit de configuration : GET /v2/groups pour lister l'ensemble des exclusions actives.

4. Aucun Changement de Code Requis dans le SDK

La logique d'exclusion est transmise via le Datafile (Ruleset) et résolue en mémoire par le SDK. Lorsque l'application exécute client.decide(user_key, flag_key), le SDK effectue les vérifications d'exclusion et l'attribution localement, sans appel réseau additionnel.

Quatre Règles de Gouvernance Incontournables

Afin d'éviter toute corruption de données, déviation statistique ou anomalie de conversion, les équipes doivent appliquer quatre principes fondamentaux :

1. Démarrer les Expériences d'un Groupe de Manière Synchrone

Ne lancez pas l'Expérience 1 aujourd'hui pour n'ajouter l'Expérience 2 que la semaine suivante. Si des visiteurs ont déjà été ventilés au niveau du groupe, tout ajout ultérieur modifie les frontières des segments, ce qui déplace des utilisateurs existants et fausse l'échantillonnage aléatoire.

2. Ne Jamais Modifier un Groupe d'Exclusion en Cours d'Exécution

Dès qu'une expérience du groupe est active en production :

• N'ajoutez aucune nouvelle expérience.
• Ne retirez aucune expérience en cours. Toute modification en cours d'exécution détruit les proportions prévues, déclenche des alertes de disparité des ratios d'échantillonnage (SRM) et invalide l'analyse statistique. Si un test doit s'interrompre plus tôt que prévu, suspendez sa règle au lieu de démanteler le groupe.

3. Garantir la Cohérence du Ciblage d'Audience

Si l'Expérience A vise l'ensemble des utilisateurs sur ordinateur alors que l'Expérience B cible uniquement les mobiles, les regrouper entraîne une perte de trafic importante. La répartition s'opérant au niveau du groupe, les utilisateurs sur ordinateur affectés à l'Expérience B ne verront aucune variation, privant ainsi l'Expérience A d'un volume précieux d'échantillons.

4. Attention à la Priorité du User Profile Service (UPS)

Dans les architectures exploitant un User Profile Service (UPS) pour figer les variations entre sessions, l'interrogation de l'UPS a lieu avant l'évaluation du groupe d'exclusion. Si un visiteur disposait déjà d'une variation enregistrée issue d'un test antérieur, l'UPS renverra cette valeur historique, court-circuitant ainsi l'exclusion mutuelle. Dans ce cas, utilisez l'option OptimizelyDecideOption.IGNORE_USER_PROFILE_SERVICE.

Références

• Use mutual exclusion - Feature Experimentation docs
• How bucketing works - Feature Experimentation docs
• Optimizely's automatic sample ratio mismatch detection