Expérimentation A/B

Pro Feature

Définissez une expérience dans le tableau de bord, intégrez une ligne de JavaScript sur votre site, et Zenovay affecte de manière déterministe une variante à chaque visiteur, puis rapporte les taux de conversion par variante ainsi qu'un intervalle de confiance à 95 % sur le gain par rapport à la variante de contrôle.

---

Comment ça marche

L'affectation d'un visiteur est calculée localement par le tracker à l'aide d'un hachage déterministe de l'identifiant visiteur, de sorte qu'un même visiteur voit toujours la même variante — y compris après un rechargement de page, et (lorsque les cookies sont activés) entre les sessions. En mode cookieless (par défaut pour les sites qui chargent le tracker avec data-cookieless="true"), l'affectation est limitée à la fenêtre et se réinitialise à la fermeture de l'onglet.

---

Configurer une expérience

1. Dans le tableau de bord, ouvrez votre site → onglet Experiments → New experiment.
2. Nommez l'expérience, décrivez éventuellement une hypothèse, puis sélectionnez un objectif cible parmi vos objectifs personnalisés existants.
3. Ajoutez 2 à N variantes, désignez-en une comme contrôle, et définissez un pourcentage de répartition du trafic par variante.
4. Enregistrez en brouillon, puis cliquez sur Launch quand vous êtes prêt·e.

---

Intégrer le code

const variant = window.zenovay('experiment', 'checkout-cta-color', ['control', 'green', 'orange']);
if (variant === 'green')   document.querySelector('.cta').style.background = '#22c55e';
if (variant === 'orange')  document.querySelector('.cta').style.background = '#f97316';

C'est l'intégration côté client dans son intégralité. Le tracker gère automatiquement l'affectation, la journalisation des expositions et l'attribution des conversions — lorsque le visiteur déclenche ensuite l'objectif cible (via votre appel existant de suivi d'objectif), Zenovay attribue la conversion à la variante qui lui était assignée.

L'appel window.zenovay('experiment', …) est idempotent — l'appeler plusieurs fois sur la même page renvoie la même variante et ne consigne qu'une exposition par visiteur, par expérience, par session. Transmettez toujours le même tableau variants dans le même ordre sur l'ensemble de vos pages ; l'ordre fait partie du hachage déterministe.

---

Exemples par framework

Le snippet ci-dessus est du JavaScript pur et fonctionne dans n'importe quel environnement de navigateur. Voici les patterns spécifiques aux stacks les plus courantes.

HTML pur

Placez ce code n'importe où sous la balise <script> du tracker Zenovay :

<button class="cta">Buy now</button>

<script>
  // Wait for the tracker to load (it sets window.zenovay on init).
  function applyVariant() {
    if (!window.zenovay) { setTimeout(applyVariant, 50); return; }
    var variant = window.zenovay('experiment', 'checkout-cta-color', ['control', 'green', 'orange']);
    var cta = document.querySelector('.cta');
    if (variant === 'green')  cta.style.background = '#22c55e';
    if (variant === 'orange') cta.style.background = '#f97316';
  }
  applyVariant();
</script>

React / Next.js (client component)

Dans Next.js App Router, marquez le composant 'use client' et appelez la fonction depuis useEffect pour que l'affectation s'exécute après l'hydratation :

'use client';
import { useEffect, useState } from 'react';

export default function CheckoutCTA() {
  const [variant, setVariant] = useState('control');

  useEffect(() => {
    if (typeof window === 'undefined' || !window.zenovay) return;
    const v = window.zenovay('experiment', 'checkout-cta-color', ['control', 'green', 'orange']);
    setVariant(v);
  }, []);

  const bg = variant === 'green' ? '#22c55e' : variant === 'orange' ? '#f97316' : undefined;
  return <button className="cta" style={{ background: bg }}>Buy now</button>;
}

Pour réduire un éventuel flash de la variante de contrôle au premier rendu, affichez la variante de contrôle par défaut et laissez useEffect injecter le traitement après le montage. L'exposition est journalisée au premier appel à window.zenovay('experiment', …).

Vue / Nuxt

Dans un composant <script setup>, déclenchez l'appel depuis onMounted :

<script setup>
import { ref, onMounted } from 'vue';

const variant = ref('control');

onMounted(() => {
  if (!window.zenovay) return;
  variant.value = window.zenovay('experiment', 'checkout-cta-color', ['control', 'green', 'orange']);
});
</script>

<template>
  <button
    class="cta"
    :style="{ background: variant === 'green' ? '#22c55e' : variant === 'orange' ? '#f97316' : null }"
  >
    Buy now
  </button>
</template>

Rendu côté serveur (Next.js, Remix, Nuxt SSR)

L'affectation des variantes est limitée à la fenêtre — le tracker n'existe que dans le navigateur, donc tout appel côté serveur renvoie undefined et la branche de contrôle est rendue lors du premier passage SSR. Le visiteur voit ensuite brièvement la variante traitement, après ré-exécution du useEffect côté client.

Deux patterns pratiques :

1. Accepter le flash de contrôle. Pour des changements visuels (couleur, texte), c'est en général sans conséquence — la bascule reste invisible à la vitesse d'hydratation habituelle.
2. Rendre la variante traitement uniquement côté client. Encapsulez le bloc expérimental dans une frontière client-only afin que le SSR n'émette rien et que le traitement s'affiche une seule fois lors de l'hydratation. Cela supprime le flash au prix d'un décalage de mise en page.

'use client';
import dynamic from 'next/dynamic';

const ExperimentalCTA = dynamic(() => import('./CheckoutCTA'), { ssr: false });

export default function Page() {
  return <ExperimentalCTA />;
}

Aucun endpoint d'affectation côté serveur ou edge n'existe en V1.

Google Tag Manager (GTM)

Encapsulez l'appel dans une balise Custom HTML qui se déclenche après votre balise tracker Zenovay, et poussez la variante vers le dataLayer pour que d'autres balises GTM puissent la lire :

<script>
  (function () {
    if (!window.zenovay) return;
    var variant = window.zenovay('experiment', 'checkout-cta-color', ['control', 'green', 'orange']);
    window.dataLayer = window.dataLayer || [];
    window.dataLayer.push({ event: 'zenovay_experiment', experiment_id: 'checkout-cta-color', variant: variant });
  })();
</script>

D'autres balises GTM (par exemple une balise de réécriture CSS) peuvent alors se déclencher sur l'événement zenovay_experiment et lire {{ DLV - variant }} pour appliquer la modification visuelle.

---

Comment la signification est calculée

Les taux de conversion par variante sont agrégés côté serveur. Le tableau de bord affiche un test z bilatéral à deux proportions pour chaque traitement comparé au contrôle, avec une correction de Bonferroni sur l'ensemble des comparaisons de l'expérience. Un badge « winner » apparaît dès lors que toutes les conditions suivantes sont vraies :

• p-value corrigée par Bonferroni < 0,05
• Les deux variantes atteignent au moins la taille d'échantillon minimale configurée (par défaut : 100 visiteurs par variante)
• L'écart de performance du traitement par rapport au contrôle est positif

Il s'agit d'un test fréquentiste à taille d'échantillon fixe. Ce n'est pas un test séquentiel — consulter les résultats avant la fin de l'expérience augmente le risque d'erreur de type I.

---

Lire le tableau de bord

Le tableau de bord Experiments affiche une ligne récapitulative par variante :

Le graphique en dessous trace le taux de conversion cumulé par variante au fil du temps, pour repérer le moment où les variantes commencent à diverger (ou si elles évoluent encore en parallèle).

---

Workflow recommandé

1. Un seul changement par expérience. Si vous modifiez simultanément la couleur du CTA et le titre, vous ne pourrez pas savoir lequel a fait bouger la métrique. Maintenez tout le reste constant.
2. Choisissez l'objectif avant de lancer. Ajouter ou changer l'objectif cible en cours d'expérience invalide toutes les données collectées jusque-là — Zenovay vous avertira et exigera un relancement.
3. Estimez la taille d'échantillon nécessaire. Un lift de 5 % sur un taux de conversion de référence de 2 % nécessite typiquement environ 30 000 visiteurs par variante pour atteindre la signification. Utilisez un calculateur de taille d'échantillon avant le lancement, et ne lancez que des expériences que votre trafic peut réellement mener à terme.
4. Ne guettez pas les gagnants. Le test fréquentiste n'est valide que si vous définissez une règle d'arrêt à l'avance. Consulter le tableau de bord quotidiennement et stopper dès qu'un traitement franchit p < 0,05 augmente fortement votre taux de faux positifs.
5. Archivez — ne supprimez pas. Une fois l'expérience terminée, archivez-la depuis le menu. Supprimer efface aussi les affectations historiques qui alimentent les rapports de tunnel ou de revenu en aval.

---

Limites par plan

---

Confidentialité et conformité

L'expérimentation A/B est conçue pour respecter la posture de confidentialité de Zenovay :

• Mode cookieless : l'affectation des variantes est limitée à la fenêtre (uniquement en mémoire). Aucun nouveau cookie ni aucune entrée localStorage n'est créé.
• Les données d'affectation des variantes sont incluses dans votre export de données personnelles gratuit au titre de l'article 20 du RGPD.
• La suppression d'un compte se propage en cascade aux expériences, variantes et affectations.
• La rétention suit votre niveau d'abonnement (Free 365 jours, Pro 730 jours, Scale 1 460 jours).

---

Ce qui n'est pas dans la V1

• Bandits manchots multiples, échantillonnage de Thompson, intervalles de crédibilité bayésiens — fréquentiste uniquement.
• p-values séquentielles / always-valid — taille d'échantillon fixe uniquement.
• Décision de variante côté serveur / edge — l'affectation se fait côté client.
• Règles de ciblage (géolocalisation, appareil, visiteurs récurrents uniquement) — affectation aléatoire uniquement.
• Groupes d'expériences mutuellement exclusifs.

---

Dépannage

Mes variantes renvoient toujours null ou toujours control

Causes probables, par fréquence :

1. Le tracker n'avait pas fini de se charger lors de l'appel à window.zenovay(...). La fonction window.zenovay est définie de façon synchrone par le stub de chargement mais n'est exploitable qu'une fois le bundle du tracker téléchargé. Les appels antérieurs renvoient undefined. Encapsulez l'appel dans une petite boucle d'attente (voir l'exemple HTML) ou exécutez-le depuis un hook de cycle de vie du framework, après le montage.
2. L'expérience n'est pas au statut running. Le tracker n'affecte de variantes que pour les expériences dont le statut est running. Les brouillons ou les expériences en pause renvoient la variante de contrôle. Ouvrez l'onglet Experiments et vérifiez le badge de statut.
3. Vous avez transmis un tableau de variantes différent de celui configuré dans le tableau de bord. Les variantes listées dans window.zenovay(...) doivent correspondre exactement aux slugs du tableau de bord (ordre compris). Une coquille comme ['control', 'gren'] envoie tous les visiteurs vers la variante de contrôle.
4. Mode cookieless + fermeture d'onglet. Si votre site charge le tracker avec data-cookieless="true", l'identifiant visiteur est limité à la fenêtre — fermer puis rouvrir l'onglet compte comme un nouveau visiteur et peut conduire à une variante différente. C'est attendu et statistiquement valide.

Aucune exposition n'est enregistrée après le lancement

1. Le tracker n'est pas chargé sur la page où vous appelez experiment(). Vérifiez dans DevTools que window.zenovay est défini sur la page concernée. Si c'est undefined, le <script> du tracker Zenovay n'est pas présent ou n'a pas encore été exécuté.
2. L'expérience est toujours en draft. Cliquez sur Launch depuis l'écran de détail de l'expérience — les brouillons n'enregistrent pas d'expositions.
3. Un bloqueur de publicités intercepte la requête. Peu fréquent, mais possible si vous n'utilisez pas un domaine first-party. Passez au tracking first-party (sous-domaine personnalisé) si votre audience utilise massivement des bloqueurs.

L'attribution de conversions affiche 0 alors que des expositions sont visibles

1. Mauvaise correspondance d'ID d'objectif. L'objectif cible choisi lors de la création de l'expérience doit être le même que celui que votre code (ou l'auto-tracking de Zenovay) déclenche réellement. Vérifiez le slug d'objectif dans le tableau de bord et confirmez le déclenchement dans le flux en direct.
2. La conversion survient avant l'affectation. Très rare, mais possible si votre CTA déclenche l'objectif au chargement initial et que vous appelez experiment() avec un délai. Appelez experiment() le plus tôt possible (juste après le stub du tracker).
3. Le visiteur a converti dans un autre navigateur / appareil / onglet que lors de l'affectation. En mode cookieless, l'affectation ne persiste pas entre onglets — pas plus que le lien de conversion. Le visiteur est alors compté comme deux participants distincts.

L'avertissement de Sample-Ratio Mismatch ne disparaît pas

Le sample-ratio mismatch (SRM) traduit un écart entre la répartition de trafic configurée et celle réellement observée — pour une expérience 50/50, observer 60/40 est un signal d'alerte.

1. Une variante échoue. Si le JavaScript de votre traitement lève une exception avant que le visiteur n'atteigne le chemin de conversion, moins de conversions lui seront attribuées — mais le nombre d'expositions devrait rester équilibré. Surveillez votre tracker d'erreurs pour une hausse corrélée au lancement.
2. Trafic de bots biaisé dans un bucket. Les bots qui partagent une famille d'identifiants visiteurs (par exemple des fermes de crawlers avec des IP non aléatoires) peuvent se retrouver sur-représentés dans une variante. Le filtre B2B/bot de l'onglet Visitors permet de quantifier le phénomène.
3. Vous avez lancé, modifié la liste des variantes, puis relancé. Modifier l'ordre des variantes dans votre appel client après lancement perturbe le hachage déterministe. Relancez toujours une nouvelle expérience si vous changez la liste des variantes.

Si le SRM persiste au-delà de 24 heures avec un trafic sain, mettez l'expérience en pause et ouvrez un ticket de support.

---

FAQ

Comment lancer un test A/B sur mon site avec Zenovay ?

Trois étapes : créez un objectif à optimiser, définissez une expérience avec au moins deux variantes dans l'onglet Experiments, puis collez une ligne de JavaScript sur la page où la variante doit s'appliquer. Le tracker Zenovay s'occupe de l'affectation aléatoire, du journal des expositions et de l'attribution des conversions. Le détail complet figure dans la section « Configurer une expérience » plus haut.

Comment ajouter le code de suivi pour les variantes A/B ?

Le tracker Zenovay est déjà sur votre page si vous avez installé l'analytics. Ajoutez simplement une ligne là où la variante doit s'afficher :

const variant = window.zenovay('experiment', 'your-experiment-id', ['control', 'treatment-a', 'treatment-b']);

Faites ensuite varier votre style, votre texte ou votre composant selon la valeur renvoyée. Aucun SDK supplémentaire à installer.

Comment Zenovay choisit-il la variante affichée à un visiteur ?

L'affectation est un hachage déterministe de l'identifiant visiteur modulo les poids de répartition de trafic configurés. Le même identifiant visiteur produit toujours la même variante pour un identifiant d'expérience donné — la cohérence est préservée d'un chargement à l'autre et (si les cookies sont activés) d'une session à l'autre.

Pourquoi mon affectation de variante est-elle vide ou null ?

Cause la plus fréquente : vous appelez window.zenovay('experiment', …) avant que le tracker n'ait fini de charger. La fonction est définie immédiatement, mais ne renvoie une variante réelle qu'une fois le bundle prêt. Encapsulez l'appel dans un hook de cycle de vie du framework (useEffect, onMounted) ou un petit setTimeout. Voir la section Dépannage pour la liste complète.

Comment vérifier la signification statistique ?

Ouvrez la page de détail de l'expérience. Chaque ligne de traitement affiche une p-value corrigée par Bonferroni par rapport à la variante de contrôle. Un badge winner vert apparaît lorsque la p-value est inférieure à 0,05, que les deux variantes comptent au moins 100 visiteurs, et que le traitement présente un lift positif sur la contrôle.

Quand mettre fin à mon expérience ?

Décidez d'une règle d'arrêt avant le lancement : soit un budget de visites fixe (par exemple « arrêt à 30 000 visiteurs par variante »), soit une date de fin fixe. Arrêtez l'expérience lorsque cette règle est atteinte, indépendamment de ce qu'affiche le tableau de bord. S'arrêter parce qu'un traitement « semble gagner » gonfle fortement le taux de faux positifs.

Que se passe-t-il si j'atteins la limite de mon plan (par exemple 5/5 sur Pro) ?

Vous ne pouvez pas lancer de nouvelle expérience tant que vous n'en avez pas archivé une. Les brouillons ne comptent pas dans la limite — seules les expériences au statut running. Les expériences archivées conservent leurs affectations et conversions historiques ; elles ne comptent simplement plus dans le quota concurrent.

Comment cloner une expérience ou la relancer avec un texte différent ?

Ouvrez l'expérience d'origine, cliquez sur l'icône de menu (⋯), choisissez Clone. La nouvelle expérience hérite de l'objectif, de la liste des variantes et de la répartition de trafic — modifiez ce qu'il faut puis Launch. L'expérience clonée reçoit son propre identifiant, donc les visiteurs sont réaffectés indépendamment de l'original.

Puis-je modifier une expérience après son lancement ?

Seules les expériences au statut draft sont entièrement modifiables. Après Launch, l'expérience est verrouillée : vous pouvez la mettre en pause, l'archiver ou y mettre fin, mais vous ne pouvez plus en changer les variantes, la répartition de trafic ou l'objectif cible sans invalider la collecte. Si une modification est nécessaire, terminez puis clonez.

Comment les conversions sont-elles attribuées à une variante ?

L'attribution est automatique. Lorsqu'un visiteur déclenche l'objectif cible (via l'auto-tracking de Zenovay ou votre appel window.zenovay('event', 'goal-slug')), Zenovay retrouve la variante qui lui avait été assignée pour les expériences en cours et y impute la conversion. Aucun code d'attribution manuel n'est requis.

Qu'est-ce que la correction de Bonferroni et pourquoi mon plan Pro l'utilise ?

Lorsque vous comparez plusieurs traitements à une variante de contrôle, appliquer naïvement un seuil unique de p < 0,05 par comparaison gonfle la probabilité de faux positif (effet « look-elsewhere »). La correction de Bonferroni divise le seuil par le nombre de comparaisons — pour une expérience avec trois traitements contre une contrôle, chaque comparaison doit atteindre p < 0,05 / 3 ≈ 0,017. Tous les plans Zenovay qui prennent en charge le A/B testing appliquent Bonferroni ; ce n'est pas exclusif à Pro, c'est la méthode commune à tous les tiers payants.

Qu'est-ce que le SRM et quand s'en inquiéter ?

Le Sample-Ratio Mismatch (SRM) mesure l'écart entre votre répartition de trafic configurée et celle effectivement observée. Pour une expérience 50/50, 50,3/49,7 est sain, mais 60/40 avec un échantillon conséquent signale un problème de déploiement ou d'affectation. Inquiétez-vous au-delà de ~5 points de pourcentage par rapport à la cible une fois les ~10 000 premiers visiteurs atteints. Le tableau de bord le signale automatiquement.

Mode cookieless + tests A/B — est-ce que ça fonctionne ?

Oui. Le hachage déterministe utilise l'identifiant visiteur configuré dans le tracker — un identifiant de cookie stable si les cookies sont activés, un identifiant en mémoire limité à la fenêtre en mode cookieless. Le modèle statistique reste inchangé ; la seule différence pratique est qu'un visiteur cookieless qui ferme et rouvre l'onglet est réaffecté de manière indépendante. C'est normal et ça n'invalide pas l'expérience.

---

Étapes suivantes

• Objectifs – Définissez les événements que votre expérience mesurera
• Tunnels de conversion – Suivez des parcours de conversion en plusieurs étapes
• Conversion Incidents – Soyez alerté·e lorsque l'objectif cible d'une expérience chute