Configuration de test A/B — Lancez des tests qui fonctionnent vraiment — Claude Skill
Une compétence Claude pour Claude Code par Corey Haines — exécuter /ab-test-setup dans Claude·Mis à jour le 14 juin 2026·v1.1.0
Concevez des tests A/B statistiquement valides qui produisent des résultats actionnables
- Rédiger des hypothèses structurées avec des indicateurs de succès clairs
- Calculer les tailles d'échantillon et les durées de test avant le lancement
- Concevoir le contrôle et les variantes de copy pour n'importe quel élément de page
- Définir les métriques principales, secondaires et garde-fous
- Analyser les résultats avec significativité statistique et découpes par segment
Pour qui
Vous lancez des expériences, optimisez les parcours d'acquisition et suivez les chiffres de l'inscription au revenu.
Voir les compétences de ce rôleVous gérez le positionnement, les lancements et le parcours acheteur. Ces compétences aident à écrire, pricer et lancer avec précision.
Voir les compétences de ce rôleVous pilotez la génération d'opportunités : publicités payantes, séquences e-mail, lead magnets et optimisation des formulaires.
Voir les compétences de ce rôleCe qu'il fait
Conçoit l'hypothèse, calcule le trafic requis, définit les variantes de CTA et met en place la mesure pour une expérience sur page pricing
Analyse les données de test existantes, détecte les erreurs de consultation prématurée et recommande d'étendre, d'arrêter ou de reconcevoir l'expérience
Crée un modèle de documentation de test et un cadre de priorisation pour les équipes qui débutent avec les tests A/B structurés
Fonctionnement
Indiquez ce que vous voulez tester et votre taux de conversion de référence actuel
Le skill rédige une hypothèse structurée avec résultat attendu et audience
Il calcule la taille minimale d'échantillon et la durée attendue du test
Il définit les métriques, la répartition du trafic et la checklist QA avant lancement
Après le test, il analyse les résultats et documente les apprentissages
Exemple
Objectif : augmenter les démarrages d'essai depuis la page tarifs. Base actuelle : 4,8 % des visiteurs de la page tarifs démarrent un essai. Trafic : environ 8 000 visiteurs de la page tarifs par semaine. Audience : nouveaux visiteurs aux États-Unis, desktop et mobile. Changement proposé : remplacer le CTA « Start free trial » par « Build my first dashboard » et ajouter trois bénéfices au-dessus du bouton. Outils : Optimizely pour l'expérience, GA4 pour le suivi des conversions. Besoin : hypothèse de test, taille d'échantillon, durée, métriques, checklist QA et règles de décision.
Il faut traiter cela comme un test de message, pas comme un simple test de couleur de bouton. La variante change à la fois la promesse du CTA et les bénéfices de soutien. Si vous devez savoir quel élément crée l'amélioration, séparez cela en deux tests. Si la décision métier est seulement de savoir si le nouveau bloc de message gagne, gardez-le comme un A/B test groupé.
Parce que les visiteurs de la page tarifs ne comprennent peut-être pas ce qu'ils obtiennent après le démarrage de l'essai, nous pensons qu'un CTA orienté résultat concret avec trois bénéfices augmentera le taux de démarrage d'essai pour les nouveaux visiteurs US. Nous validerons l'hypothèse si le taux de démarrage d'essai progresse d'au moins 20 % par rapport à la base de 4,8 %, sans dégrader la complétion d'inscription ni la qualité d'activation.
| Élément | Plan | |---|---| | Type de test | A/B test | | Contrôle | Page tarifs actuelle avec le CTA « Start free trial » | | Variante | CTA « Build my first dashboard » plus trois bénéfices | | Répartition du trafic | 50 % contrôle, 50 % variante | | Audience | Nouveaux visiteurs US de la page tarifs, desktop et mobile | | Métrique principale | Visiteur page tarifs -> démarrage d'essai | | Métriques secondaires | Taux de clic CTA, complétion d'inscription, création du premier dashboard | | Garde-fous | Taux de rebond, temps de chargement, tickets support liés à des utilisateurs d'essai confus |
La base est proche de 5 %. Pour détecter une hausse relative de 20 %, prévoyez environ 18 000 visiteurs par variante, soit 36 000 visiteurs exposés au total. Avec 8 000 visiteurs de la page tarifs par semaine et 100 % d'exposition, le test doit durer environ 4,5 semaines. Exécutez-le au moins quatre semaines complètes pour couvrir les comportements semaine/week-end, et ne l'arrêtez pas plus tôt parce qu'une variante semble en tête après quelques jours.
Vérifiez qu'Optimizely assigne les utilisateurs de façon stable, que les deux variantes déclenchent le même événement GA4 trial_start, que le rendu mobile et desktop est correct, que la variante ne dégrade pas la vitesse de page, que le trafic interne est exclu et que l'ID d'expérience est stocké avec l'événement de conversion pour permettre l'audit.
Déployez la variante uniquement si elle atteint la taille d'échantillon prévue, montre une amélioration statistiquement significative et utile en pratique du taux de démarrage d'essai, et ne dégrade pas la complétion d'inscription ni la qualité d'activation. Si le résultat est non concluant, gardez le contrôle et testez d'abord le texte du CTA seul avant de tester les bénéfices.
Métriques améliorées
Compatible avec
Suivez les métriques de entonnoir et segmentez les résultats par propriétés utilisateur
Collectez des heatmaps et des enregistrements de session pour nourrir les hypothèses de test
Lancez des tests A/B côté client et gérez les variantes d'expérience
Mesurez l'impact de l'expérience sur les métriques d'activation et de rétention
Suivez le trafic, les événements de conversion et les objectifs pendant les tests
Envie d'utiliser Configuration de test A/B ?
Choisissez comment commencer.
Installez et exécutez cette compétence localement sur votre ordinateur.
Ouvrez un terminal sur votre ordinateur et collez cette commande :
Cela télécharge la compétence avec tous ses fichiers sur votre ordinateur :
Ajoutez -g à la fin pour le rendre disponible dans tous vos projets.
Démarrez Claude Code, puis tapez la commande :
Configuration de test A/B
Vous êtes expert en expérimentation et tests A/B. Votre objectif est d'aider à concevoir des tests qui produisent des résultats statistiquement valides et actionnables.
Évaluation initiale
Vérifiez d'abord le contexte de product marketing :
Si .agents/product-marketing-context.md existe (ou .claude/product-marketing-context.md dans les anciennes configurations), lisez-le avant de poser des questions. Utilisez ce contexte et ne demandez que les informations qui ne sont pas déjà couvertes ou qui sont spécifiques à cette tâche.
Avant de concevoir un test, comprenez :
- Contexte du test - Qu'essayez-vous d'améliorer ? Quel changement envisagez-vous ?
- État actuel - Taux de conversion de référence ? Volume de trafic actuel ?
- Contraintes - Complexité technique ? Calendrier ? Outils disponibles ?
Principes clés
1. Commencer par une hypothèse
- Pas seulement "voyons ce qui se passe"
- Prédiction spécifique du résultat
- Fondée sur un raisonnement ou des données
2. Tester une seule chose
- Une seule variable par test
- Sinon vous ne saurez pas ce qui a fonctionné
3. Rigueur statistique
- Déterminer la taille d'échantillon à l'avance
- Ne pas regarder les résultats trop tôt ni arrêter prématurément
- S'engager sur la méthodologie
4. Mesurer ce qui compte
- Métrique principale liée à la valeur business
- Métriques secondaires pour le contexte
- Métriques garde-fous pour éviter les effets négatifs
Cadre d'hypothèse
Structure
Parce que [observation/données],
nous pensons que [changement]
provoquera [résultat attendu]
pour [audience].
Nous saurons que c'est vrai quand [métriques].
Exemple
Faible : "Changer la couleur du bouton pourrait augmenter les clics."
Fort : "Parce que les utilisateurs disent avoir du mal à trouver le CTA (selon les heatmaps et les retours), nous pensons qu'agrandir le bouton et utiliser une couleur contrastée augmentera les clics CTA de 15 %+ chez les nouveaux visiteurs. Nous mesurerons le taux de clic entre la vue de page et le début d'inscription."
Types de tests
| Type | Description | Trafic nécessaire |
|---|---|---|
| A/B | Deux versions, un seul changement | Modéré |
| A/B/n | Plusieurs variantes | Plus élevé |
| MVT | Plusieurs changements en combinaison | Très élevé |
| Split URL | URLs différentes pour les variantes | Modéré |
Taille d'échantillon
Référence rapide
| Baseline | 10% Lift | 20% Lift | 50% Lift |
|---|---|---|---|
| 1% | 150k/variant | 39k/variant | 6k/variant |
| 3% | 47k/variant | 12k/variant | 2k/variant |
| 5% | 27k/variant | 7k/variant | 1.2k/variant |
| 10% | 12k/variant | 3k/variant | 550/variant |
Calculateurs :
Pour des tableaux détaillés de taille d'échantillon et les calculs de durée : Voir references/sample-size-guide.md
Choix des métriques
Métrique principale
- Une seule métrique la plus importante
- Directement liée à l'hypothèse
- Celle qui servira à conclure le test
Métriques secondaires
- Aident à interpréter la métrique principale
- Expliquent pourquoi/comment le changement a fonctionné
Métriques garde-fous
- Ce qui ne doit pas se dégrader
- Arrêter le test si c'est significativement négatif
Exemple : test de page pricing
- Principale : Taux de sélection de plan
- Secondaires : Temps sur page, répartition des plans
- Garde-fous : Tickets support, taux de remboursement
Conception des variantes
Ce qui peut varier
| Catégorie | Exemples |
|---|---|
| Titres/Copy | Angle de message, proposition de valeur, précision, ton |
| Design visuel | Mise en page, couleur, images, hiérarchie |
| CTA | Texte du bouton, taille, position, nombre |
| Contenu | Informations incluses, ordre, quantité, preuve sociale |
Bonnes pratiques
- Un seul changement significatif
- Assez visible pour faire une différence
- Fidèle à l'hypothèse
Répartition du trafic
| Approche | Split | Quand l'utiliser |
|---|---|---|
| Standard | 50/50 | Défaut pour A/B |
| Conservatrice | 90/10, 80/20 | Limiter le risque d'une mauvaise variante |
| Progressive | Commencer petit, augmenter | Réduire le risque technique |
À considérer :
- Cohérence : les utilisateurs voient la même variante au retour
- Exposition équilibrée selon l'heure/le jour de la semaine
Implémentation
Côté client
- JavaScript modifie la page après le chargement
- Rapide à mettre en place, peut provoquer un flicker
- Outils : PostHog, Optimizely, VWO
Côté serveur
- Variante déterminée avant le rendu
- Pas de flicker, nécessite du travail dev
- Outils : PostHog, LaunchDarkly, Split
Exécution du test
Checklist avant lancement
- Hypothèse documentée
- Métrique principale définie
- Taille d'échantillon calculée
- Variantes correctement implémentées
- Tracking vérifié
- QA terminée sur toutes les variantes
Pendant le test
À faire :
- Surveiller les problèmes techniques
- Vérifier la qualité des segments
- Documenter les facteurs externes
À éviter :
- Regarder les résultats et arrêter trop tôt
- Modifier les variantes
- Ajouter du trafic depuis de nouvelles sources
Le problème du peeking
Regarder les résultats avant d'atteindre la taille d'échantillon et arrêter prématurément entraîne des faux positifs et de mauvaises décisions. Engagez-vous à l'avance sur la taille d'échantillon et faites confiance au processus.
Analyse des résultats
Significativité statistique
- 95% confidence = p-value < 0.05
- Signifie moins de 5 % de chances que le résultat soit aléatoire
- Ce n'est pas une garantie, seulement un seuil
Checklist d'analyse
- Taille d'échantillon atteinte ? Sinon, le résultat est préliminaire
- Statistiquement significatif ? Vérifiez les intervalles de confiance
- Taille d'effet significative ? Comparez au MDE et à l'impact projeté
- Métriques secondaires cohérentes ? Soutiennent-elles la principale ?
- Problèmes de garde-fous ? Quelque chose s'est dégradé ?
- Différences par segment ? Mobile vs desktop ? Nouveaux vs revenants ?
Interprétation des résultats
| Résultat | Conclusion |
|---|---|
| Gagnant significatif | Implémenter la variante |
| Perdant significatif | Garder le contrôle, comprendre pourquoi |
| Pas de différence significative | Besoin de plus de trafic ou d'un test plus marqué |
| Signaux mixtes | Creuser davantage, peut-être segmenter |
Documentation
Documentez chaque test avec :
- Hypothèse
- Variantes (avec captures d'écran)
- Résultats (échantillon, métriques, significativité)
- Décision et apprentissages
Pour les modèles : Voir references/test-templates.md
Erreurs courantes
Conception du test
- Tester un changement trop petit (indétectable)
- Tester trop de choses (impossible à isoler)
- Pas d'hypothèse claire
Exécution
- Arrêter trop tôt
- Changer des éléments en cours de test
- Ne pas vérifier l'implémentation
Analyse
- Ignorer les intervalles de confiance
- Choisir les segments qui arrangent
- Sur-interpréter des résultats non concluants
Questions propres à la tâche
- Quel est votre taux de conversion actuel ?
- Combien de trafic cette page reçoit-elle ?
- Quel changement envisagez-vous et pourquoi ?
- Quelle est la plus petite amélioration qui mérite d'être détectée ?
- Quels outils avez-vous pour tester ?
- Avez-vous déjà testé cette zone ?
Skills associés
- page-cro : Pour générer des idées de test selon les principes CRO
- analytics-tracking : Pour mettre en place la mesure du test
- copywriting : Pour créer la copy des variantes
Documents de référence
Guide de taille d'échantillon
Référence pour calculer les tailles d'échantillon et la durée des tests.
Sommaire
- Fondamentaux de taille d'échantillon (entrées requises, signification)
- Tableaux de référence rapide
- Calculateur de durée (formule, exemples, durée minimale, durée maximale)
- Calculateurs en ligne
- Ajustement pour plusieurs variantes
- Erreurs courantes de taille d'échantillon
- Quand les besoins d'échantillon sont trop élevés
- Tests séquentiels
- Cadre de décision rapide
Fondamentaux de taille d'échantillon
Entrées requises
- Taux de conversion de référence : votre taux actuel
- Effet minimal détectable (MDE) : le plus petit changement qui mérite d'être détecté
- Niveau de significativité statistique : généralement 95 % (α = 0.05)
- Puissance statistique : généralement 80 % (β = 0.20)
Ce que cela signifie
Taux de conversion de référence : si votre page convertit à 5 %, c'est votre baseline.
MDE (Minimum Detectable Effect) : la plus petite amélioration que vous voulez détecter. Définissez-la selon :
- Impact business (un lift de 5 % est-il significatif ?)
- Coût d'implémentation (cela vaut-il l'effort ?)
- Attentes réalistes (qu'ont montré les tests précédents ?)
Significativité statistique (95 %) : signifie qu'il y a moins de 5 % de chances que l'écart observé soit dû au hasard.
Puissance statistique (80 %) : signifie que s'il existe un effet réel de taille MDE, vous avez 80 % de chances de le détecter.
Tableaux de référence rapide
Taux de conversion : 1 %
| Lift à détecter | Échantillon par variante | Échantillon total |
|---|---|---|
| 5% (1% → 1.05%) | 1,500,000 | 3,000,000 |
| 10% (1% → 1.1%) | 380,000 | 760,000 |
| 20% (1% → 1.2%) | 97,000 | 194,000 |
| 50% (1% → 1.5%) | 16,000 | 32,000 |
| 100% (1% → 2%) | 4,200 | 8,400 |
Taux de conversion : 3 %
| Lift à détecter | Échantillon par variante | Échantillon total |
|---|---|---|
| 5% (3% → 3.15%) | 480,000 | 960,000 |
| 10% (3% → 3.3%) | 120,000 | 240,000 |
| 20% (3% → 3.6%) | 31,000 | 62,000 |
| 50% (3% → 4.5%) | 5,200 | 10,400 |
| 100% (3% → 6%) | 1,400 | 2,800 |
Taux de conversion : 5 %
| Lift à détecter | Échantillon par variante | Échantillon total |
|---|---|---|
| 5% (5% → 5.25%) | 280,000 | 560,000 |
| 10% (5% → 5.5%) | 72,000 | 144,000 |
| 20% (5% → 6%) | 18,000 | 36,000 |
| 50% (5% → 7.5%) | 3,100 | 6,200 |
| 100% (5% → 10%) | 810 | 1,620 |
Taux de conversion : 10 %
| Lift à détecter | Échantillon par variante | Échantillon total |
|---|---|---|
| 5% (10% → 10.5%) | 130,000 | 260,000 |
| 10% (10% → 11%) | 34,000 | 68,000 |
| 20% (10% → 12%) | 8,700 | 17,400 |
| 50% (10% → 15%) | 1,500 | 3,000 |
| 100% (10% → 20%) | 400 | 800 |
Taux de conversion : 20 %
| Lift à détecter | Échantillon par variante | Échantillon total |
|---|---|---|
| 5% (20% → 21%) | 60,000 | 120,000 |
| 10% (20% → 22%) | 16,000 | 32,000 |
| 20% (20% → 24%) | 4,000 | 8,000 |
| 50% (20% → 30%) | 700 | 1,400 |
| 100% (20% → 40%) | 200 | 400 |
Calculateur de durée
Formule
Durée (jours) = (Échantillon par variante × Nombre de variantes) / (Trafic quotidien × % exposé)
Exemples
Scénario 1 : page à fort trafic
- Besoin : 10,000 par variante (2 variantes = 20,000 au total)
- Trafic quotidien : 5,000 visiteurs
- 100 % exposés au test
- Durée : 20,000 / 5,000 = 4 jours
Scénario 2 : page à trafic moyen
- Besoin : 30,000 par variante (60,000 au total)
- Trafic quotidien : 2,000 visiteurs
- 100 % exposés
- Durée : 60,000 / 2,000 = 30 jours
Scénario 3 : faible trafic avec exposition partielle
- Besoin : 15,000 par variante (30,000 au total)
- Trafic quotidien : 500 visiteurs
- 50 % exposés au test
- Quotidien effectif : 250
- Durée : 30,000 / 250 = 120 jours (trop long !)
Règles de durée minimale
Même avec une taille d'échantillon suffisante, lancez les tests au moins :
- 1 semaine complète : pour capter les variations selon le jour de la semaine
- 2 cycles business : en B2B (semaine vs week-end)
- À travers les jours de paie : en e-commerce (début/fin de mois)
Repères de durée maximale
Évitez de faire durer les tests plus de 4 à 8 semaines :
- Les effets de nouveauté disparaissent
- Des facteurs externes interviennent
- Coût d'opportunité des autres tests
Calculateurs en ligne
Outils recommandés
Calculateur d'Evan Miller https://www.evanmiller.org/ab-testing/sample-size.html
- Interface simple
- À garder en favori
Calculateur d'Optimizely https://www.optimizely.com/sample-size-calculator/
- Langage orienté business
- Estimations de durée
Calculateur AB Test Guide https://www.abtestguide.com/calc/
- Inclut une option bayésienne
- Plusieurs types de tests
Calculateur de durée VWO https://vwo.com/tools/ab-test-duration-calculator/
- Centré sur la durée
- Utile pour la planification
Ajustement pour plusieurs variantes
Avec plus de 2 variantes (tests A/B/n), vous avez besoin de plus d'échantillon :
| Variantes | Multiplicateur |
|---|---|
| 2 (A/B) | 1x |
| 3 (A/B/C) | ~1.5x |
| 4 (A/B/C/D) | ~2x |
| 5+ | Envisager de réduire les variantes |
Pourquoi ? Plus de comparaisons augmente le risque de faux positifs. Vous comparez :
- A vs B
- A vs C
- B vs C (parfois)
Appliquez la correction de Bonferroni ou utilisez des outils qui la gèrent automatiquement.
Erreurs courantes de taille d'échantillon
1. Tests sous-puissants
Problème : échantillon insuffisant pour détecter des effets réalistes Correctif : soyez réaliste sur le MDE, obtenez plus de trafic ou ne testez pas
2. Tests surpuissants
Problème : attendre la taille d'échantillon alors que vous avez déjà une significativité Correctif : c'est acceptable : vous vous êtes engagé sur une taille d'échantillon, respectez-la
3. Mauvais taux de référence
Problème : utiliser le mauvais taux de conversion pour le calcul Correctif : utilisez la métrique et la page spécifiques, pas les moyennes du site
4. Ignorer les segments
Problème : calculer pour tout le trafic, puis analyser des segments Correctif : si vous prévoyez une analyse segmentée, calculez l'échantillon pour le plus petit segment
5. Tester trop de choses
Problème : diviser le trafic en trop de branches Correctif : priorisez sans concession, lancez moins de tests simultanés
Quand les besoins d'échantillon sont trop élevés
Options quand vous n'avez pas assez de trafic :
- Augmenter le MDE : accepter de ne détecter que des effets plus importants (20 %+ de lift)
- Réduire la confiance : utiliser 90 % au lieu de 95 % (risqué, à documenter)
- Réduire les variantes : tester seulement la variante la plus prometteuse
- Combiner le trafic : tester sur plusieurs pages similaires
- Tester en amont : tester plus tôt dans le entonnoir, là où le trafic est plus élevé
- Ne pas tester : décider à partir de données qualitatives
- Allonger le test : accepter une durée plus longue (semaines/mois)
Tests séquentiels
Si vous devez consulter les résultats avant d'atteindre la taille d'échantillon :
Qu'est-ce que c'est ?
Méthode statistique qui ajuste les calculs pour plusieurs consultations des données.
Quand l'utiliser
- Changements à risque élevé
- Besoin d'arrêter tôt les mauvaises variantes
- Décisions sensibles au temps
Outils qui le prennent en charge
- Optimizely (Stats Accelerator)
- VWO (SmartStats)
- PostHog (approche bayésienne)
Compromis
- Plus de flexibilité pour arrêter tôt
- Besoin d'échantillon légèrement plus élevé
- Analyse plus complexe
Cadre de décision rapide
Puis-je lancer ce test ?
Trafic quotidien vers la page : _____
Taux de conversion de référence : _____
MDE qui m'importe : _____
Échantillon nécessaire par variante : _____ (depuis les tableaux ci-dessus)
Jours d'exécution : Échantillon / trafic quotidien = _____
Si jours > 60 : envisager des alternatives
Si jours > 30 : acceptable pour les tests à fort impact
Si jours < 14 : probablement faisable
Si jours < 7 : facile à lancer, envisagez quand même de le faire durer plus longtemps
Référence de modèles de tests A/B
Modèles pour planifier, documenter et analyser des expérimentations.
Sommaire
- Modèle de plan de test
- Modèle de documentation des résultats
- Modèle d'entrée dans le référentiel de tests
- Modèle de brief rapide
- Modèle de mise à jour parties prenantes
- Scorecard de priorisation des expériences
- Modèle de banque d'hypothèses
Modèle de plan de test
# Test A/B : [Nom]
## Vue d'ensemble
- **Owner** : [Nom]
- **ID du test** : [ID dans l'outil de test]
- **Page/Fonctionnalité** : [Ce qui est testé]
- **Dates prévues** : [Début] - [Fin]
## Hypothèse
Parce que [observation/données],
nous pensons que [changement]
provoquera [résultat attendu]
pour [audience].
Nous saurons que c'est vrai quand [métriques].
## Design du test
| Élément | Détails |
|---------|---------|
| Type de test | A/B / A/B/n / MVT |
| Durée | X semaines |
| Taille d'échantillon | X par variante |
| Répartition du trafic | 50/50 |
| Outil | [Nom de l'outil] |
| Implémentation | Côté client / Côté serveur |
## Variantes
### Contrôle (A)
[Capture d'écran]
- Expérience actuelle
- [Détails clés sur l'état actuel]
### Variante (B)
[Capture d'écran ou maquette]
- [Changement spécifique #1]
- [Changement spécifique #2]
- Rationale : [Pourquoi nous pensons que cela gagnera]
## Métriques
### Principale
- **Métrique** : [nom de la métrique]
- **Définition** : [mode de calcul]
- **Baseline actuelle** : [X%]
- **Effet minimal détectable** : [X%]
### Secondaires
- [Métrique 1] : [ce que cela nous dit]
- [Métrique 2] : [ce que cela nous dit]
- [Métrique 3] : [ce que cela nous dit]
### Garde-fous
- [Métrique qui ne doit pas se dégrader]
- [Autre métrique de sécurité]
## Plan d'analyse par segment
- Mobile vs desktop
- Nouveaux visiteurs vs visiteurs récurrents
- Source de trafic
- [Autres segments pertinents]
## Critères de succès
- Gagnant : [La métrique principale s'améliore de X% avec 95% de confiance]
- Perdant : [La métrique principale baisse significativement]
- Non concluant : [Ce que nous ferons sans résultat significatif]
## Checklist avant lancement
- [ ] Hypothèse documentée et relue
- [ ] Métrique principale définie et trackable
- [ ] Taille d'échantillon calculée
- [ ] Durée du test estimée
- [ ] Variantes correctement implémentées
- [ ] Tracking vérifié dans toutes les variantes
- [ ] QA terminée sur toutes les variantes
- [ ] Parties prenantes informées
- [ ] Créneau calendrier réservé pour l'analyse
Modèle de documentation des résultats
# Résultats du test A/B : [Nom]
## Résumé
| Élément | Valeur |
|---------|--------|
| ID du test | [ID] |
| Dates | [Début] - [Fin] |
| Durée | X jours |
| Résultat | Gagnant / Perdant / Non concluant |
| Décision | [Ce que nous faisons] |
## Hypothèse (rappel)
[Copier depuis le plan de test]
## Résultats
### Taille d'échantillon
| Variante | Cible | Réel | % de la cible |
|----------|-------|------|---------------|
| Contrôle | X | Y | Z% |
| Variante | X | Y | Z% |
### Métrique principale : [Nom de la métrique]
| Variante | Valeur | IC 95% | vs contrôle |
|----------|--------|--------|-------------|
| Contrôle | X% | [X%, Y%] | — |
| Variante | X% | [X%, Y%] | +X% |
**Significativité statistique** : p = X.XX (95% = sig / non sig)
**Significativité pratique** : [Ce lift est-il significatif pour le business ?]
### Métriques secondaires
| Métrique | Contrôle | Variante | Changement | Significatif ? |
|----------|----------|----------|------------|----------------|
| [Métrique 1] | X | Y | +Z% | Oui/Non |
| [Métrique 2] | X | Y | +Z% | Oui/Non |
### Métriques garde-fous
| Métrique | Contrôle | Variante | Changement | Préoccupation ? |
|----------|----------|----------|------------|-----------------|
| [Métrique 1] | X | Y | +Z% | Oui/Non |
### Analyse par segment
**Mobile vs desktop**
| Segment | Contrôle | Variante | Lift |
|---------|----------|----------|------|
| Mobile | X% | Y% | +Z% |
| Desktop | X% | Y% | +Z% |
**Nouveaux vs récurrents**
| Segment | Contrôle | Variante | Lift |
|---------|----------|----------|------|
| Nouveaux | X% | Y% | +Z% |
| Récurrents | X% | Y% | +Z% |
## Interprétation
### Que s'est-il passé ?
[Explication des résultats en langage simple]
### Pourquoi pensons-nous que c'est arrivé ?
[Analyse et raisonnement]
### Réserves
[Limites, facteurs externes ou préoccupations]
## Décision
**Gagnant** : [Contrôle / Variante]
**Action** : [Implémenter la variante / Garder le contrôle / Re-tester]
**Calendrier** : [Quand les changements seront implémentés]
## Apprentissages
### Ce que nous avons appris
- [Insight clé 1]
- [Insight clé 2]
### Ce qu'il faut tester ensuite
- [Idée de test suivante 1]
- [Idée de test suivante 2]
### Impact
- **Lift projeté** : [X% d'amélioration sur la métrique Y]
- **Impact business** : [Revenu, conversions, etc.]
Modèle d'entrée dans le référentiel de tests
Pour suivre tous les tests à un endroit central :
| ID du test | Nom | Page | Dates | Métrique principale | Résultat | Lift | Lien |
|------------|-----|------|-------|---------------------|----------|------|------|
| 001 | Test de titre hero | Accueil | 1/1-1/15 | CTR | Gagnant | +12% | [Lien] |
| 002 | Layout de grille pricing | Pricing | 1/10-1/31 | Sélection de plan | Perdant | -5% | [Lien] |
| 003 | Champs du formulaire signup | Signup | 2/1-2/14 | Complétion | Non concluant | +2% | [Lien] |
Modèle de brief rapide
Pour les tests simples qui n'ont pas besoin d'une documentation complète :
## [Nom du test]
**Quoi** : [Description en une phrase]
**Pourquoi** : [Hypothèse en une phrase]
**Métrique** : [Métrique principale]
**Durée** : [X semaines]
**Résultat** : [TBD / Gagnant / Perdant / Non concluant]
**Apprentissages** : [Point clé à retenir]
Modèle de mise à jour parties prenantes
## Mise à jour test A/B : [Nom]
**Statut** : En cours / Terminé
**Jours restants** : X (ou terminé)
**Échantillon actuel** : X% de la cible
### Observations préliminaires
[Ce que nous voyons, sans encore prendre de décision]
### Prochaines étapes
[Ce qui se passe ensuite]
### Calendrier
- [Date] : Analyse terminée
- [Date] : Décision et recommandation
- [Date] : Implémentation (si gagnant)
Scorecard de priorisation des expériences
Pour décider quels tests lancer :
| Facteur | Poids | Test A | Test B | Test C |
|---|---|---|---|---|
| Impact potentiel | 30% | |||
| Confiance dans l'hypothèse | 25% | |||
| Facilité d'implémentation | 20% | |||
| Risque en cas d'erreur | 15% | |||
| Alignement stratégique | 10% | |||
| Total |
Score : 1-5 (5 = meilleur)
Modèle de banque d'hypothèses
Pour collecter les idées de test :
| ID | Page/Zone | Observation | Hypothèse | Impact potentiel | Statut |
|----|-----------|-------------|-----------|------------------|--------|
| H1 | Accueil | Faible profondeur de scroll | Un hero plus court augmentera le scroll | Élevé | En test |
| H2 | Pricing | Les utilisateurs comparent les plans | Un tableau comparatif aidera | Moyen | Backlog |
| H3 | Signup | Abandon à l'email | Le login social augmentera la complétion | Moyen | Backlog |