Les analyses Web et app sont fondamentales à toutes entreprises de nos jours. Aucun développeur, chef de produit ou PDG sérieux d’une entreprise opérant sur le marché numérique ne songe à ne pas les utiliser. Le marché de l’analyse est également très concurrentiel, des fournisseurs de toutes tailles et de toutes agilités luttant pour obtenir leurs trois lignes de code ou SDK dans votre logiciel. En conséquence, les plates-formes regorgent de fonctionnalités et sont très faciles à utiliser.
Donc, si la mise en œuvre est si simple et si la visualisation des résultats est si simple, alors la méthodologie «basée sur les données» devrait être encore plus simple. Mais est-ce vraiment le cas ?
Nous recevons quotidiennement des rapports volumineux contenant d’énormes quantités d’informations importantes. Que faisons-nous avec cette information après le premier mois ou les deux premiers? Dans la plupart des cas, la réponse est : à peu près rien. Comme le dit mon collaborateur Paul Sartori, responsable des analyses chez Consultance Station 10, personne n’a besoin d’un rapport: «Ils pourraient penser que oui, ces personnes très importantes pour lesquelles vous faites l’analyse pourraient dire:« Je dois voir les ventes de la société tous les jours. jour ‘, mais pensez-y; c’est une statistique, pas un rapport, et s’il ne fait rien, il ne vaut pas la peine de passer du temps dessus »
Où est le problème?
Le problème se situe au tout début de toute implémentation d’analyse. Les chefs de produits et les analystes se sont habitués à travailler par étapes avec l’analyse.
Ces étapes ressemblent généralement à ceci:
- Cartographiez tous les événements possibles (rien ne manque!) vers une table d’évènements
- Implémenter une table d’événements
- Version finale
- Vérifier que tout est enregistré
- Créez un tableau de bord pour surveiller les nouveaux utilisateurs et les utilisateurs précédents, les métriques de rétention et les taux de conversion intégrés … et c’est à peu près tout, n’est-ce pas?
Qu’est-ce qui ne va pas avec ça ? Pas grand chose, mais est-ce suffisant? J’espère que ce n’est pas le cas pour vous.
Le problème est que, en appliquant cette approche (et si beaucoup d’entre nous l’adoptons), vous vous retrouvez constamment à chercher les bonnes réponses, alors que vous devriez être en train de chercher les bonnes questions.
À moins que vous ne receviez le soutien d’une équipe d’apprentissage automatique extrêmement talentueuse, organiser des centaines d’événements ne vous sert pas du tout. Il est inévitable que les données soient surchargées, ce qui rend très difficile la décision pour commencer à définir les priorités. En pratique, la multiplicité des événements vous limite, car vous vous voyez lié à ces événements et vous êtes sûr que les réponses à toutes vos questions se cachent dans les données. Mais vous ne faites que rendre la vie plus difficile pour vous-même.
De plus, définir trop d’événements entraîne nécessairement des événements «plus faibles», des événements sans propriétés réfléchies. Je vais approfondir l’utilisation judicieuse des propriétés d’événement et d’autres techniques une autre fois.
Si le rapport dit que tout va bien, allez-vous tous arrêter de travailler? Et s’il dit tout, n’allez-vous pas en chercher les raisons et ce que vous devriez faire à ce sujet de toute façon? Comme l’a ajouté Paul Sartori: «Pourquoi ne pas le faire en premier lieu au lieu de perdre du temps sur des tableaux de bord jolis mais inutiles».
Pourquoi cela arrive-t-il? Et pourquoi cela arrive-t-il à presque tout le monde? C’est parce que nous sommes tous en train de regarder la tête en bas. Nous recherchons des aiguilles dans une pile de données, au lieu de comprendre que nous avons les moyens de les suivre au fur et à mesure qu’elles sont diffusées et qu’elles tombent dans les airs. Il est temps d’inverser notre perspective analytique.
La méthode du côté droit
Le terme axé sur les données est très couramment utilisé, mais beaucoup oublient son contexte. L’idée n’était jamais que les données sonnent juste l’alarme lorsque les choses tournent mal. Son contexte d’origine est constitué par les décisions basées sur les données.
En fait, je voudrais aller un peu plus loin et appeler cela une stratégie guidée par les données. Lorsque nous nous concentrons sur nos objectifs et ne sommes pas distraits par des contraintes tactiques, nous nous permettons (ou nous nous efforçons) de choisir les paramètres les plus pertinents et de ne poser que les questions pertinentes.
Par exemple:
- Notre chiffre d’affaires absolu, notre chiffre d’affaires par utilisateur ou notre taux de croissance?
- Notre approche actuelle des produits fonctionne-t-elle? Est-ce que cela sert notre objectif?
De cette façon, nous planifions notre implémentation analytique de haut en bas:
- Commencer avec des objectifs
- Choisissez les métriques / indicateurs de performance clés qui comptent vraiment
- Poser des questions stratégiques pour expliquer la cause
Une fois que nous sommes convaincus que nous avons posé toutes les questions pertinentes, nous passons maintenant à la détermination des causes et des effets potentiels.
“Qu’est-ce qui pourrait affecter cet objectif et quelles en sont les causes possibles?”.
Plus nous pourrons définir et approfondir nos questions, sans nous appuyer sur des réponses quantitatives pour poser la question suivante, mieux ce sera. Dès que nous ajoutons cette première métrique, il devient très difficile de ne pas devenir obsédé par elle…
Par exemple:
- Nous n’avons pas besoin de connaître le taux de conversion réel pour savoir où vont les utilisateurs.
- Lorsque nous disposerons de chiffres quantitatifs, nous voudrons bien sûr savoir où se situent les plus fortes baisses, mais à ce stade, nous nous concentrerons sur les chiffres, ce qui rend très difficile toute ouverture d’esprit.
Nos prochaines étapes sont alors tactiques:
- Sélectionnez les méthodes d’investigation pour répondre aux questions
- Terminez avec le tableau des événements / plan de taggage
Nous devons sélectionner les méthodes les plus efficaces pour analyser les questions stratégiques choisies parmi l’ensemble des outils fournis par la plateforme d’analyse choisie. À ce stade, je dois souligner que ce processus de sélection n’est pas simplement «agréable à avoir» pour des raisons de propreté. C’est une tâche supercritique qui doit être effectuée.
La raison en est que l’analyse analytique peut prendre beaucoup de temps si elle n’est pas effectuée efficacement. En fait, Hotjar rapporte que c’est l’une des principales raisons pour lesquelles les développeurs arrêtent d’utiliser ses produits, même s’ils les trouvent utiles. Ne sous-estimez pas le «poids» que la partie analyse aura sur vous – une erreur que j’ai commise trop de fois. Une exploration excessive peut causer, et causera généralement, plus de tort que de bien. C’est pourquoi vous devez l’alléger autant que possible en optimisant et en concentrant votre enquête et vos méthodes.
Alors, comment devenez-vous plus efficace avec vos méthodes d’enquête? Il existe un certain nombre de techniques que vous pouvez utiliser, que je partagerai dans mon prochain post. Mais surtout, vous devriez toujours essayer de trouver le chemin le plus court vers votre réponse. Plus le chemin est compliqué, plus il y a de chance qu’une erreur se produise dans le processus de mise en œuvre et corrompe vos données…
Là où la plupart des analyses commencent, nous terminerons avec la table des événements. Une fois que tous les éléments ci-dessus sont définis, la table des événements doit consister à joindre les points et à s’assurer qu’aucun point n’est laissé de côté. N’oubliez pas que vous devriez:
- Essayez de limiter le nombre d’événements
- Quand il s’agit de propriétés de l’événement être somptueux
- Assurez-vous de fournir une explication détaillée du moment où chaque événement est déclenché et de la propriété de chaque propriété d’événement. Fournissez des exemples et la liste complète des options de saisie si elles sont limitées.
