Votre plateforme publicitaire annonce quatorze conversions cette semaine. GA4 en compte six. Votre CRM, celui avec de vrais noms et de vraies factures attachées, en enregistre neuf. À un moment donné lors de la prochaine réunion, quelqu’un va demander quel chiffre est le bon, et la réponse honnête — celle que personne ne veut donner à voix haute — est que les trois sont corrects, et qu’aucun, pris isolément, ne signifie ce que tout le monde dans cette salle suppose qu’il signifie.
Voilà ce qu’on classe sous “problèmes de tracking de conversion“, et c’est rarement une seule chose cassée. C’est généralement trois ou quatre décisions individuellement raisonnables qui se contredisent dès qu’on pose leurs résultats côte à côte.
Le symptôme : vos chiffres ne concordent pas d’une plateforme à l’autre
Avant de corriger quoi que ce soit, acceptons un fait légèrement inconfortable : votre plateforme publicitaire, votre outil analytics et votre CRM n’allaient jamais produire des chiffres identiques, parce qu’ils ne mesurent pas le même événement, de la même façon, sur la même fenêtre temporelle, avec la même définition du “crédit”. Traiter un écart comme la preuve que quelque chose est cassé est la première erreur. La seconde, et la plus coûteuse, est de supposer que l’écart est normal et de ne jamais vérifier si une partie de cet écart est effectivement un bug.
Pourquoi GA4 et votre plateforme publicitaire ne s’accorderont jamais complètement
Deux raisons structurelles expliquent presque tous les écarts que vous constaterez :
- Des fenêtres d’attribution différentes. La plupart des plateformes publicitaires utilisent une fenêtre courte — souvent 7 jours au clic et 1 jour à la vue. GA4, en revanche, peut regarder en arrière sur plusieurs mois dans ses chemins de conversion. Un achat survenu douze jours après un clic peut obtenir tout le crédit dans GA4 et aucun crédit sur la plateforme publicitaire, parce que cette plateforme a cessé de compter ce clic comme pertinent après le septième jour.
- Des modèles d’attribution différents. Depuis le passage à l’attribution data-driven par défaut dans GA4, le crédit d’une conversion est distribué entre plusieurs points de contact selon un modèle algorithmique. La plupart des plateformes publicitaires rapportent d’une façon qui s’apparente au last-click pour leur propre canal. Même conversion, deux systèmes comptables entièrement différents.
Les problèmes GA4 courants qui ne viennent pas de l’attribution
Au-delà du désaccord sur les modèles, une part significative des problèmes de tracking de conversion GA4 vient de la configuration :
- Paramètres d’événements manquants. Un événement d’achat déclenché sans paramètre
valueetcurrencyapparaît quand même comme un événement dans GA4 — il ne se comportera simplement pas comme une conversion dans les rapports de revenus, ce qui ressemble à un échec de tracking alors que c’est un problème de paramétrage. - Consent Mode qui bloque les tags avant le consentement. Pour le trafic EEE et UK, les tags non correctement connectés au signal de consentement sont soit bloqués, soit modélisés — estimés plutôt que mesurés — ce qui peut ressembler exactement à “le tracking est cassé dans cette région” alors que c’est un problème de conformité.
- Regroupement de canaux par défaut mal configuré. Le trafic qui arrive sans paramètres UTM propres — via une redirection, un lien raccourci, une transition app-vers-web — finit souvent dans “Direct” ou “Non assigné” plutôt que dans le canal qui l’a réellement envoyé, gonflant silencieusement une bucket et affamant les canaux qui font réellement le travail.
- Seuils de données. Avec Google Signals activé, GA4 retient ou généralise certaines lignes de données en dessous d’un seuil de population pour des raisons de confidentialité. Un segment à faible trafic peut simplement ne pas apparaître, ce qu’on confond avec un échec de tracking alors que c’est une fonctionnalité de protection de la vie privée.
Le tracking côté serveur et la déduplication
Le tracking côté client seul — un pixel assis dans le navigateur — se dégrade en fiabilité depuis des années, entre les bloqueurs de publicités, les restrictions de confidentialité des navigateurs et la prévention intelligente du tracking qui rogne silencieusement ce qu’un pixel côté navigateur peut effectivement voir. La solution plus durable, et celle qui vaut la peine d’être construite correctement plutôt que de patcher indéfiniment, est le tracking côté serveur via une API de conversions — en envoyant l’événement depuis votre propre serveur plutôt qu’en comptant sur le navigateur du visiteur pour le rapporter.
Bien fait, en suivant la documentation de l’API Marketing de Meta par exemple, cela capture des conversions que le pixel côté navigateur seul aurait manquées. Mal fait, cela crée un nouveau problème : le même événement comptabilisé deux fois — une fois depuis le navigateur, une fois depuis le serveur — ce qui gonfle vos chiffres d’une façon qui ressemble à une bonne nouvelle jusqu’à ce que quelqu’un les réconcilie avec les revenus réels.
Ce que les tutoriels omettent systématiquement
- La déduplication dépend d’une correspondance exacte, pas approximative. Les événements pixel navigateur et les événements CAPI serveur doivent partager le même event_id pour que la plateforme les reconnaisse comme la même conversion plutôt que deux conversions distinctes. Générez cet ID de façon incohérente — d’un côté côté client et de l’autre côté serveur — et vous avez un double comptage silencieux qui ressemble à une performance solide et est en réalité un bug.
- Les données personnelles hachées doivent être normalisées avant le hachage, sinon elles ne correspondent à rien. Envoyer un email ou un numéro de téléphone à une API de conversions signifie le hacher en SHA-256, mais la plateforme s’attend à ce que la valeur soit en minuscules et sans espaces avant le hachage. Hachez “Jean@Email.com ” tel quel et le hash résultant ne correspondra à rien côté plateforme, et l’événement sera silencieusement écarté sans erreur visible.
- Les bloqueurs de publicités ne sont pas un bug de tracking — ce sont simplement une part de votre trafic qui sera toujours invisible aux outils côté client. Avant de passer des jours à traquer un “mystère de conversions manquantes”, séparez ce qui est une configuration véritablement cassée de la part des visiteurs dont le navigateur n’allait jamais laisser se déclencher un pixel côté client.
- Votre fenêtre d’attribution est un paramètre, pas une valeur par défaut immuable. GA4 permet de l’ajuster dans les paramètres Admin, et la plupart des comptes tournent encore sur celle configurée le jour de la création de la propriété, souvent sans correspondance avec les fenêtres beaucoup plus courtes utilisées par les plateformes publicitaires.
- “Ça fonctionnait en Preview” ne veut pas dire “c’est en production”. Les containers Tag Manager restent non publiés plus souvent que personne ne veut l’admettre, et un tag confirmé fonctionnel en Preview mais jamais publié fonctionne exactement comme un tag qui n’a jamais été créé.
Où ça s’inscrit
Le tracking de conversion n’échoue pas parce que quelqu’un est négligent — il échoue parce que pixels côté navigateur, événements côté serveur, modèles d’attribution et exigences de consentement sont tous des systèmes indépendamment raisonnables qui n’ont jamais été conçus pour s’accorder naturellement. Obtenir des chiffres qui se réconcilisent réellement demande de construire délibérément autour de cette réalité plutôt que d’espérer qu’elle se résoudra d’elle-même.
C’est précisément le travail derrière le système de tracking de conversion qu’OJC Labs construit pour ses clients : GA4 configuré correctement, événements côté serveur dédupliqués contre le pixel navigateur, attribution expliquée plutôt que simplement reportée.
Si vos tableaux de bord se contredisent depuis plus longtemps que vous ne le souhaiteriez, contactez-nous et nous trouverons quels chiffres disent vraiment la vérité.