Configuration du déploiement d'expériences

Cette compétence répond à : Qui voit quelle variante ?

Approche recommandée : répartition égale + ajuster le pourcentage de déploiement

Dans la plupart des cas, les expériences fonctionnent mieux avec une répartition égale. Si vous voulez limiter l'exposition à la variante de test, ajustez plutôt le pourcentage de déploiement.

Pourquoi les répartitions égales sont meilleures :

• Les répartitions égales maximisent la puissance statistique — chaque variante a la même taille d'échantillon
• Les répartitions égales équilibrent le trafic et atteignent ainsi la significativité plus rapidement
• Augmenter l'exposition des utilisateurs tout au long de l'expérience en augmentant le déploiement est propre (changer la répartition en cours d'expérience peut amener les utilisateurs à basculer entre variantes, ce qui est mauvais pour l'expérience utilisateur et la qualité des données)

Privilégiez toujours une répartition égale sauf si l'utilisateur demande explicitement autrement.

Quand une répartition inégale est nécessaire

Les répartitions inégales combinées à la gestion par défaut « Exclure les utilisateurs multivariés » peuvent introduire un biais. Si l'expérience observe des utilisateurs multi-variantes (utilisateurs exposés à plus d'une variante), ceux-ci sont supprimés asymétriquement — la plus petite variante perd une fraction plus grande de ses attributions. Si ces utilisateurs se comportent différemment du reste, les métriques de la plus petite variante seront faussées.

L'atténuation appropriée dépend de l'état de l'expérience :

1. Avant le lancement, ou en direct mais avec peu d'expositions jusqu'à présent — utilisez une répartition égale et réduisez le déploiement global. Cela donne la même exposition à la variante de test sans le biais et préserve la puissance statistique. Voir la question de désambiguïsation ci-dessous.
2. Expérience en direct avec des expositions significatives — passez la gestion multivariée à « Première variante observée ». Changer la répartition en cours d'exécution réattribue les utilisateurs entre variantes (anti-pattern ; voir « Changer le déploiement sur une expérience en cours » ci-dessous). Basculer la gestion à la place garde tout le monde dans sa variante d'origine et évite l'exclusion asymétrique. Voir configuring-experiment-analytics pour savoir comment définir ceci. Notez que la gestion « first seen » peut introduire d'autres biais, mais c'est préférable à la réattribution en cours d'exécution.

Les deux contrôles de déploiement

Il existe deux contrôles distincts qui déterminent qui voit quoi. Les deux sont définis via parameters.

1. Répartition des variantes (parameters.feature_flag_variants)

Comment les utilisateurs dans l'expérience sont distribués entre variantes.

• Tableau de {key, name, split_percent} — les pourcentages doivent totaliser 100
• La première variante doit avoir la clé "control" — c'est la baseline
• Minimum 2 variantes, maximum 20
• Par défaut : control 50 % / test 50 %

Si l'utilisateur dit « test A/B/C », mappez la baseline à "control" et créez des variantes supplémentaires pour les autres.

2. Déploiement global (parameters.rollout_percentage)

Quel pourcentage de tous les utilisateurs entrent dans l'expérience. Par défaut : 100 %.

Les utilisateurs non inclus sont exclus entièrement — ils ne voient aucune variante et ne font pas partie de l'analyse.

Comment ils interagissent

Ces deux contrôles se multiplient :

La question de désambiguïsation

CRITIQUE : Si l'utilisateur demande une répartition de variantes inégale (p. ex. « 60/40 », « 70/20/10 ») ou mentionne un pourcentage spécifique qui pourrait faire référence à la répartition ou au déploiement (p. ex. « déployer à 25 % »), vous DEVEZ clarifier avant de procéder. Ceci couvre deux cas :

Cas 1 : Pourcentage unique (« 25 % », « déployer à 40 % »)

Le pourcentage est ambigu — il pourrait signifier une répartition de variantes ou un changement de déploiement. Demandez :

Il y a deux façons d'obtenir 25 % des utilisateurs voyant la variante de test :

1. Déploiement réduit avec répartition égale (recommandé) : réduire le déploiement global et répartir les variantes équitablement. Seulement un sous-ensemble d'utilisateurs entre dans l'expérience, et parmi ceux-ci, chaque variante obtient la même part. Les répartitions égales maximisent la puissance statistique et évitent les biais.
2. Répartition asymétrique : conserver 100 % de déploiement mais donner à la variante de test seulement 25 %. Tous les utilisateurs entrent dans l'expérience, mais la répartition inégale réduit la puissance sur la plus petite variante et risque d'introduire un biais.

Quelle approche préférez-vous ?

Ajustez les chiffres pour correspondre au pourcentage demandé par l'utilisateur.

Cas 2 : Ratio inégal (« 60/40 », « 70/30 », « 80/20 », etc.)

Le ratio ressemble à une répartition de variantes explicite, mais une répartition égale avec déploiement réduit est presque toujours meilleure. Expliquez le compromis et recommandez l'alternative :

Une répartition de variantes inégale fonctionne, mais une répartition égale avec déploiement réduit est recommandée :

1. Répartition égale + déploiement réduit (recommandé) : réduire le déploiement global de sorte que la même fraction d'utilisateurs voit la variante de test, mais répartir les variantes équitablement au sein de l'expérience. Les répartitions égales maximisent la puissance statistique et évitent les biais dus à l'exclusion multivariée asymétrique.
2. Répartition inégale. Produit le même résultat du côté utilisateur, mais réduit la puissance sur la plus petite variante et risque d'introduire un biais.

Préférez-vous l'approche de répartition égale, ou avez-vous une raison spécifique pour la répartition inégale ?

Ajustez les chiffres pour correspondre au ratio. Pour les expériences avec plus de deux variantes, « égal » signifie que chaque variante obtient la même part (p. ex. 34/33/33 pour trois variantes). Si l'utilisateur confirme qu'il veut la répartition inégale après avoir vu le compromis, procédez — mais NE SAUTEZ PAS la section suivante.

Après que l'utilisateur choisisse la répartition inégale

Si l'utilisateur procède avec une répartition inégale (option 2 dans l'un ou l'autre cas ci-dessus), vous DEVEZ exposer l'implication de la gestion multivariée AVANT de créer ou mettre à jour l'expérience. L'utilisateur a choisi le chemin de déploiement plus risqué et doit prendre une décision éclairée sur la façon de l'atténuer.

Demandez :

Une dernière chose — avec une répartition inégale, la gestion par défaut « Exclure les utilisateurs multivariés » supprime asymétriquement les utilisateurs exposés à plusieurs variantes. La plus petite variante perd une fraction plus grande de ses attributions, ce qui peut fausser ses métriques si ces utilisateurs se comportent différemment du reste.

Deux options :

1. Basculer la gestion multivariée à « Première variante observée » (recommandé pour les répartitions inégales) — garde tous les utilisateurs dans l'analyse et évite l'exclusion asymétrique. A ses propres avertissements (d'autres biais peuvent s'introduire) mais est préférable au défaut pour les répartitions inégales.
2. Conserver la gestion par défaut « Exclure » et accepter le risque de biais.

Laquelle préférez-vous ?

Voir configuring-experiment-analytics pour savoir comment définir la gestion multivariée. Appliquez le choix dans le cadre de la même opération (création ou mise à jour) — ne laissez pas l'utilisateur avec une répartition inégale sous gestion par défaut sans une décision explicite et éclairée.

Persister le flag à travers les étapes d'authentification

Cette option (ensure_experience_continuity sur le feature flag) n'est pertinente que lorsque :

• Le feature flag est affiché aux utilisateurs à la fois déconnectés ET connectés
• Vous avez besoin de la même attribution de variante avant et après la connexion

Ceci n'est pas compatible avec tous les configurations. En savoir plus : https://posthog.com/docs/feature-flags/creating-feature-flags#persisting-feature-flags-across-authentication-steps

Mentionnez ceci à l'utilisateur seulement si son cas d'usage implique des expériences pré/post-authentification.

Résoudre les expériences

Les changements de déploiement nécessitent un ID d'expérience. Si l'utilisateur se réfère à une expérience par nom ou description (p. ex. « changer le déploiement de mon test d'inscription »), chargez la compétence finding-experiments pour la résoudre à un ID concret avant de procéder.

Changer le déploiement sur une expérience en cours

Tout changement au déploiement ou à la répartition des variantes sur une expérience en cours affecte à la fois l'expérience utilisateur et la validité statistique. Vous DEVEZ avertir l'utilisateur et obtenir une confirmation explicite avant de faire le changement.

NE PAS appliquer silencieusement le changement — même si l'utilisateur l'a demandé directement. Présentez l'avertissement couvrant les deux perspectives :

1. Qui voit quelle variante ? — les utilisateurs vont-ils basculer entre variantes ou perdre une fonctionnalité ?
2. Qui est dans mon analyse ? — comment cela affecte-t-il la qualité des données ?

Exception : Augmenter le déploiement (sans changer la répartition) est généralement sûr — aucun utilisateur ne bascule entre variantes, plus d'utilisateurs sont ajoutés proprement.

Correctif en cours d'expérience pour le biais de répartition inégale : basculer la gestion multivariée de « Exclure » à « Première variante observée » est l'atténuation recommandée pour les expériences déjà lancées — aucun utilisateur ne bascule entre variantes et toutes les données collectées restent dans l'analyse. Changer la répartition pour être égale est un anti-pattern en cours d'exécution (généralement nécessite de réinitialiser ou d'arrêter l'expérience) et n'est préféré que si l'expérience n'a pas été exposée à beaucoup d'utilisateurs. Voir configuring-experiment-analytics pour savoir comment changer la gestion.

Voir references/changing-distribution-after-launch.md pour les avertissements détaillés, ce qu'il faut dire à l'utilisateur, et quand recommander des alternatives.