Variantes d'expérimentation

Fragments de tests A/B sans SDK côté client. Déclarez une expérience sur l'inclusion, bext attribue une variante par utilisateur, réécrit le chemin source et met en cache chaque bras indépendamment.

<bext-include src="/partials/hero"
  experiment="hero-redesign"
></bext-include>

L'attribut experiment nomme une expérience configurée. Sur la base de l'affectation de l'utilisateur (cookie collant), bext résout /partials/hero pour le bras de commande, /partials/hero-v2 pour la variante A, /partials/hero-v3 pour la variante B — sans aucune modification de la balise HTML.

Configuration de l'expérience#

Déclarez les expériences dans bext.config.toml :

[[experiments]]
name = "hero-redesign"
cookie = "bext_exp_hero"
cookie_ttl = "30d"
variants = [
  { name = "control",  weight = 50, src_suffix = "" },
  { name = "variant-a", weight = 25, src_suffix = "-v2" },
  { name = "variant-b", weight = 25, src_suffix = "-v3" },
]

Les pondérations sont relatives : il n'est pas nécessaire qu'elles totalisent 100. Le total est recalculé et chaque variante génère du trafic weight / total.

Réécriture des sources#

Le src_suffix est ajouté au src déclaré de l'inclusion :

Vous pouvez organiser le contenu des variantes comme bon vous semble :

• Fichiers séparés : _partials/hero-v2.html, _partials/hero-v3.html.
• Points de terminaison séparés : /cms/hero?variant=v2, /cms/hero?variant=v3.
• Accessoires de composant : combinez experiment avec render="v8" et props dérivés du nom de la variante.

Logique d'affectation#

Priorité d'affectation (premier match gagné) :

1. Remplacement du paramètre de requête (pour le débogage) : ?exp_override_hero-redesign=variant-a.
2. Cookie existant : lu à partir du cookie exp_hero de la requête, utilisez cette variante.
3. Hachage stable : si l'utilisateur est authentifié, hacher son identifiant ; sinon, hachez les en-têtes et le chemin de la demande. Utilisez le hachage % total_weight pour choisir une variante.

L'affectation est déterministe :

• Le même utilisateur obtient toujours la même variante (au fil des sessions, via cookie).
• La même empreinte digitale anonyme obtient toujours la même variante (au cours d'une session).
• La modification du cookie efface l'affectation – utile pour le contrôle qualité.

Le cookie d'affectation est écrit sur la réponse, donc la première requête établit l'affectation persistante.

Mise en cache par variante#

Les expériences s'injectent automatiquement sous forme de dimension variable :

<bext-include src="/partials/hero"
  experiment="hero-redesign"
  ttl="1h"
></bext-include>

Est équivalent à :

<bext-include src="/partials/hero"
  experiment="hero-redesign"
  ttl="1h"
  vary="experiment:hero-redesign"
></bext-include>

Chaque bras de variante obtient sa propre entrée de cache. Le contrôle, la variante-a et la variante-b sont mis en cache indépendamment — pas de pollution entre variantes.

Combinaison avec auth et varie#

Les expériences s'empilent clairement avec d'autres attributs :

<bext-include
  src="/partials/pricing"
  experiment="pricing-test"
  auth="required"
  vary="role,locale"
  ttl="10m"
></bext-include>

La clé de cache inclut la variante d'expérience, le rôle et les paramètres régionaux. Vous obtenez :

• pricing-control × admin × en (mis en cache)
• pricing-variant-a × admin × en (mis en cache)
• pricing-control × viewer × fr (mis en cache)
• …etc

Chaque combinaison est mise en cache séparément ; chaque utilisateur voit son expérience cohérente.

Remplacement manuel pour le débogage#

Ajoutez un paramètre de requête pour forcer une variante :

https://example.com/page?exp_override_hero-redesign=variant-a

Cela contourne les cookies et la logique d’affectation – utile pour le contrôle qualité, les captures d’écran et les tests internes. Le remplacement de ne définit pas de cookie pour, il est donc éphémère pour la requête en cours uniquement.

Analytique#

Chaque résolution d'inclusion dans le cadre d'une expérience émet un événement :

{
  "event": "bext.include.experiment",
  "experiment": "hero-redesign",
  "variant": "variant-a",
  "src_original": "/partials/hero",
  "src_resolved": "/partials/hero-v2",
  "user_id": "user-42"
}

Introduisez cela dans votre pipeline d'analyse (Segment, PostHog, personnalisé) via un plugin d'analyse bext pour mesurer l'impact de la conversion par variante.

Déployer un gagnant#

Pour promouvoir une variante gagnante à 100 % :

[[experiments]]
name = "hero-redesign"
cookie = "bext_exp_hero"
cookie_ttl = "30d"
variants = [
  { name = "winner", weight = 100, src_suffix = "-v2" },
]

Tous les utilisateurs se voient attribuer winner et voient /partials/hero-v2. Une fois que vous êtes sûr de vous, mettez à jour les fichiers sources (renommez hero-v2.html → hero.html avec le suffixe vide) et supprimez l'expérience.

Variantes pour les tests A/A/A#

Les tests A/A vérifient que votre cadre d'expérimentation n'introduit pas de biais. Déclarez des variantes identiques avec des noms différents :

[[experiments]]
name = "aaa-sanity-check"
variants = [
  { name = "a1", weight = 33, src_suffix = "" },
  { name = "a2", weight = 33, src_suffix = "" },
  { name = "a3", weight = 34, src_suffix = "" },
]

Tous trois aboutissent au même contenu ; la seule différence est le nom de la variante enregistré dans Analytics. Utilisez-le pour valider que les mesures de conversion entre les variantes sont statistiquement impossibles à distinguer.

Voir aussi#

• La mise en cache inclut — le cycle de vie du cache interagit avec les variantes
• Mise en cache adaptée aux variations : comment les variantes d'expérience deviennent des dimensions variables
• Les inclusions authentifiées — expériences + authentification
• Indicateurs de fonctionnalités — pour les déploiements booléens sans variante