40 commandes dans WooCommerce, 28 dans GA4 : où sont passées les douze autres ?

Douze commandes manquantes, ce n’est presque jamais un bug unique. Ce sont plusieurs petites fuites, et tant que vous les additionnez dans un seul chiffre, vous ne corrigez rien. L’article d’Analytify à l’origine de ce sujet cite des rapports en retard, des événements incomplets, des redirections de paiement, le consentement, le cache et des balises concurrentes. La liste est juste. Il manque la méthode pour la parcourir.

Fixez d’abord la référence

WooCommerce est votre vérité comptable. GA4 mesure ce qui s’est déclenché dans un navigateur, et un événement purchase n’est pas une commande. Revenuescope le formule ainsi : un purchase GA4 est la trace d’une mesure déclenchée dans un navigateur.

Alignez donc le périmètre avant de comparer. Gardez les statuts payés, mettez le même fuseau horaire des deux côtés et isolez les commandes créées à la main. Les renouvellements d’abonnement sont un cas à part : ils se font sans action du client, donc aucune page de confirmation ne charge. Cela peut déjà expliquer deux ou trois lignes sur douze.

Quelles sont les fuites, et que dit la documentation ?

Le consentement. Google documente deux modes. En mode basique, les balises ne se chargent pas avant que l’utilisateur ait interagi avec le bandeau. En mode avancé, elles se chargent à l’arrivée et envoient des pings sans cookies tant que le consentement est refusé. Ces pings alimentent la modélisation comportementale et des conversions, qui comble les trous des rapports. À ma connaissance, cette modélisation ne recrée pas de ligne avec un transaction_id exploitable dans l’export BigQuery. La documentation consultée ne le dit pas, donc testez-le sur votre propriété. Côté CNIL, des analyses tierces indiquent que GA4 ne figure pas sur la liste des outils exemptés et reste soumis au consentement. Je n’ai pas relu la page officielle, vérifiez-la.

Les bloqueurs. Aucune source primaire ne chiffre ce point. Analytify avance un écart normal de 5 à 10 % lié aux bloqueurs, aux réglages de navigateur et au consentement. C’est un chiffre d’éditeur de plugin, pas une norme. Ici, 12 sur 40 font 30 %, ce qui dépasse largement cet ordre de grandeur.

Les transaction_id. Google documente que la déduplication ne porte que sur un même ID provenant du même utilisateur. Elle ne fonctionne que sur les flux web. Un ID vide est pire : tous les purchase avec transaction_id= » » sont dédupliqués ensemble. Vos commandes semblent alors manquer alors qu’elles ont été avalées. Un même ID réutilisé pour des commandes différentes peut provoquer un sous-comptage important. Amplio Data observe aussi que la déduplication ne tient que dans une fenêtre limitée. Je n’ai pas trouvé cette fenêtre dans la page d’aide de Google, considérez-la comme une observation.

Confirmation non chargée et paiements tiers. L’acheteur paie chez un prestataire, ferme l’onglet, et WooCommerce valide par webhook. Conversios décrit ce mécanisme : la commande aboutit dans WooCommerce, mais GA4 n’enregistre aucun purchase. Le cache de page produit le même effet.

Ces pages d’aide Google sont modifiées sans préavis. Le comportement décrit peut évoluer, relisez-les avant de figer vos règles.

Comment construire la jointure

Exportez les commandes WooCommerce : order_id, statut, moyen de paiement, canal de création, date, montant. Côté BigQuery, groupez les événements purchase par ecommerce.transaction_id et comptez-les, comme le propose OWOX. Faites ensuite une jointure complète sur l’identifiant. Chaque commande tombe dans une case : appariée, absente de GA4, doublon GA4, ID vide, ou purchase GA4 sans commande.

Pour retrouver la session d’une commande absente, stockez le client_id et le ga_session_id dans les métadonnées de commande au moment du checkout. Sans ce pont, vous resterez aveugle.

Où le LLM aide, et où il invente

Commencez par des règles déterministes : canal admin, renouvellement, statut impayé. Le LLM ne traite que le résidu, qu’il s’agisse de douze lignes ou de deux cents. Envoyez-lui des attributs, jamais d’emails ni de noms.

Vous êtes analyste tracking e-commerce. Pour chaque commande absente de GA4, classez la cause probable : paiement_tiers_sans_retour, commande_hors_navigateur, id_vide_ou_reutilise, delai_ou_fuseau, invisible_consentement_ou_bloqueur, indetermine.
Données par ligne : order_id, payment_method, created_via, statut, user_agent, événements GA4 de la session (begin_checkout, add_payment_info), consentement si connu.
Répondez en JSON : order_id, cause, confiance (0 à 1), indice_utilise.
Si les indices ne suffisent pas, répondez indetermine. N'inventez aucune donnée.

Remarquez la catégorie « invisible ». Sans journal de consentement côté serveur, un refus de cookies et un bloqueur laissent la même absence de trace. Aucun modèle ne les départagera honnêtement. Un begin_checkout présent, un paiement PayPal et pas de purchase, en revanche, désignent presque sûrement le paiement tiers.

Le LLM propose et vous validez. Relisez dix lignes à la main et mesurez l’accord avant de lui faire confiance.

Un tableau de bord d’écart, une ligne par jour

Planifiez une requête BigQuery quotidienne et branchez-la sur Looker Studio. Chaque jour contient les commandes payées WooCommerce, les purchase distincts GA4, le taux d’appariement, les doublons, les ID vides et la répartition par cause. Calculez sur J-2, car des éditeurs comme Conversios évoquent des rapports e-commerce GA4 qui peuvent traîner 24 à 48 heures. C’est un retour terrain, pas une garantie de Google.

Ne fixez pas de cible de rapprochement universelle. Alertez plutôt quand le taux dérive de plusieurs points par rapport à votre médiane sur 28 jours. Un écart stable de 12 % se comprend. Un écart qui bouge d’un coup a une cause datable.

Ce soir, exportez les commandes d’hier, faites la jointure sur transaction_id et ne comptez que trois choses : les manquantes, les doublons et les ID vides. Le reste de la classification peut attendre demain.