Mener un test A/B d’onboarding mobile fiable

1. Transformer une idée en décision

« Raccourcir l’onboarding » est une idée. Une hypothèse testable précise quelle audience verra quel changement et pourquoi cela devrait améliorer un résultat. Par exemple, déplacer une préférence facultative après la première utilisation pourrait aider les nouvelles installations à accomplir une première action utile en 24 heures.

Consignez métrique principale, niveau de départ estimé, effet minimal utile, allocation, éligibilité, fenêtre et règle d’arrêt. Estimez la taille d’échantillon avec la méthode statistique choisie et un trafic réaliste. Aucun nombre universel de jours ou d’utilisateurs ne rend tous les tests fiables.

La complétion peut aider, mais une activation en aval représente parfois mieux la valeur recherchée. Ajoutez des garde-fous comme les crashes, erreurs réseau ou comportements d’achat indésirables. Ne redéfinissez pas le succès après avoir vu quelle métrique semble meilleure.

2. Stabiliser l’affectation et définir l’exposition

Une installation éligible doit retrouver le même groupe après redémarrage. Sinon, les résultats ne correspondent plus clairement à l’expérience attribuée. Conservez version de l’expérience et affectation dans le contexte des événements pertinents.

Affectation, téléchargement et exposition sont distincts. Mesurez l’exposition quand l’expérience est effectivement affichée. Décidez si l’analyse principale inclut toutes les installations randomisées ou une population exposée. Filtrer après l’affectation peut biaiser le résultat si la variante change la probabilité d’exposition.

Avant la collecte décisionnelle, testez les deux branches, la persistance, les doublons et les frontières d’application. Un plan 50/50 ne donne pas exactement deux groupes égaux, mais un déséquilibre important mérite une investigation.

3. Exprimer l’effet en points de pourcentage

Imaginons 500 complétions sur 1 000 installations pour le contrôle A et 540 sur 1 000 pour la variante B. Les taux sont 50 % et 54 %. L’écart absolu vaut +4 points ; la hausse relative vaut +8 %. Dire seulement « 8 % de mieux » masque les taux de départ.

Le graphique présente ces résultats inventés. Avec une approximation normale simple, binomiale indépendante et à horizon fixe, l’intervalle approximatif à 95 % de la différence va de −0,4 à +8,4 points. Une petite dégradation comme une amélioration utile restent compatibles avec les observations : aucun vainqueur n’est démontré.

Cette illustration utilise 1,96 fois l’erreur standard de la différence. L’approximation peut mal fonctionner avec de petits échantillons ou des proportions proches de zéro ou un. Adaptez la méthode au protocole ; observations répétées, regroupements et comparaisons multiples nécessitent une attention particulière.

4. Respecter la règle d’arrêt

Un intervalle classique à horizon fixe ne permet pas de consulter sans cesse les résultats puis d’arrêter dès qu’ils paraissent favorables. Choisissez à l’avance un horizon fixe ou une méthode séquentielle valide. Laissez aussi la fenêtre des derniers participants arriver à maturité.

Consignez exclusions, incidents et versions publiées pendant le test. Distinguez segments prévus et analyses exploratoires : essayer de nombreux pays, appareils ou objectifs augmente le risque d’un résultat séduisant par hasard. Un segment découvert après coup devient une hypothèse pour un prochain test.

Si le test reste non concluant, dites-le. Un trafic faible peut laisser des effets importants indéterminés. Améliorer l’instrumentation ou tester un changement cohérent plus marqué peut être préférable à prolonger indéfiniment une analyse improvisée.

5. Décider, puis surveiller

La décision combine preuves, effet utile, garde-fous et coût de mise en œuvre. Une meilleure complétion accompagnée d’une activation ou d’une fiabilité dégradée ne justifie pas forcément un déploiement. Conservez les versions exactes et le motif de la décision.

Aplyna prend en charge les configurations et événements documentés ; il ne déclare ni ne déploie automatiquement une variante gagnante. Les branches natives doivent déjà être livrées dans l’application. La configuration distante ne distribue pas de nouveau code natif arbitraire. Consultez les limites actuelles avant de planifier la publication.