Du CRO à la Purchase Journey Intelligence
Pourquoi la plupart des « analytics de conversion » n'expliquent pas la conversion, et ce que nous construisons à la place (Partie 1)
Télécharger le PDFPartie 1 d'une série en trois parties
- Partie 1 — Du CRO à la Purchase Journey Intelligence (cet article)
- Partie 2 — 32 341 $ de dépenses AWS, 10,5 millions de pages produit, 9 % de fiabilité
- Partie 3 — La réponse déterministe
L'optimisation du taux de conversion (CRO) a un problème d'image. Son vrai problème coûte bien plus cher à l'e-commerce.
Voici ce qui leur coûte. Le CRO est souvent traité comme une discipline de retouche d'interface : changer les couleurs, réorganiser les blocs, tester des micro-variantes en A/B, livrer des « bonnes pratiques » et appeler ça du progrès. Pendant ce temps, les défaillances qui drainent le plus de revenu se trouvent souvent ailleurs : la compétitivité de l'offre, la disponibilité, la confiance, les contraintes et le jeu concurrentiel.
Voici le recadrage :
La conversion n'est pas un problème d'« optimisation ».
C'est un problème de faisabilité du parcours d'achat — et les problèmes de faisabilité se cachent des outils d'optimisation.
Un parcours d'achat ne convertit que s'il est (1) digne d'être commencé, (2) possible à terminer, et (3) fiable dans des conditions réelles, pas seulement le jour où tout va bien.
C'est ce que nous appelons la Purchase Journey Intelligence (PJI) : un système qui mesure et explique les préconditions qui font réussir ou échouer les parcours d'achat. C'est le pari que j'ai fait en fondant SHORA l'an dernier, et le reste de cette série raconte ce qui s'est passé quand je l'ai testé.
Pourquoi cela compte (et où cela va)
La plupart des équipes découvrent les « problèmes de conversion » trop tard, parce que le revenu est l'indicateur le plus en retard du bâtiment. Au moment où une baisse du taux de conversion apparaît clairement dans les tableaux de bord, le parcours sous-jacent peut être cassé depuis des jours, à travers appareils et contextes, brûlant silencieusement du trafic payant et de la confiance de marque. Ces défaillances « partielles » — trop localisées pour faire bouger le KPI macro, trop transverses pour appartenir au tableau de bord d'une seule équipe — n'apparaissent jamais sur le radar des outils d'analytique que les équipes e-commerce paient déjà, parce que ces outils n'ont jamais été conçus pour les chercher. Dans le vocabulaire d'Avinash Kaushik, ce sont des ruptures de micro-conversion invisibles au KPI de macro-conversion.
L'économie tient sur une serviette de table. Une enseigne en ligne de taille moyenne réalisant 50 M€ de chiffre d'affaires annuel à un taux de conversion de référence de 3 % et un panier moyen de 1 000 € traite environ 50 000 parcours payants par an. Une défaillance partielle qui fait chuter la conversion de deux points absolus sur un tiers du trafic — un seul contrôle d'éligibilité à la livraison cassé sur mobile, dans un pays, pendant deux semaines — saigne environ 330 000 €. Voilà un « petit » bug.[1]
[1] Les benchmarks de conversion e-commerce et les distributions de panier sous-jacents sont tirés de rapports publics de l'industrie du retail cités en annexe de la Partie 2.
L'objectif final n'est donc pas « de meilleurs tableaux de bord » ou « plus d'expériences ». C'est une capacité :
- détecter les défaillances de parcours plus tôt que les KPI de revenu ne le peuvent,
- localiser ce qui a cassé et où,
- attacher des preuves que les ingénieurs peuvent reproduire,
- suivre la fiabilité dans le temps, pas seulement les moyennes.
C'est là que va CROspector. La Partie 1 explique pourquoi.
Le résultat plutôt que l'activité : l'écart de mesure que la plupart des stacks analytiques n'ont jamais été conçus pour combler
La plupart des stacks analytiques sont excellents pour compter des événements et déplorables pour expliquer des résultats. Ils ont été bâtis pour l'activité, pas pour la reddition de comptes.
Ils peuvent produire à la demande ce que Kaushik appelle une purge de données : pages vues, taux de clic, taux de rebond, abandons par étape de tunnel, cartes de chaleur, rejeux de session, clics de rage. Une équipe peut en présenter quarante et n'en conclure rien.
Mais ils échouent souvent à répondre aux seules questions qui comptent :
Qu'est-ce qui a exactement bloqué cet achat ?
Le parcours était-il impossible, ou simplement peu attrayant ?
L'utilisateur a-t-il échoué à cause d'une friction, ou à cause de contraintes ?
À quelle fréquence cela casse-t-il, dans le temps, selon les appareils et les contextes ?
Ce n'est pas un manque de fonctionnalité dans votre produit d'analytique. C'est un écart de mesure — et il se situe exactement là où la Trinité de Kaushik (Expérience, Comportement, Résultats) dit qu'il serait. Les outils existants mesurent le Comportement (clickstream). Ils rapportent les Résultats (le revenu) comme un KPI en retard. Ils laissent l'Expérience non instrumentée. Chaque euro de revenu qui saigne à travers une défaillance partielle saigne dans l'écart que la Trinité avait prédit.
Quand vous mesurez la mauvaise chose, vous optimisez des indicateurs indirects. Quand vous optimisez des indicateurs indirects, vous livrez de l'activité, pas de la reddition de comptes — et l'activité est exactement ce que le Web Analytics 2.0 de Kaushik a été écrit pour mettre à la retraite.
Pourquoi l'A/B testing sur une mesure faible devient un tapis roulant
L'A/B testing n'est pas l'ennemi. La causalité faible l'est. Une équipe qui mène des tests A/B rigoureux par-dessus une mesure faible applique la bonne discipline au mauvais substrat.
Si votre instrumentation ne peut pas expliquer pourquoi les utilisateurs échouent, vous finissez dans une boucle : générer des hypothèses (souvent purement UI parce que c'est le plus facile), livrer des expériences, constater des effets négligeables la plupart du temps, expliquer le résultat comme du bruit ou un manque de trafic, recommencer.
Les LLM ne corrigent pas cela — ils l'amplifient. Ce qui se passe quand vous pointez un modèle de langage de pointe sur ce problème précis, et combien il en coûte d'apprendre cette leçon, fait l'objet de la Partie 2.
Deux vidéos qui illustrent l'écart
Pour rendre cela concret, voici deux façons d'« instrumenter » le même parcours — la même tentative d'achat, le même utilisateur, la même défaillance. La première est ce que la plupart des outils de rejeu de session voient aujourd'hui. La seconde est un cran au-dessus. Aucune n'est suffisante pour arrêter le revenu qui fuit, et la raison pour laquelle aucune ne suffit est ce que le reste de ce post explique.
Télémétrie de clickstream (la référence courante)
Un clickstream montre les mouvements du curseur et les clics sous forme de trajectoire. Ça ressemble à des données. Mais c'est surtout du résidu de comportement. C'est le Comportement dans la Trinité de Kaushik, et seulement le Comportement — pas d'Expérience, aucun lien aux Résultats.
Il n'est pas lié aux éléments d'UI qui étaient réellement visibles. Il n'encode pas l'état (« à quelle étape étions-nous ? »). Il n'encode pas la sémantique (« qu'essayait de faire l'utilisateur ? »). Il n'encode pas les réponses du système (« que s'est-il passé quand il a essayé ? »).
Deux personnes peuvent donc regarder le même gribouillis et raconter deux histoires différentes.
Ce n'est pas de l'intelligence. C'est du récit.
Annotation ancrée à l'UI (un vrai pas en avant)
La vue annotée superpose la trace du curseur à l'interface réellement rendue et identifie les régions/éléments de l'écran. C'est immédiatement meilleur parce que le comportement est désormais lié à la géométrie de l'UI. Vous pouvez isoler des cibles candidates (CTA, contrôles, modales). C'est plus falsifiable qu'une trajectoire sur toile blanche. C'est aussi toujours du Comportement. Cela ne capture pas encore l'Expérience et ne s'attache pas aux Résultats.
Cela ne répond toujours pas à ce que l'utilisateur essayait de faire (intention), à ce que le système a répondu (Expérience), ou à savoir si le parcours a jamais produit un Résultat.
Autrement dit : la vue annotée enregistre ce que le curseur a fait. Elle n'enregistre pas ce que le système était censé faire, et s'il l'a fait. Ce sont des catégories de preuves différentes, et la Purchase Journey Intelligence concerne la seconde — celle qui attrape les défaillances qui saignent de l'argent.
Le parcours d'achat est plus vaste que l'UI — et c'est là que vit l'essentiel du revenu perdu
Un parcours d'achat est une séquence d'états sous contraintes.
Il inclut la friction. Il inclut aussi cinq modes de défaillance qui coûtent silencieusement plus cher à l'e-commerce que la friction ne l'a jamais fait :
- Compétitivité de l'offre — votre prix perd face à un concurrent dans la même session de shopping.
- Disponibilité et éligibilité — l'article est affiché en stock mais n'est pas livrable à l'adresse de l'acheteur.
- Confiance et conformité — la caisse demande des données que l'acheteur n'est pas prêt à donner.
- Performance et fiabilité — le même parcours fonctionne aujourd'hui et casse demain sur le même appareil.
- Le jeu concurrentiel — l'acheteur compare les offres en cours de parcours et ne revient jamais.
Le CRO se sur-concentre sur la friction parce que la friction est la chose la plus facile à voir et à tester. Les défaillances à plus fort levier se trouvent dans les contraintes, pas dans l'UI. Chacune d'elles est, dans le vocabulaire de Kaushik, une défaillance d'Expérience que la stack actuelle, limitée au Comportement, ne peut détecter avant que le KPI de Résultat ne se soit déjà effondré.
Un taux de conversion n'est qu'une moyenne sur ces états cachés. La moyenne est la façon dont les défaillances restent cachées, et dont le revenu continue de fuir.
D'où vient CROspector : la mesure avant l'optimisation
CROspector part d'une prémisse simple :
Vous ne pouvez pas optimiser ce que vous ne pouvez pas observer,
et vous ne pouvez pas observer ce que vous ne mesurez pas comme des états, des contraintes et des preuves.
Nous avons donc construit un agent qui sonde les parcours d'achat sur des surfaces publiques, de façon répétée, à travers le temps et les contextes, comme le ferait un humain, et qui enregistre des preuves.
Des preuves. Pas des événements.
Nous sondons les parcours de façon non intrusive et à débit limité sur des pages publiques, conçue pour respecter la stabilité des sites.
L'objectif n'est pas de générer des hypothèses. L'objectif est de produire des faits vérifiables sur ce qui fait réussir ou échouer un parcours d'achat.
En clair : un compte rendu de ce qui casse, à quelle fréquence, dans quelles conditions, et de quel type d'échec il s'agit (friction, contrainte, confiance, position concurrentielle), avec des preuves que l'équipe d'ingénierie peut reproduire. Pas un tableau de bord. Pas une nouvelle purge de données. Un dossier de fiabilité pour les parcours qui paient vos factures — actionnable au sens exact de Kaushik : un seul clic sur le dossier de défaillance donne à l'ingénieur la page, le moment, l'état et la reproduction.
Analytique vs intelligence du parcours
Voici la distinction : l'analytique répond à « Que s'est-il passé ? ». L'intelligence du parcours répond à « Que s'est-il passé, pourquoi, dans quelles conditions, et avec quelle fiabilité dans le temps ? ». Si vous prenez la conversion au sérieux, vous voulez la seconde, parce qu'elle change ce que votre organisation peut faire. Elle raccourcit le temps de détection, réduit le temps de diagnostic, et empêche les équipes de passer des mois à optimiser des indicateurs indirects pendant qu'une défaillance de contrainte saigne silencieusement du revenu.
Où nous allons (teaser de la Partie 2)
La Partie 1 porte sur le recadrage et l'écart de mesure.
La Partie 2 est le verdict — ce qui s'est passé quand nous avons essayé de faire produire à un modèle de langage de pointe la couche Expérience de la Trinité de Kaushik, à l'échelle, sur des millions de pages d'enseignes en direct. Cela n'a pas marché. Le taux de précision était de 9 %. La Partie 2 explique la facture AWS, ce que nous attendions, et ce que les données nous ont forcés à admettre.