Drame analytique en milieu bisontin
Mai 2019.
Nous sommes dans la banlieue nord de Besançon, entre l’Ibis Hôtel et le Buffalo Grill qui longent l’A236, à la limite entre la préfecture du Doubs et Châtillon-le-Duc. Après plusieurs semaines de travail acharné, est en train de démarrer le comité de pilotage trimestriel de Photocopix 2000, avec la présence exceptionnelle de Michel Toner, président du directoire de Photocopix depuis avril 1924.
Pour la première fois, son agence de webanalytics, Consulteo, sélectionnée après un appel d’offre resté dans toutes les mémoires, est présente, et s’apprête à présenter une analyse de la performance de photocopix.biz, le site des passionnés de photocopieuses, lancé il y a tout juste 6 mois.
Cléodon, 23 ans, consultant senior en webanalytics avec plus de 10 ans d’expérience, est sûr de son fait mais transpire un peu dans sa chemise à carreaux en flanelle. Après le traditionnel café de bienvenue (« bravo les gars, on est content de se mettre à l’internet grâce à vous. Mais attendez, mon commercial de Montluçon m’appelle sur mon Palm Pilot »), Cléodon se lance dans une présentation endiablée. Taux de rebond, taux d’ajout au panier, AB Testing sur les call to action, analyse du tunnel de conversion, analyse de la déperdition par moyens de paiement, carte de chaleur… Plus la présentation avance, plus Cléodon sent qu’il est en train de gagner la confiance du Comité de Direction. Mais arrivé à la slide 127 de son analyse, lorsqu’il explique que les 327 transactions qui ont été remontées dans Google Analytics sont essentiellement dues à la campagne d’awareness faite auprès des influenceurs en photocopie d’Instagram, Corinne Toner, responsable financière du groupe (et fille de Michel, mais c’est une longue histoire), consulte avec vigueur un gros classeur rouge, et interrompt Cléodon : « 327 transactions ? Hum… D’après mes rapports SAP, sur la période en questions, il y aurait plutôt eu 361 transactions, cher Monsieur ». S’ensuivent 3 heures de débats mouvementés sur l’utilisation d’adblockers, le VPN Citrix de Photocopix, le Dark Web et les reptiliens.
Ma déontologie professionnelle m’interdit de dire si Consulteo travaille toujours pour Photocopix à ce jour, mais tout ce que je peux affirmer, c’est que la note du midi au buffet asiatique a été partagée à parts égales entre les convives, avant que Consulteo ne rejoigne ses locaux à République par le Train Express Régional de 14h28.
Si vous êtes, comme nous, des vieux roublards de la web analytics, il est hautement probable que vous ayez assisté à une situation comme celle-ci (même si pas forcément à Besançon). Au-delà des questions de la pertinence d’une campagne d’influence sur la verticale des photocopieurs, le sujet dont on se parle ici est celui, au sens large, de la fiabilité des données remontées dans les outils de webanalytics.
Coupé décalé
Commençons par détailler pourquoi ce type de décalage existe. Concrètement, comment un écart de 10, 15, 20% (voire plus) peut exister entre, d’une part, des données présente dans une base de données (qui va elle-même servir à émettre des factures, des documents comptables, etc…) et d’autre part, un outil de webanalytics qui par ailleurs contient des informations comme les sessions, le taux de rebond, les sources de trafic, j’en passe et des meilleures. Si les lecteurs les plus expérimentées de ce blog sont probablement déjà familiers de ce type de problématiques, une petite piqûre de rappel ne fait jamais de mal.
Concrètement, que se passe-t-il lorsqu’un utilisateur fait une transaction sur un site e-commerce quelconque ? Après avoir ajouté un produit à son panier, rentré ses informations de paiement, accepté les CGU, puis cliqué sur « Valider ma commande », il va tout d’abord se passer des choses côté back-end : l’API de paiement (par exemple Stripe) va tout d’abord confirmer que la carte bancaire utilisée dispose bien des fonds nécessaires, qu’elle n’est pas expirée, et faire sa petite affaire sans que notre site n’ait à s’occuper de quoi que ça soi. Si Stripe donne son feu vert, la transaction va être validée côté back office, et va donc venir ajouter une ligne dans la table des transactions de l’ERP de l’entreprise (SAP ou whatever), et déclencher un process de livraison d’un article dans l’entrepôt, etc.
Faisons une courte pause. Jusqu’ici, il ne s’est rien passé de visible pour l’utilisateur, qui, concrètement, voit encore à l’écran quelque chose comme « nous sommes en train de vérifier votre paiement. Merci de patienter. Bisous ». Et donc, côté analytics, idem : aucun tag de page / event / transaction n’est venu alimenter votre outil préféré. Et si vous êtes un peu un gars du genre YOLO, vous pouvez très possiblement arracher la batterie de votre laptop avec vos dents (ou juste l’éteindre, soyons raisonnables), votre transaction sera probablement validée, et vous recevrez votre article.
Si vous décidez malgré tout de rester sur le site (ce que je conseille tout de même), c’est seulement après qu’une page de validation va s’afficher (« Bravo, votre commande est validée, merci de votre confiance »). Et c’est précisément à ce moment là que, si tout se passe bien, votre tag d’analytics va être déclenché. À moins que…
- Peut-être que vous avez un adblocker un peu violent comme uBlock Origin qui met GA en PLS?
- Peut-être que le proxy de votre entreprise bloque les requêtes vers tout ce qui touche à Google ?
- Peut-être que vous êtes sur une connexion peu rapide, et que vous fermez précipitamment la page sans que le tag n’ait le temps de partir ?
- Peut-être que vous avez refusé les cookies d’analytics dans le bandeau de cookie consent du site (sauf s’ils sont exemptés, mais c’est un autre débat) ?
On peut être créatif et trouver encore quelques raisons supplémentaires (vos idées sont les bienvenues), mais il n’y a pas à aller chercher bien loin pour se rendre compte que votre tag de transaction côté analytics a un certain nombre de raisons de ne pas être déclenché.
Ce qui nous ramène donc un peu à notre véhément débat entre Cléodon et Corinne : pour quelqu’un qui vient d’un domaine où, littéralement, le moindre centime compte, et a même une valeur légale, dans quel monde peut-on travailler avec un outil qui ne nous remonte qu’une partie incomplète (et qui plus est assez variable) de la « vérité » ? Après tout, même si on ne maîtrise pas toutes les subtilités de PHP et PostgreSQL, notre logique de donnée qui passe dans le backend, sans que l’utilisateur puisse y mettre la grouille, paraît infiniment plus clean que quelque chose qui passe sur le front, n’est-il-pas ?
Pour répondre à cette question (qui n’est donc pas vite répondue pour reprendre l’adage commun), il faut en réalité comprendre le scope d’un outil d’analytics dans son ensemble. Certes, si on reprend l’exemple de notre transaction, l’affichage de la page de confirmation n’est en réalité qu’une conséquence de la transaction au sens comptable, logistique, et ne reflète pas forcément la réalité. Et si on pousse l’exemple un peu plus loin, au-delà de l’exemple de la transaction, il y a d’autres infos moins cruciales, comme les pages vues, qui sont, sous une autre forme, également disponibles en faisant abstraction du front. Eh oui mes amis, je veux bien entendu parler des logs serveurs : pour ceux qui connaîtraient moins bien ce sujet, il s’agit, un peu comme pour notre exemple de la transaction, de récupérer non pas le fait que la page s’affiche sur le device de l’utilisateur, mais bien que le serveur l’ait gentiment envoyée. Une nouvelle fois, on peut d’une certaine façon dire qu’un appel serveur correspond à une réalité plus « concrète », dans le sens où un serveur, bah, ça coûte cher, et que chaque appel serveur coûte sans doute quelques centièmes de centimes. D’ailleurs, si on revient un peu à la préhistoire de l’analytics, certains des premiers outils du marché (Webtrends notamment) utilisaient des logs serveur pour afficher de la data.
Donc, finalement, si on va par là, est ce qu’on ne pourrait pas tout simplement remettre en cause la webanalytics de façon générale (et m’envoyer à Pôle Emploi par la même occasion) ? La réponse est non. Enfin pas tout de suite. Enfin merde, quoi, j’ai un crédit immo à payer moi. On revient donc aux fondamentaux, et on va poser une bonne fois pour toutes le principe : les outils de webanalytics sont là pour mesurer ce qui se passe dans le navigateur de l’utilisateur. Et si les transactions sont moins exactes que dans votre back office ou les pages vues moins précises que sur vos logs Apache, votre outil d’analytics reste indispensable pour analyser des choses qui se passent purement sur le front : clic sur des boutons, navigation sur un carrousel…
Finalement, l’analytics, à défaut d’être un outil qui reflète une certaine exactitude, peut être vu comme le pont entre toutes ces notions. Parce que si les données de transactions de votre base de données seront précises à la milliseconde près, bon courage pour les lier à un comportement de vos utilisateurs sur un referrer et donc une source de trafic. Même chose si vous voulez maquer vos logs serveur avec un taux de scroll sur une page produit. Allez pan Corinne, prends-toi ça dans les dents, toi et ton Excel 2007* !
*Une blague était initialement prévue sur Jean-Guy, directeur informatique de Photocopix, relative au fait qu’il avait plus de sessions sur son Windows Server que sur GA. La blague impliquait également le fait qu’il ait un catogan, mais le comité éditorial de Webalab a censuré ce passage. N’hésitez pas à tweeter #jeanGuyReturns sur les réseaux sociaux pour que justice soit rendue.
Pour résumer jusqu’ici, retenez que les outils de webanalytics sont là pour analyser ce qui se passe sur votre front end, côté navigateur. Qui dit front end dit capacité à analyser des choses très fines qui se passent dans les navigateurs de vos utilisateurs (consentants), mais en contrepartie, qui ont 1001 façons de fuck up votre data ¯\_(ツ)_/¯
Donc, j’espère que vous vous êtes bien mis dans la tête que chercher l’exactitude dans vos outils d’analytics relève de la gageure. Il est super important, dès que vous démarrez un projet d’analytics, de tenir ce discours de façon rationnelle et honnête. Il est aussi important de comprendre la logique technique qui peut exister sur les décalages discutés ci-dessus. Oui, que vous le vouliez ou non, vous devez être d’une rigueur implacable lorsqu’il faut expliquer ce genre de choses à un directeur marketing, digital ou je ne sais quelle fonction exécutive. Et n’allez pas me servir du « ouais c’est les devs qui ont merdé, lol ».
Une approximation, oui, mais jusqu’ou?
Nous sommes donc à l’aise pour parler d’outil de tendance, mais cela vaut le coup d’aller un peu plus loin. Jusqu’à quel stade peut-on considérer une approximation comme « acceptable » ? Là-dessus, j’ai deux réponses, très différentes mais pas forcément antinomiques :
- Est-ce que la donnée que vous allez utiliser vous permettra de prendre une décision en votre âme et conscience ? Concrètement, vous hésitez entre le bouton rouge et le bouton bleu pour le call to action de vos pages produit. Est-ce que le fait d’avoir 80, 70, voire 40% de vos données va vraiment vous faire douter ? Je pense que selon les cas, la réponse peut varier.
- Est-ce qu’à un moment on ne devrait pas discuter de significativité statistique ? Aucun outil de WA ne propose ça, mais on peut faire des choses sympa avec BigQuery, ayant les données brutes… En gros, l’idée serait d’accompagner chaque analyse d’un peu plus de rigueur statistique : « le taux de clic sur le bouton bleu est significativement différent du taux de clic sur le bouton vert ».
Enfin, si vous constatez que, comme je l’ai parfois vu, l’écart entre votre outil d’analytics et votre base va du simple au double parce que vous n’avez que 6 (ou du coup, 12) commandes, franchement, je pense que vous avez des décisions plus importantes à prendre pour votre business.
Optimiser l’approximation
Même si le propos principal de cet article consiste à dire que « ça va les gars on se déstresse même si vous perdez de la data ça ira », ce n’est pas pour autant que l’on ne doit pas être rigoureux sur le fait d’optimiser au maximum la récolte. Je veux bien entendu parler de questions de performance. Cela fera sans doute l’objet d’un article à part entière, mais le temps d’exécution de votre TMS, son utilisation de lookup tables, mais aussi la façon dont GTM est appelé dans le code, etc. ont de vrais impacts sur la remontée des données.
Plus globalement, même si les discussions peuvent vite devenir très touffues, il ne faut pas hésiter à avoir des discussions constructives avec les équipes tech, qui doivent souvent arbitrer l’appel de votre Tag Manager parmi d’autres librairies.
Pour la petite histoire, lorsque je travaillais pour un grand quotidien de la presse quotidienne régionale, le tag de page AT Internet, outil qui était utilisé pour certifier le trafic auprès de l’ACPM, avait carrément été sorti de GTM, et appelé en dur, dans la page, avant même toutes les ressources CSS et JS, et ce, afin de gagner quelques millisecondes dans son appel. Comme ça, ça n’a l’air de rien, mais sur un trafic de centaines de millions de sessions par mois, ça finit par compter, d’autant plus quand l’ACPM est une donnée publique, et utiliser pour mettre en avant la marque pour que les annonceurs lâchent leurs $$$ en espace publicitaire.
Conclusion
Pour celles et ceux qui sont moins expérimentés sur les outils d’analytics, j’espère avoir dédramatisé ce sujet épineux, et vous avoir fourni plus d’arguments pour vous permettre d’avoir un regard avisé sur ces sujets de décalages des outils d’analytics avec la « réalité ». Pour les personnes plus expérimentées dans le domaine, j’espère avoir apporté plus de plénitude dans votre vie professionnelle, et/ou des arguments pour votre prochain meeting stratégique sur la définition des insights de la transformation digitale de vos clients.