Comment suivre le tunnel de conversion WooCommerce dans GA4 ?

Une boutique WooCommerce dont le suivi analytique se limite au nombre de sessions et au chiffre d'affaires ne dit rien de ce qui se passe entre les deux. Le tunnel de conversion WooCommerce comporte au minimum cinq étapes, de la vue d'un produit au paiement accepté, et l'essentiel de la marge de progression se trouve dans les passages d'une étape à la suivante. Google Analytics 4 sait représenter ce parcours, à condition qu'on lui envoie les bons événements, avec les bons paramètres, au bon moment. C'est un travail d'implémentation, pas de configuration : aucune case à cocher ne produit ces données, et les extensions qui promettent le contraire couvrent en général les cas simples et laissent des trous précisément là où les questions se posent.

Les événements que GA4 attend réellement

GA4 ne devine rien : il affiche ce qu'on lui envoie, avec la structure qu'il attend. Le modèle du commerce électronique repose sur une série d'événements normalisés, chacun accompagné d'un tableau d'articles décrivant les produits concernés. Les nommer autrement, ou envoyer les produits sous une autre forme, produit des données présentes dans l'interface mais absentes des rapports dédiés au commerce, ce qui est la source de confusion la plus fréquente sur les boutiques que nous reprenons dans la rubrique WooCommerce.

La série normalisée du parcours d'achat

Sept événements couvrent le parcours complet, et ils doivent porter exactement les noms prévus par la documentation officielle : la vue d'une liste de produits, la sélection d'un produit dans cette liste, la vue d'une fiche produit, l'ajout au panier, la vue du panier, l'entrée dans le tunnel de commande et l'achat. Deux compléments sont utiles selon la boutique, l'ajout des informations de paiement et l'ajout des informations de livraison, qui découpent l'étape de commande quand celle ci comporte plusieurs pages. Le retrait du panier mérite aussi d'être suivi, car il éclaire des abandons que rien d'autre n'explique.

Le tableau d'articles, qui porte toute la valeur

Chaque événement du commerce transporte une liste d'articles, et c'est cette liste qui alimente tous les rapports produit. Chaque entrée doit porter au minimum un identifiant stable, un nom, un prix et une quantité, et gagne à porter aussi la catégorie, la variante et la marque. L'identifiant est le point critique : il doit être le même à toutes les étapes et correspondre à celui utilisé dans le flux produit envoyé aux régies, faute de quoi les rapprochements ultérieurs deviennent impossibles. Sur une boutique à variantes, la décision d'envoyer la référence du produit parent ou celle de la variante doit être prise une fois et tenue partout.

La devise et la valeur, sans lesquelles rien ne remonte

GA4 ignore purement et simplement un événement d'achat qui ne comporte pas de devise valide, et n'affiche aucun chiffre d'affaires. C'est l'erreur la plus fréquente et la plus silencieuse, car l'événement apparaît bien dans les rapports temps réel. La valeur transmise doit par ailleurs correspondre à une définition arrêtée à l'avance : montant hors taxes ou toutes taxes comprises, port inclus ou non, remises déduites ou non. Aucune de ces options n'est fausse, mais mélanger les conventions entre le panier et l'achat produit des taux de conversion en valeur qui n'ont aucun sens.

L'identifiant de transaction, garde fou contre les doublons

L'événement d'achat doit porter le numéro de commande. GA4 s'en sert pour écarter les envois en double, cas très courant puisqu'un client peut recharger la page de confirmation, revenir dessus depuis son historique ou la laisser ouverte dans un onglet. Sans cet identifiant, chaque rechargement crée une commande supplémentaire dans les rapports, ce qui gonfle le chiffre d'affaires mesuré de plusieurs pour cent et rend toute réconciliation impossible. Avec lui, la déduplication est automatique et ne demande aucun travail supplémentaire.

Ce que le modèle ne prévoit pas

Certaines étapes propres aux boutiques françaises n'ont aucun équivalent normalisé : le choix d'un point relais, l'application d'un code promotionnel, la sélection d'un mode de paiement en plusieurs fois, la demande d'une facture au nom d'une société. Rien n'interdit de créer des événements personnalisés pour ces moments, à condition de ne pas les nommer comme les événements normalisés et de ne pas espérer les voir apparaître dans les rapports du commerce, qui ne connaissent que la série officielle. Ces événements sur mesure prennent tout leur sens en exploration, où ils permettent de comparer le taux de finalisation selon qu'un code promotionnel a été saisi ou non, question à laquelle aucun rapport standard ne répond.

Envoyer ces événements depuis WooCommerce

WooCommerce fournit tout ce qu'il faut pour produire ces événements, à condition de les accrocher aux bons points d'entrée. Le choix se fait entre trois approches, dont aucune n'est universellement supérieure, et la comparaison se fait sur la fiabilité de la mesure autant que sur le coût de mise en place. La logique reste celle exposée dans notre article sur la manière de créer un tunnel de vente efficace pour son site e-commerce : on ne mesure correctement que ce qu'on a d'abord défini clairement.

Le suivi par le navigateur

La méthode la plus répandue consiste à déclencher les événements depuis le navigateur, au moment où l'utilisateur agit. Elle est simple à mettre en place et donne accès à tout le contexte de la session. Elle a deux faiblesses connues : une part des visiteurs bloque les scripts de mesure, et les ajouts au panier effectués en arrière plan, très fréquents sur les boutiques modernes, n'entraînent aucun chargement de page et exigent donc d'écouter les événements internes émis par WooCommerce plutôt que de compter sur un déclenchement au chargement.

Le suivi côté serveur

L'événement d'achat, en particulier, gagne beaucoup à être envoyé depuis le serveur, au moment où la commande passe effectivement au statut payé. Cette approche capte les paiements qui se finalisent sans retour du client sur le site, cas courant avec certains moyens de paiement, et n'est affectée ni par les bloqueurs ni par les fermetures d'onglet prématurées. Elle exige en revanche de transmettre l'identifiant de client attribué par la mesure côté navigateur, sans quoi la commande apparaît comme provenant d'un utilisateur inconnu et perd tout rattachement à sa source d'acquisition.

Le mode mixte, qui est la configuration courante

La configuration qui donne les meilleurs résultats mêle les deux : les étapes de navigation et de panier partent du navigateur, où elles sont naturelles, et l'achat part du serveur, où il est fiable. Il faut alors s'assurer qu'aucun achat n'est envoyé deux fois, ce que l'identifiant de transaction garantit, et vérifier que l'identifiant de client est bien transmis d'un canal à l'autre. Cette architecture demande une journée de travail de plus qu'une extension prête à l'emploi, et elle est la seule qui produise des chiffres qu'on peut opposer à une facture.

Le cas des paiements différés et des remboursements

Une commande peut être payée trois jours après avoir été passée, annulée le lendemain, ou remboursée partiellement un mois plus tard. Décider à quel changement de statut l'événement d'achat est envoyé conditionne tout le reste : l'envoyer à la création de la commande gonfle les chiffres des paniers abandonnés au paiement, l'envoyer au passage en statut payé donne des chiffres réconciliables avec la comptabilité. Les remboursements, eux, disposent d'un événement dédié qu'il faut penser à câbler, sans quoi le chiffre d'affaires mesuré reste durablement supérieur au chiffre d'affaires réel.

Le consentement, qui conditionne tout le reste

Aucune de ces méthodes ne dispense du recueil préalable du consentement pour les traceurs qui ne sont pas strictement nécessaires, ce qui inclut la mesure d'audience dans sa configuration courante. En pratique, cela signifie que les événements ne partent qu'après acceptation, et que le mode de consentement doit être câblé avant le script de mesure plutôt qu'après, faute de quoi les premiers événements de la session partent quoi qu'il arrive. Il faut aussi accepter la conséquence : une part des visiteurs restera non mesurée, et la comparaison avec les commandes réelles portera toujours un écart structurel, qu'il vaut mieux estimer une fois pour toutes que découvrir à chaque analyse.

Vérifier que les chiffres sont justes

Une implémentation non vérifiée est une implémentation fausse, et l'expérience montre que les écarts se logent toujours aux mêmes endroits. Le contrôle se fait en trois passes, de la plus immédiate à la plus lente, et doit être refait après chaque mise à jour importante de la boutique. Le principe est le même que pour tout dispositif de mesure, y compris l'installation initiale du code de suivi Analytics de Google : on ne fait confiance qu'à ce qu'on a vu arriver.

Regarder les événements partir

Le premier contrôle se fait dans le navigateur, en observant les requêtes envoyées pendant un parcours d'achat complet effectué à la main. Chaque événement doit apparaître une fois et une seule, avec sa liste d'articles complète et sa valeur. C'est à ce stade qu'on découvre les doublons de chargement, les listes d'articles vides et les prix envoyés avec un séparateur décimal inattendu. Ce parcours prend dix minutes et évite plusieurs semaines de données inutilisables.

Comparer avec les commandes réelles

Le deuxième contrôle consiste à comparer, sur une semaine complète, le nombre de commandes et le chiffre d'affaires mesurés par GA4 avec ceux de l'administration WooCommerce. Un écart de quelques pour cent est normal et s'explique par les refus de mesure et les fuseaux horaires. Un écart de vingt pour cent signale un problème structurel, et son signe oriente le diagnostic : un déficit vient d'événements perdus, un excédent vient de doublons ou de commandes envoyées avant paiement.

Surveiller le taux de passage entre étapes

Le troisième contrôle est un contrôle de vraisemblance. Un taux de passage de la fiche produit à l'ajout au panier supérieur à cinquante pour cent, ou un taux de passage du panier à la commande de cent pour cent, révèlent presque toujours un événement déclenché au mauvais moment plutôt qu'une boutique exceptionnelle. À l'inverse, un taux nul sur une étape signale un événement qui ne part jamais, souvent parce qu'il est accroché à un gabarit que le thème n'utilise pas. Ces trois contrôles gagnent à être refaits sur une seule et même semaine de référence, conservée comme étalon : disposer d'une période dont on sait qu'elle est propre permet de comparer plus tard n'importe quel mois douteux à quelque chose de sûr, au lieu de rediscuter à chaque fois de la validité de la mesure.

Documenter le plan de marquage

Le dernier point n'est pas technique. Un plan de marquage écrit, listant chaque événement, ses paramètres, son point de déclenchement et la convention retenue pour la valeur, est ce qui permet de reprendre le dispositif six mois plus tard sans tout redécouvrir. Sans lui, chaque intervenant réinterprète les chiffres à sa manière, et la première question posée par une agence qui reprend le dossier reste sans réponse.

Refaire le contrôle après chaque intervention

Le marquage d'une boutique est fragile par nature, parce qu'il dépend de gabarits, de sélecteurs et d'événements internes que la moindre mise à jour de thème ou d'extension peut déplacer. Une mise à jour de WooCommerce qui modifie la page de commande, un nouveau moyen de paiement qui remplace le formulaire par un cadre externe, une refonte du panier en affichage latéral suffisent à faire disparaître un événement sans aucun message d'erreur. La parade est une surveillance automatique simple : une alerte déclenchée dès qu'un événement du tunnel tombe à zéro sur vingt quatre heures alors qu'il ne l'était pas la veille. C'est le seul contrôle qui prévienne avant qu'un mois de données ne soit perdu.

Lire le tunnel sans se tromper de conclusion

Une fois les données fiables, reste à les interpréter, et c'est là que les erreurs coûtent le plus cher parce qu'elles orientent des décisions. Trois précautions de lecture évitent la majorité des contresens, et aucune n'est propre à WooCommerce : elles tiennent à la nature même des rapports d'entonnoir.

L'entonnoir n'est pas un parcours linéaire

Les visiteurs ne suivent pas les étapes dans l'ordre. Certains ajoutent au panier depuis une page de catégorie sans jamais voir la fiche, d'autres reviennent trois fois sur le panier, d'autres encore finalisent une commande commencée la semaine précédente. Un rapport d'entonnoir en étapes ouvertes, qui n'exige pas que les étapes précédentes aient été franchies, donne une image bien plus fidèle du comportement réel qu'un entonnoir fermé, qui exclut tous ces cas et affiche des taux artificiellement bas.

Segmenter avant de conclure

Un taux d'abandon global ne se corrige pas, parce qu'il n'existe pas : il est la moyenne de comportements très différents selon l'appareil, la source d'acquisition et le fait d'être client ou non. La même boutique perd souvent deux fois plus de visiteurs entre panier et commande sur téléphone que sur ordinateur, pour des raisons de formulaire, et la moyenne masque complètement ce déséquilibre. Le premier réflexe devant un mauvais chiffre est donc de le découper, pas de refaire la page.

Regarder les frais de port au bon endroit

L'abandon au moment où les frais de port apparaissent est le motif le plus fréquent sur les boutiques françaises, et il ne se voit pas si l'affichage des frais se fait sur la même page que l'entrée dans la commande. Découper le tunnel de commande en étapes distinctes, avec un événement à chaque changement d'écran, est la seule manière de rendre cet abandon visible. C'est un cas où la finesse du marquage change la conclusion, et où un tunnel trop grossier fait conclure à un problème de moyen de paiement là où le sujet est le prix affiché. Il vaut mieux dans ce cas afficher le montant des frais dès le panier, quitte à faire chuter le taux de passage à l'étape suivante, plutôt que de le révéler au dernier écran : la marche existe de toute façon, la question est seulement de savoir si on la mesure ou si on la subit.

Rattacher chaque étape à sa source d'acquisition

Le tunnel prend une autre dimension dès qu'on le croise avec l'origine des visiteurs, car la marche la plus haute n'est pas la même selon qu'on arrive d'une campagne payante, d'une recherche de marque ou d'un courriel. Une source qui amène beaucoup de vues de fiches et très peu d'ajouts au panier n'a pas un problème de tunnel mais un problème d'adéquation entre la promesse et la page d'arrivée. À l'inverse, une source dont le taux d'ajout est bon et le taux de commande mauvais renvoie bien à la boutique. Cette lecture croisée est ce qui transforme un rapport analytique en décision d'arbitrage budgétaire, et elle suppose que les paramètres de campagne soient posés correctement en amont, ce qui reste le point faible de la plupart des dispositifs.