Expériences (tests A/B)

Une expérience dans Kilden n’est pas un second répartiteur de trafic. C’est une lentille sur un feature flag multivariant que vous avez déjà : le flag continue de décider qui voit quoi, exactement comme avant, et l’expérience lit les expositions que votre SDK envoie déjà pour vous dire si la différence est réelle.

Cela a deux conséquences qu’il vaut mieux connaître d’emblée. Démarrer une expérience ne change rien à ce que vos utilisateurs voient. Et n’importe quel flag avec au moins deux variantes est déjà mesurable : vous n’avez rien de nouveau à instrumenter.

Avant de commencer

Une expérience a besoin de :

• Un flag multivariant avec au moins deux variantes, dont une marquée comme contrôle.
• Que votre code interroge réellement le flag. Les expositions viennent de getFeatureFlag() / isFeatureEnabled(). Si votre code branche sans appeler l’un des deux, l’expérience ne mesure rien — et elle le dit.
• Un événement cible : ce dont vous voulez davantage. Conversion (cette personne l’a-t-elle fait au moins une fois ?) ou une valeur par personne (une somme, ou un décompte).

// C'est cet appel qui place la personne dans l'expérience.
const variant = await kilden.getFeatureFlag('checkout_flow');

if (variant === 'one_step') {
  renderOneStepCheckout();
} else {
  renderClassicCheckout();
}

Le SDK envoie une exposition par flag et par session ; l’analyse retient la première variante vue par chaque personne.

En créer une

Expériences → Nouvelle expérience, en trois étapes : l’hypothèse, le flag et son contrôle, et ce qui compte comme succès.

La dernière étape estime la durée nécessaire au test à partir du trafic récent du flag lui-même. Si la réponse est « huit mois », elle le dit avant que vous ne lanciez, pas après : la façon la plus courante dont un test A/B échoue est de ne pas pouvoir détecter l’effet qu’il cherchait.

Pendant qu’une expérience tourne, la répartition du flag est gelée. Changer les poids en cours de route mélange deux configurations d’assignation différentes sous un seul résultat, la façon la plus silencieuse de ruiner un test. Mettez l’expérience en pause si vous devez modifier le flag.

Lire les résultats

La page s’ouvre sur un verdict en toutes lettres, et tout ce qui se trouve en dessous existe pour que vous puissiez l’auditer.

Pourquoi une probabilité et pas une p-valeur

Kilden rapporte « B bat le contrôle avec 91 % de probabilité ». C’est une affirmation bayésienne sur cette expérience, et elle signifie exactement ce qu’elle semble signifier.

Une p-valeur, non. Elle répond à une autre question (« à quel point ces données seraient-elles surprenantes s’il n’y avait aucune différence ? »), elle est régulièrement lue comme la probabilité d’avoir raison, et elle punit précisément le comportement qu’a toute équipe réelle : regarder les résultats tous les jours. Sous observation continue, une règle de décision fondée sur la p-valeur gonfle sévèrement les faux positifs. La lecture bayésienne se dégrade bien mieux.

À côté, vous obtenez :

• L’intervalle crédible — la plage où l’effet réel vit plausiblement. Kilden n’affiche jamais un uplift sans lui.
• La perte attendue — ce que vous abandonnez en moyenne si vous choisissez cette variante et que vous aviez tort. C’est le chiffre qui répond vraiment à « est-ce sûr de le déployer ? ».

Le graphique d’effet

Une ligne par variante, avec l’uplift contre le contrôle et son intervalle crédible à 95 %. Le zéro est toujours dans le cadre, et un intervalle qui traverse le zéro est dessiné en gris neutre — parce qu’un effet qui pourrait être positif comme négatif n’est pas encore un résultat.

Ce n’est délibérément pas un graphique en barres des taux de conversion : les barres invitent à l’axe tronqué qui transforme 2,1 % contre 2,3 % en montagne.

Les courbes a posteriori

Les distributions de ce que pourrait être le taux réel de chaque variante. Le chevauchement est l’incertitude : deux courbes l’une sur l’autre signifient que vous ne pouvez pas encore les distinguer, quoi que dise le chiffre en tête.

Évolution

La probabilité de battre le contrôle, jour après jour, calculée uniquement avec ce que l’on savait chaque jour. Voir cette ligne franchir les 95 % tôt puis retomber est l’argument le plus clair qui soit contre l’arrêt dès que le résultat a l’air bon.

Les diagnostics de validité

Trois contrôles tournent sur chaque expérience. Un résultat qui les échoue est pire qu’aucun résultat, parce qu’il a l’air tout aussi convaincant — donc Kilden ne rapporte pas de gagnant quand ils échouent, il n’adoucit pas la lecture.

Répartition (SRM)

Compare le trafic réellement reçu par chaque bras à celui que le flag était configuré pour envoyer. Un écart signifie que quelque chose a cassé l’assignation : un filtre anti-bots asymétrique, un changement de poids en cours de route, ou une intégration qui n’interroge le flag que sur une branche. Toute conclusion bâtie là-dessus est du bruit.

Contamination

Les personnes ayant vu plus d’une variante. Cela arrive surtout quand des visiteurs anonymes s’identifient en cours de test : le bucket dépend de l’identifiant, donc changer d’identifiant peut les faire changer de bras.

Kilden les exclut de l’analyse et rapporte le taux au lieu de corriger en silence. Au-dessus de 2 %, le résultat est marqué comme compromis. L’exclusion a son propre biais — elle écarte ceux qui se sont connectés pendant le test — et c’est un problème plus petit et visible, contre un invisible.

Échantillon

Chaque bras a besoin d’au moins 100 personnes avant qu’une inférence ne soit rapportée, et le verdict suit la progression vers l’échantillon qu’implique votre MDE.

C’est là que vous rencontrerez la différence entre en tête et décisif. Un bras peut franchir les 95 % au troisième jour avec un quart de l’échantillon : les effets réels comme le bruit pur font cela. Kilden dit en tête, indique combien d’échantillon manque, et vous laisse quand même conclure — la décision est la vôtre, l’outil refuse seulement de faire comme si le test était terminé.

Conclure

Conclure fige les résultats tels qu’ils sont, comme la preuve derrière la décision, avec ce que vous écrivez sur les raisons de ce choix. Cet instantané n’est jamais recalculé : les données en dessous bougent — fusions, rétention, backfills — et un chiffre qui change après la décision n’est pas une preuve.

Conclure ne modifie pas votre flag. Déployer le gagnant à 100 % est une action distincte et explicite, avec la traçabilité propre au flag. Kilden ne change jamais le comportement de votre produit de lui-même.

Limites en v1

• Trafic navigateur uniquement. Les SDK server-side n’émettent pas encore d’événements d’exposition, par choix.
• Un seul événement cible comme métrique principale ; les tunnels multi-étapes sont approchés par la dernière étape.
• Les métriques de revenu sont winsorisées au 99e centile avant comparaison, pour qu’une commande énorme ne déplace pas la moyenne. La page indique combien de valeurs cela a touché.