ab-test-setup

Cadre d'hypothèse

Structure

Parce que [observation/données],
nous croyons que [changement]
causera [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 signalent une difficulté à trouver l'appel à l'action (selon les heatmaps et les retours), nous croyons que rendre le bouton plus grand et utiliser une couleur contrastée augmentera les clics sur l'appel à l'action de 15 % ou plus pour les nouveaux visiteurs. Nous mesurerons le taux de clics de la vue de page au démarrage de l'inscription. »

Types de tests

Taille d'échantillon

Référence rapide

Calculateurs :

• Evan Miller's
• Optimizely's

Pour des tableaux détaillés de taille d'échantillon et des calculs de durée : Voir references/sample-size-guide.md

Sélection des métriques

Métrique primaire

• Une seule métrique qui compte vraiment
• Directement liée à l'hypothèse
• Ce que vous utiliserez pour valider le test

Métriques secondaires

• Soutiennent l'interprétation de la métrique primaire
• Expliquent comment/pourquoi le changement a fonctionné

Métriques de garde-fou

• Les choses qui ne devraient pas s'aggraver
• Arrêtez le test si significativement négatif

Exemple : Test de page de tarification

• Primaire : Taux de sélection de plan
• Secondaire : Temps sur page, distribution des plans
• Garde-fou : Tickets de support, taux de remboursement

Concevoir les variantes

Ce qu'il faut varier

Bonnes pratiques

• Changement unique et significatif
• Assez audacieux pour faire une différence
• Fidèle à l'hypothèse

Allocation du trafic

Considérations :

• Cohérence : Les utilisateurs voient la même variante au retour
• Exposition équilibrée au cours de la journée/semaine

Implémentation

Côté client

• JavaScript modifie la page après le chargement
• Rapide à mettre en œuvre, peut causer du scintillement
• Outils : PostHog, Optimizely, VWO

Côté serveur

• Variante déterminée avant le rendu
• Pas de scintillement, nécessite du travail de développement
• Outils : PostHog, LaunchDarkly, Split

Lancer le test

Liste de contrôle avant le lancement

• [ ] Hypothèse documentée
• [ ] Métrique primaire définie
• [ ] Taille d'échantillon calculée
• [ ] Variantes implémentées correctement
• [ ] Suivi vérifié
• [ ] QA complété sur toutes les variantes

Pendant le test

À FAIRE :

• Surveiller les problèmes techniques
• Vérifier la qualité des segments
• Documenter les facteurs externes

À ÉVITER :

• Jeter un coup d'œil aux résultats et arrêter tôt
• Apporter des modifications aux variantes
• Ajouter du trafic provenant de nouvelles sources

Le problème du « peeking »

Regarder les résultats avant d'atteindre la taille d'échantillon et arrêter tôt entraîne des faux positifs et de mauvaises décisions. Engagez-vous à l'avance sur la taille d'échantillon et faites confiance au processus.

Analyser les résultats

Significativité statistique

• 95 % de confiance = p-value < 0,05
• Signifie < 5 % de chance que le résultat soit aléatoire
• Pas une garantie — juste un seuil

Liste de contrôle d'analyse

1. Atteint la taille d'échantillon ? Si non, le résultat est préliminaire
2. Significativité statistique ? Vérifiez les intervalles de confiance
3. L'effet est-il significatif ? Comparez à l'amélioration détectable minimale, l'impact du projet
4. Les métriques secondaires sont-elles cohérentes ? Soutiennent-elles la primaire ?
5. Préoccupations des garde-fou ? Y a-t-il quelque chose qui s'est aggravé ?
6. Différences entre les segments ? Mobile vs. desktop ? Nouveau vs. récurrent ?

Interprétation des résultats

Documentation

Documentez chaque test avec :

• Hypothèse
• Variantes (avec captures d'écran)
• Résultats (échantillon, métriques, significativité)
• Décision et enseignements

Pour les modèles : Voir references/test-templates.md

Programme d'expérimentation pour la croissance

Les tests individuels sont précieux. Un programme d'expérimentation continu est un actif composé. Cette section couvre comment exécuter des expériences en tant que moteur de croissance continu, pas seulement des tests ponctuels.

La boucle d'expérimentation

1. Générer des hypothèses (à partir de données, recherches, concurrents, retours clients)
2. Prioriser avec la notation ICE
3. Concevoir et lancer le test
4. Analyser les résultats avec rigueur statistique
5. Promouvoir les gagnants dans un playbook
6. Générer de nouvelles hypothèses à partir des enseignements
→ Répéter

Génération d'hypothèses

Alimentez votre arriéré d'expériences à partir de plusieurs sources :

Priorisation ICE

Notez chaque hypothèse de 1 à 10 sur trois dimensions :

Score ICE = (Impact + Confiance + Facilité) / 3

Lancez les expériences avec les scores les plus élevés en premier. Re-notez mensuellement à mesure que le contexte change.

Vélocité d'expérimentation

Suivez votre taux d'expérimentation comme indicateur avancé de croissance :

Le playbook d'expérimentation

Quand un test gagne, ne le mettez pas simplement en œuvre — documentez le motif :

## [Nom de l'expérience]
**Date** : [date]
**Hypothèse** : [l'hypothèse]
**Taille d'échantillon** : [n par variante]
**Résultat** : [gagnant/perdant/inconclus] — [métrique primaire] a changé de [X %] (IC 95 % : [intervalle], p=[valeur])
**Garde-fou** : [toutes les métriques de garde-fou et leurs résultats]
**Deltas de segment** : [différences notables par appareil, segment ou cohorte]
**Pourquoi cela a fonctionné/échoué** : [analyse]
**Motif** : [l'insight réutilisable — par ex., « la preuve sociale près des appels à l'action de tarification augmente la sélection de plan »]
**Appliquer à** : [autres pages/flux où ce motif pourrait fonctionner]
**Statut** : [implémenté / mis de côté / nécessite un suivi]

Au fil du temps, votre playbook devient une bibliothèque de motifs de croissance éprouvés spécifiques à votre produit et votre audience.

Cadence d'expérimentation

Hebdomadaire (30 min) : Examinez les expériences en cours pour les problèmes techniques et les métriques de garde-fou. N'appelez pas de gagnants tôt — mais arrêtez les tests où les garde-fou sont significativement négatifs.

Bi-hebdomadaire : Concludez les expériences terminées. Analysez les résultats, mettez à jour le playbook, lancez la prochaine expérience de l'arriéré.

Mensuel (1 heure) : Examinez la vélocité d'expérimentation, le taux de victoire, l'amélioration cumulée. Remplissez l'arriéré d'hypothèses. Re-priorisez avec ICE.

Trimestriel : Auditez le playbook. Quels motifs ont été appliqués largement ? Quels motifs gagnants n'ont pas encore été mis à l'échelle ? Quelles zones de l'entonnoir sont sous-testées ?

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 tôt
• Modifier les choses au milieu du test
• Ne pas vérifier l'implémentation

Analyse

• Ignorer les intervalles de confiance
• Cherry-picker les segments
• Sur-interpréter les résultats inconclusifs

Questions spécifiques à la tâche

1. Quel est votre taux de conversion actuel ?
2. Combien de trafic cette page reçoit-elle ?
3. Quel changement envisagez-vous et pourquoi ?
4. Quelle est la plus petite amélioration qu'il vaut la peine de détecter ?
5. Quels outils avez-vous pour tester ?
6. Avez-vous testé cette zone auparavant ?

Compétences connexes

• page-cro : Pour générer des idées de test basées sur les principes CRO
• analytics-tracking : Pour mettre en place la mesure du test
• copywriting : Pour créer des variantes de texte