Exigences pour l'exécution de programmes d'expérimentation sérieuse

La conduite de programmes d'expérimentation est un art et une science. Je le dis tout le temps. Les programmes doivent avoir un certain niveau de rigueur, c'est-à-dire des systèmes, des processus et des procédures. Ce n'est pas quelque chose à prendre à la légère. Croire que n'importe qui peut démarrer un programme demain avec un minimum de préparation et de planification est une erreur. Malheureusement, cela arrive tout le temps. Cela entraîne beaucoup d'argent, de temps et d'efforts gaspillés - sans surprise. Cela m'amène au sujet de la préparation.

Si vous voulez être sérieux au sujet de l'expérimentation et améliorer votre compétitivité sur le marché, vous feriez mieux de bien le faire. Vous devez supposer que vos concurrents le font bien. Donc, si cela résonne en vous, continuez à lire et je vous garantis que vous ramasserez une ou deux pépites d'or à utiliser immédiatement.

Le précurseur incontournable pour construire un programme d'expérimentation qui vous fera ou vous détruira : les calculs de pré-test

Calculs de pré-test. Avez-vous déjà entendu parler d'eux? Les avez-vous fait? Le MDE ou l'effet minimum détectable vous semble-t-il familier ? Qu'en est-il des estimations de durée ou de la taille des échantillons ? J'espère que vous savez de quoi je parle même si je parierais de l'argent qu'une grande majorité d'entre vous ne le savent pas – simplement à cause de ma propre expérience personnelle avec les clients.

Avant de faire quoi que ce soit lié à l'expérimentation, veuillez voir si vous disposez d'un volume de données suffisant pour le faire. Voyez si vous êtes capable de tester du tout grâce à des calculs de pré-test. Par volume de données, j'entends les visiteurs et les conversions. Les visiteurs peuvent être tout ce que vous utilisez habituellement (par exemple, sessions, utilisateurs, MAU, etc.). Les conversions proviennent de la métrique principale que vous allez utiliser dans vos tests. Saches cela:

1. Toutes les entreprises ne disposent pas d'un volume de données suffisant pour effectuer des expérimentations à n'importe quelle capacité.
2. Si vous pouvez le faire, sachez que vous ne choisissez pas simplement la vitesse souhaitée à partir de rien. C'est basé sur des calculs.

Le premier coupable d'avoir ignoré l'un ou l'autre de ces points : les commerciaux. Si vous envisagez d'acheter n'importe quel type d'outil, assurez-vous que cela fait partie de la conversation. La barrière minimale à l'entrée pour avoir un programme d'expérimentation : un volume de données suffisant pour exécuter un test en huit semaines ou moins dans un couloir.

J'ai couvert ce sujet en détail il y a quelques mois pour Experiment Nation. Sachez que si vous ne comprenez pas ce sujet et que vous le faites dès le premier jour, cela vous hantera et finira certainement par provoquer des résultats indésirables. Une autre remarque très importante : sachez si votre outil de test (ou celui que vous envisagez d'utiliser) est construit sur la base de tests à horizon fixe ou de tests séquentiels. Cela affecte les calculs et la façon dont vous exécutez votre programme.

Étape 1 (post-précurseur) : mesure et qualité des données

Si vous avez franchi l'obstacle des calculs de pré-test et que vous avez confirmé que vous disposez d'un volume de données suffisant pour tester, le prochain obstacle pour aller de l'avant est la mesure et la qualité des données. Vous devez savoir ce que vous visez dans ce travail ; sinon, vous pataugerez comme un poisson au bord d'une rivière. Trop d'équipes ne savent pas sur quoi elles travaillent - comme les soumissions de formulaires, les transactions, les revenus, la LTV, etc.

Comprenez quelles sont vos mesures primaires, secondaires et tertiaires pour l'expérimentation et l'entreprise dans son ensemble. Comprenez-le en toute clarté. Ne laissez pas la confusion ou l'incertitude persistante. Assurez-vous que tout le monde est sur la même page.

Ensuite, une fois que vous en avez autant, assurez-vous que vous collectez ces données aux bons endroits et que vous pouvez leur faire confiance.

Si la mesure et/ou la qualité des données sont désastreuses, arrêtez. Arrêtez tout et consacrez tous vos efforts à bien faire les choses. Considérez l'expérimentation comme une pyramide. Ces deux choses sont les couches fondamentales de la pyramide. S'il se fissure à un moment donné, tout le reste s'effondrera dessus. Je promets.

Je dirai que je sais que cela peut être difficile. Les faire correctement peut prendre plus de temps. Peut-être même plus d'un mois ou deux. Les faire correctement en vaut la peine. J'ai vu des problèmes survenir six mois ou plus après le lancement d'un programme – seulement pour que tout finisse par s'arrêter brutalement. Personne n'est content à ce moment-là.

Une note sur ce que devrait être une métrique principale…

C'est parfois un sujet qui divise les pratiquants. J'ai une position très ferme sur la question, en particulier en ce qui concerne les équipes marketing et les sites Web (pas nécessairement les équipes produit et les produits).

Les métriques principales doivent toujours être des métriques descendantes. Ordres. Soumissions de formulaire. MQL. Revenu. LTV. SQL. Vous avez eu l'idée. Certaines personnes disent qu'elles devraient toujours être l'action la plus proche du changement que vous apportez ou des mesures d'engagement. Faux. Non. Non. Incorrect. BS. Celui qui vous dit cela devrait être celui qui devra justifier le programme dans six mois ou un an auprès du CMO ou du PDG de l'entreprise. Ils seront sur la sellette. NE PAS avoir un programme plein de tests axés sur les clics de bouton, les clics, les pages vues, la moyenne. durée de la session, taux de sortie, taux de rebond, vues vidéo, etc. Cela ne justifiera pas les milliers ou les centaines de milliers de dollars dépensés pour faire ce travail. Tout le monde veut connaître son retour sur investissement et l'impact du travail sur le résultat net. Les clics sur les boutons ne feront pas cela.

Je ne dis pas qu'il ne faut pas mesurer les métriques d'engagement ou les métriques d'entonnoir supérieur, mais elles devraient être des métriques secondaires ou tertiaires. Pas les primaires. Ils ajoutent du contexte à l'histoire d'un test. Ce ne sont pas sur eux que reposent les tests lorsque vient le temps de prendre une décision. Remarque, je ne dis pas non plus qu'il n'y a jamais d'exceptions. Toujours évaluer les tests au cas par cas.

Un conseil : à ceux qui débattent de ce sujet entre vous, je dis toujours aux équipes de discuter des options et de décider par elles-mêmes. Assurez-vous simplement d'arriver à une conclusion collective que tout le monde respecte en allant de l'avant.

Étape 2 : Recherche d'utilisateurs et idéation

À ce stade, vous devez (1) savoir que vous disposez d'un volume de données suffisant pour tester et (2) savoir ce que vous mesurez et que vous collectez des données appropriées auxquelles vous pouvez faire confiance. Alors, quelle est la prochaine étape ? Il vient avec ce qu'il faut tester. Quelles sont vos idées de test ? Comment allez-vous les générer ?

Devinez ce que font la plupart des équipes ? Ils partent d'intuitions et de beaucoup de "nous pensons", "nous ressentons" et "nous croyons". C'est beaucoup trop subjectif, et c'est une façon terrible d'exécuter un programme. Cette approche n'est pas du tout basée sur des données. C'est ce que les praticiens appellent le "test de spaghetti", c'est-à-dire jeter des trucs sur le mur et espérer que ça colle. Les conversations basées sur des données n'impliquent pas beaucoup de ce type de langage, et les données nécessaires proviennent de la recherche d'utilisateurs. On me demande ce que signifie « recherche » tout le temps.

Eh bien, il existe plusieurs méthodologies qui collectent des données, y compris, mais sans s'y limiter, les analyses, les sondages, les enquêtes, les tests d'utilisateurs, les tests de messages, les cartes thermiques, les enregistrements de session, le tri des cartes, les tests d'arborescence, la cartographie du parcours client, les personnages et bien d'autres. Il existe également plusieurs outils pour nous aider à remplir chacun d'eux. Je dis toujours de commencer par un ou deux et de passer à d'autres à partir de là. C'est certainement mieux que rien. Techniquement, je ne compte plus vraiment les analyses car chaque entreprise dispose de données d'analyse de nos jours. Si vous n'avez pas cela, vous avez probablement de plus gros poissons à faire frire. Si vous l'avez cependant, efforcez-vous d'en obtenir un ou deux au-delà même (et ne dites pas "oh, nous sommes bons alors").

Il existe une méthodologie appelée évaluation heuristique. C'est à ce moment-là que quelqu'un évalue visuellement une expérience et développe des idées basées sur son expérience et son expertise. Il y a un moment et un endroit pour cela, mais la plupart du temps, ils ne sont pas étayés par des « données concrètes ». C'est assez subjectif et sera différent dans une certaine mesure selon qui le complète. Sachez que votre programme ne devrait pas être basé sur ces types d'informations.

Je ne vais pas expliquer en détail comment faire des recherches ici, mais vous pouvez consulter l'un de mes webinaires VWO ici où je parle davantage du modèle ResearchXL de CXL.

Étape 3 : Priorisation

Une fois que vous avez une liste d'idées de test, vous ne pouvez pas les faire toutes en même temps. Vous avez besoin d'une manière stratégique et logique de créer un plan d'action. C'est là que les cadres de priorisation entrent en jeu. Beaucoup existent. J'en aime un en particulier : le framework PXL de CXL. D'autres courants incluent PIE, ICE ou PILL. Le PXL est le plus objectif selon moi. C'est personnalisable et plus robuste (dans le bon sens).

D'autres modèles sont corrects et mieux que rien. Si vous avez quelque chose et que cela fonctionne pour vous, tant mieux. Ayez-en juste un et assurez-vous que tout le monde l'utilise ! Cela vous évite de faire face à un chaos supplémentaire.

Étape 4 : Feuille de route

Les feuilles de route vous montrent visuellement ce qui est en cours d'exécution à un moment donné. Combinez vos calculs de priorisation et de pré-test et boum. Vous avez une feuille de route. Ceux-ci sont mieux réalisés dans les diagrammes de Gantt. Ajoutez tous vos couloirs et tests avec des durées estimées, des appareils et d'autres métadonnées utiles. Vous éviterez les chevauchements indésirables et les effets d'interaction indésirables. Cela aide tout le monde à planifier de manière beaucoup plus efficace et efficiente. Cela vous évitera plus de chaos.

Étape 5 et au-delà : Business as usual

Maintenant que tout ce que nous avons couvert est terminé, c'est comme d'habitude. Vous avez un test à portée de main que vous allez exécuter. Vous l'envoyez via le workflow d'expérimentation standard : maquette > conception > développement > AQ > lancement > surveillance > conclusion > analyse > partage et archivage > répétition.

Sujets connexes : Gestion et gouvernance du programme

En dehors des tests individuels, il y a d'autres sujets à considérer en relation avec un « programme » entier. Il s'agit notamment de la gestion et de la gouvernance du programme. Voici comment je pense à eux d'une manière très résumée…

Gestion du programme : Comment allez-vous organiser et suivre tout ce travail ? Déterminez quels outils vous allez utiliser pour les tâches, la gestion des données et la communication. (J'ai eu cette ventilation de Ben Labay, PDG de Speero.)

Gouvernance : Quels rôles et responsabilités chacun a-t-il ? Un moyen utile de déterminer cela consiste à (1) choisir un modèle de gouvernance et (2) remplir un tableau RASCI aligné sur le modèle de gouvernance. Modèles de gouvernance communs à étudier et à considérer : Individuel, centralisé, décentralisé, centre d'excellence, conseil de test et hybrides.

Si vous ne fixez pas ces deux éléments avec tout le reste, ce sera un chaos supplémentaire et vous en paierez le prix à chaque étape du processus. Clouez-les. Cela prend du temps supplémentaire, mais cela en vaut la peine. Si vous vous frayez un chemin à travers les choses pendant un certain temps, les conséquences finiront par vous rattraper. Je promets. (Apparemment, j'ai fait pas mal de promesses ici.)

Conclusion

Vous devriez vous sentir un peu (ou beaucoup) plus confiant dans ce que vous pouvez faire pour vous lancer dans l'expérimentation ou ce que vous pouvez faire pour mettre à niveau votre programme déjà en cours d'exécution. Ne pensez pas que c'est trop difficile ou trop facile. C'est généralement quelque part au milieu. Ma plus grande recommandation applicable à tout ce que j'ai mentionné : Avoir un quarterback. Avoir quelqu'un qui dirige tout ce travail. Il n'est pas nécessaire que ce soit leur rôle à plein temps, mais quelqu'un devrait le posséder. C'est généralement quand j'ai vu le plus de succès.

Pour conclure, j'espère que vous avez un programme d'expérimentation plein de rigueur, de résultats et d'un peu de plaisir parsemé. En fin de compte, c'est un travail amusant et excitant qui peut faire une énorme différence pour une entreprise.

Si vous souhaitez en savoir plus sur la façon dont l'expérimentation stimule l'innovation et la croissance et vaut tout le battage médiatique, regardez mon dernier webinaire avec VWO.