Click identifiers (GCLID, FBCLID…) : les 7 erreurs qui faussent vos rapports GA4 — et comment les corriger avec GTM
Vos campagnes Google Ads semblent rentables. Vos rapports GA4 montrent autre chose. Ce n’est pas un problème de budget ou de créatif : c’est un problème de plomberie.
Quand un utilisateur clique sur une annonce — Google Ads, TikTok Ads, X — la plateforme génère un identifiant unique et l’ajoute en paramètre à l’URL de la landing page. Ces identifiants jouent un rôle décisif dans l’attribution des conversions, notamment les conversions offline. Le problème : entre la génération du clic et l’arrivée dans vos rapports, il y a au moins sept endroits où ça peut se casser.
Erreur 1 — Confondre ce que FBCLID fait (et ne fait pas) dans GA4
C’est la confusion la plus répandue. GA4 n’a aucun support natif pour les paramètres de tracking Facebook. Le FBCLID est conçu exclusivement pour les systèmes internes de Facebook. Il n’apporte strictement rien à GA4, qui ignore ce paramètre parce qu’il appartient à l’infrastructure d’une plateforme concurrente.
Conséquence directe : si vous lancez des Facebook Ads sans UTM parameters, le trafic apparaît comme « facebook.com » ou « l.facebook.com » et le channel grouping affiche « Referral » au lieu de « Paid Social ». Vous perdez toute visibilité sur vos campagnes dans GA4.
La recette GTM : créer une variable URL qui capture la valeur FBCLID, la stocker en cookie ou session storage, et alimenter vos UTMs en parallèle. Une idée reçue tenace : le FBCLID peut remplacer les UTM parameters. En réalité, ce n’est pas l’un ou l’autre — le FBCLID sert dans l’écosystème Meta, les UTMs servent l’attribution cross-plateforme.
Erreur 2 — Ne pas avoir de Conversion Linker sur toutes les pages
Le Conversion Linker est un tag utilitaire dans GTM qui stocke les paramètres publicitaires (comme le GCLID de Google Ads) dans les cookies first-party du navigateur. Cela permet à Google Ads, GA4 et Floodlight de voir les conversions même quand un utilisateur navigue entre les pages.
Par défaut, le GCLID n’est présent que sur la landing page. Si votre Conversion Linker ne déclenche pas sur toutes les pages — ou s’il est bloqué par votre CMP avant le consentement — vous perdez les conversions qui surviennent après la première page. GA4 ne préserve plus le GCLID dans un cookie pour les événements de conversion Google Ads, donc il ne suffit plus de linker vos comptes Google Analytics et Google Ads.
Erreur 3 — La casse du paramètre. Vraiment.
Les valeurs des click identifiers sont sensibles à la casse. Une valeur qui diffère uniquement par la casse est traitée comme une valeur entièrement différente. Le nom du paramètre URL lui-même est également sensible à la casse. &GCLID n’est pas la même chose que &gclid.
Ça paraît trivial. Ce ne l’est pas. Si votre CRM normalise les valeurs en lowercase avant de les uploader pour les offline conversions, le GCLID étant sensible à la casse, vous devez vous assurer de l’uploader correctement. Attribution cassée, sans aucun message d’erreur.
Erreur 4 — Les redirects qui avalent vos paramètres
Quand votre URL de landing page effectue une redirection — de http:// vers https://, ou via des geo-redirects — le paramètre GCLID peut être supprimé de l’URL. Vous ne le verrez jamais dans GTM Preview parce que le tag se déclenche après la redirection, sur l’URL finale propre.
On peut observer dans les logs : le lien d’entrée contient le GCLID, puis l’utilisateur est redirigé vers une URL sans lui. La seule solution viable : travailler avec les devs pour configurer le serveur afin de préserver les query parameters lors des redirects.
Erreur 5 — Votre site strip les click IDs lui-même
Le problème n’est parfois pas dans vos tags GTM, mais dans la façon dont votre site gère les paramètres inconnus dans les URLs. Même si vous avez correctement implémenté la capture des click identifiers dans GTM, votre site peut automatiquement supprimer ces identifiants de l’URL s’ils ne sont pas dans une allowlist.
Frameworks Next.js, routeurs SPA, certains CMS e-commerce : ils nettoient les URLs par défaut. Vérifiez dans GTM Preview si le page_location envoyé à GA4 contient encore le GCLID. Si le paramètre dl ne contient pas le GCLID, quelque chose dans le web GTM l’écrase.
Erreur 6 — Safari qui mange vos identifiants en silence
C’est le problème structurel du moment. Les click IDs des grandes plateformes — Google (gclid, dclid), Meta (fbclid), Bing (MSCLKID), TikTok (TTCLID) — sont les plus impactés : supprimés en mode privé, dans les messages de tiers, et de plus en plus dans les sessions Safari standard.
Safari représente environ 24% du trafic mondial. Aux États-Unis, c’est le navigateur mobile dominant avec plus de 50% de parts de marché. WebKit a clarifié que les paramètres de type campagne (comme les UTMs) sont autorisés, donc vos UTMs marketing ne sont pas impactés. Mais vos click IDs, si.
La réponse technique : lire le click ID depuis la requête HTTP avant que la protection côté client de Safari puisse le supprimer. Le Link Tracking Protection opère côté client — il modifie l’URL dans le navigateur avant que le JavaScript s’exécute. Mais la requête HTTP qui arrive sur votre serveur contient l’URL complète et non modifiée. Un serveur first-party lit le GCLID depuis la requête entrante au niveau serveur. C’est l’argument principal pour passer au Server-Side GTM.
Erreur 7 — Polluer vos rapports avec les FBCLID dans page_location
Erreur inverse des précédentes : trop garder plutôt que trop perdre. Les paramètres comme fbclid, _hsenc, mkt_tok, mc_cid polluent vos rapports. Ils fragmentent vos pages dans les rapports GA4 — une même URL apparaît en dizaines de variantes selon le FBCLID du clic.
La solution : stripper le paramètre FBCLID de l’URL, réécrire le champ page_location dans votre tag GA4, puis envoyer l’événement page_view. La façon la plus simple est d’installer le template de variable « Trim Query » depuis la GTM Community Gallery. Cela n’affectera pas les données historiques, mais vous ne verrez plus le FBCLID dans les nouvelles données collectées.
Méthode augmentée par IA : auditer votre dataLayer en 30 secondes
Ancienne école : ouvrir GTM Preview, cliquer sur chaque événement, inspecter manuellement les paramètres, noter dans un Google Sheet, répéter pour chaque environnement.
Méthode augmentée : copier le JSON de votre dataLayer (disponible dans la console DevTools via window.dataLayer) et passer ce prompt à un LLM :
Tu es un expert GA4/GTM. Voici le contenu de mon dataLayer :
[COLLER LE JSON ICI]
Analyse ce dataLayer et identifie :
1. La présence ou l'absence de GCLID, FBCLID, MSCLKID dans page_location
2. Si le Conversion Linker semble actif (cookie _gcl_aw présent ?)
3. Les paramètres de click ID qui seraient normalisés en lowercase
4. Les événements GA4 envoyés sans session_id ou client_id
5. Les paramètres UTM manquants sur les hits de type page_view
Pour chaque problème détecté, donne la correction GTM correspondante.
En moins de deux minutes, vous avez un rapport d’audit structuré. Ce n’est pas parfait — un LLM ne voit pas votre réseau, ne clique pas sur vos annonces — mais il détecte les patterns d’erreur sur des volumes de données que personne ne lirait manuellement.
La vraie question n’est pas « est-ce que mon tracking fonctionne ? » mais « quelle proportion de mes clics payants arrivent encore intacts dans GA4 en 2026 ? » Selon l’analyse du spécialiste tracking Luc Nugteren publiée en avril 2026, environ 20% des sessions Safari subissent déjà la suppression du GCLID dans les configurations actuelles. Autrement dit, si vous n’avez pas encore audité votre setup depuis l’été 2025, vous pilotez avec un cinquième de vos données paid media dans l’angle mort.
Catégories