Vous livrez une refonte et la métrique principale chute. Que faites-vous la première semaine ?

Ne revenez pas en arrière et ne redessinez pas dès le premier jour. Confirmez que la mesure est réelle, puis segmentez par type d'utilisateur, appareil et ancienneté, parce qu'un creux de nouveauté chez les utilisateurs existants ressemble exactement à un design cassé dans l'agrégat. Regardez les enregistrements de session et le volume de support pour l'échec précis. Décidez dans une fenêtre convenue si ça se rétablit, si ça demande un correctif, ou s'il faut revenir en arrière.

Première chose, je vérifie qu'on mesure bien la même chose que la semaine dernière. Les refontes changent le balisage et les déclencheurs d'événements, et un événement cassé ressemble exactement à une catastrophe. Ça m'a eu deux fois. Ensuite je segmente, et le découpage qui m'intéresse le plus, c'est nouveaux contre utilisateurs existants. Si les nouveaux vont bien et que les existants ont chuté, c'est très probablement du réapprentissage et ça se rétablit en général en deux à trois semaines. Si les nouveaux ont chuté aussi, le design est réellement moins bon et je veux savoir où. Je regarde donc vingt enregistrements de sessions qui ont raté la tâche, ce qui est désagréable et extrêmement rapide pour trouver la vérité. Sur un lancement, c'était un seul contrôle qui ne se lisait plus comme cliquable parce qu'on l'avait rendu trop discret, un correctif d'une journée plutôt qu'un retour arrière. L'important, c'est de convenir de la règle de décision avant le lancement : quelle ampleur de chute déclenche un retour arrière et combien de temps on attend. Décider ça pendant que tout le monde est angoissé et que le chiffre est rouge, c'est comme ça qu'on jette du bon travail.