Quels sont les effets du test A / B si l'utilisateur en est conscient?
Je suis allé sur le même site Web sur deux navigateurs différents, et j'ai obtenu deux mises en page + design différents. J'étais en cours de test A/B. Je n'ai pas aimé ça, probablement parce que:
- Je n'aime pas faire partie d'une expérience
- J'aime avoir la même expérience à chaque fois que je vais sur le site
Existe-t-il des études/recherches pour mesurer l'effet du test A/B lui-même sur l'utilisateur, si celui-ci se rend compte qu'il est en train d'être testé A/B? Seront-ils moins susceptibles de rester sur le site?
Je ne connais aucune étude publiée.
Je sais que d'avoir introduit les tests A/B dans plusieurs organisations:
- Je n'ai jamais vu de baisse de nombre après avoir introduit les tests.
- Nous n'avons jamais reçu de plaintes.
- Lorsque nous avons eu des études longitudinales lorsque nous revisitons les mêmes utilisateurs et qu'ils ont fini par avoir des expériences légèrement différentes, ils ne l'ont presque jamais remarqué.
Je soupçonne donc que le nombre de personnes qui seraient toutes deux en situation de remarquer des différences, et qui considéreraient cela comme négatif, sont suffisamment faibles pour que vous puissiez les ignorer.
Bien sûr, cela dépend de la façon dont vous abordez vos tests. Nous ne divisons jamais les principaux changements d'interface utilisateur de test sans faire d'abord des tests de convivialité de base pour éliminer les stupidités évidentes.
Je ne connais aucune étude, mais je peux vous donner quelques conseils pour vous aider à garder vos résultats plus significatifs.
Si vous voulez vraiment tester le logiciel de test, il ne devrait pas être trop difficile d'écrire la logique côté serveur ou "déployé" vs "non déployé" dans une sorte de test A/A.
- Software Flicker - si vous utilisez une plate-forme de test lente a/b, vous risquez d'afficher la page "scintillement" qui pourrait invalider les tests (j'ai maintenant vu la version par défaut et la version B)
- Latence logicielle - si vous introduisez une latence supplémentaire, vous nuisez probablement à votre taux de conversion (ironiquement). Pour cette raison, il est préférable de dépenser l'argent supplémentaire et d'obtenir une plate-forme rapide et soutenue par des SLA.
- Ce que vous mesurez - si vous testez les clics sur le bouton sur la page d'accueil lorsque vous manipulez votre entonnoir d'achat, il est probable que vous ne voyiez pas beaucoup de changements. Vos mesures devraient être aussi proches des changements que possible ... ni trop en amont, ni trop en aval.
- Durée du test - Ne testez pas pendant quelques jours seulement. Plus vous testez longtemps, plus vous vous rapprocherez de la "vraie moyenne" et vos chiffres deviendront et convergeront. Vous pouvez également remarquer qu'avec le temps, toutes les versions convergent vers un taux de conversion similaire, ce qui signifie que le test n'a pas fait grand-chose.
- Exécutez les tests A/A! - Si vous exécutez un test A/A pendant 2 mois et que vous remarquez un soulèvement, vous devez le prendre en compte comme une marge d'erreur supplémentaire dans vos résultats de test réels. Si vous voyez une augmentation de 5% et que vos prochains tests réels entraînent une augmentation de 5%, il est possible que cela n'ait pas ou peu d'effet.
Le point # 4 est important, personnellement. À la fin de la journée, si un visiteur souhaite acheter sur votre site, il le fera, quelles que soient vos habitudes de test. La seule exception étant des choses comme le prix et les avantages offerts. Mais, ces (tests de prix) vous donneront probablement les meilleures informations sur ce qui motive la conversion ... pas seulement "aiment-ils les boutons bleus ou verts"
Vous avez raison, les utilisateurs se comportent différemment lorsqu'ils savent qu'ils sont testés. Ils peuvent avoir l'impression que quelque chose ne va pas, je sais que depuis que nous vendons des logiciels de test A/B et début 2012, nous avons eu le sentiment que quelque chose n'allait pas. Nous remplacions le contenu à l'aide de jQuery en arrière qu'après DOM-ready et parfois les gens étaient un clin d'œil ... un ancien morceau de contenu de chargement qui a été relativement rapidement remplacé par la nouvelle variante.
Nous avons constaté que lorsque nous codions en dur la même variation côté serveur, nous pouvions augmenter les conversions de 18%. Donc, nous savons maintenant de cette expérience que l'installation d'un Javascript lourd abaisse le taux de conversion, faire des échanges après DOM-ready pourrait affecter les conversions jusqu'à 18%.
En mai 2012, nous avons amélioré la technique et apporté des modifications à l'interrogation toutes les 50 millisecondes avant de préparer DOM. Lisez un peu plus sur cette expérience ici dans le blog Convert.com .