Les 6 erreurs fatales avec les click identifiers (gclid, fbclid, msclkid)
Gclid, fbclid, msclkid : les erreurs courantes qui sabotent votre attribution. Whitelisting, stockage, ITP Safari et consentement UE.
Les click identifiers sont le nerf de la guerre en attribution publicitaire. Un simple gclid corrompu et vos conversions Google Ads disparaissent. Un fbclid tronque et Meta ne peut plus optimiser vos campagnes. Voici les six erreurs les plus courantes, inspirees des travaux de Simo Ahava, et comment les eviter.
Les click identifiers sont sensibles a la casse
Premiere surprise pour beaucoup de developpeurs : certains click identifiers sont sensibles a la casse. Le parametre ScCid de Snapchat ne fonctionnera pas si votre systeme le normalise en sccid. De meme, ne transformez jamais la valeur d’un gclid en minuscules. Ces identifiants sont des tokens opaques dont chaque caractere compte.
Voici un tableau recapitulatif des parametres par plateforme :
| Plateforme | Parametre | Sensible a la casse |
|---|---|---|
| Google Ads | gclid | Oui (valeur) |
| Meta Ads | fbclid | Oui (valeur) |
| Microsoft Ads | msclkid | Oui (valeur) |
| TikTok Ads | ttclid | Oui (valeur) |
| Twitter/X Ads | twclid | Oui (valeur) |
| Snapchat Ads | ScCid | Oui (nom ET valeur) |
| LinkedIn Ads | li_fat_id | Oui (valeur) |
Whitelister tous les parametres dans vos redirections
La deuxieme erreur fatale : vos redirections, votre CDN ou votre CMS supprime silencieusement les parametres inconnus. Chaque couche intermediaire entre le clic publicitaire et votre page de destination doit explicitement whitelister gclid, fbclid, msclkid, ttclid, twclid, ScCid et li_fat_id. Verifiez vos regles de redirection, vos reverse proxies et les parametres de votre CMS.
Stocker correctement les click identifiers
Le stockage doit se faire sur le domaine racine avec un path /. Si vous stockez un cookie gclid sur www.example.com uniquement, il ne sera pas accessible depuis shop.example.com. Autre piege classique : ne jamais stocker la valeur null, undefined ou une chaine vide. Avant d’ecrire le cookie, validez que le parametre existe et contient une valeur non vide.
Safari ITP et la duree de vie des cookies
Safari limite la duree de vie des cookies first-party poses via JavaScript a 7 jours (voire 24 heures dans certains cas avec ITP). Cela signifie qu’un utilisateur qui clique sur votre annonce Google un lundi et convertit le dimanche suivant ne sera plus attribue. La solution combine le stockage localStorage cote client et une ecriture de cookie server-side via un en-tete Set-Cookie HTTP. Pour approfondir le sujet Safari, consultez notre article sur l’impact de Safari sur l’attribution gclid.
Le consentement est obligatoire en UE
Stocker un click identifier dans un cookie ou dans le localStorage constitue un traitement de donnees personnelles au sens du RGPD. En Union europeenne, vous devez obtenir le consentement de l’utilisateur avant de stocker ces identifiants. Sans consentement, pas de cookie gclid, pas d’attribution. C’est pourquoi le Consent Mode et une CMP correctement configuree sont indispensables pour preserver un maximum d’attribution tout en respectant la reglementation.
Combiner client-side et server-side pour fiabiliser l’attribution
La strategie la plus robuste consiste a capturer les click identifiers cote client, les transmettre a votre serveur, puis les envoyer aux plateformes publicitaires via les API de conversions offline. Cette approche server-side contourne les limitations ITP, les ad blockers et les pertes de parametres dans les redirections. Elle garantit que chaque conversion est correctement attribuee, meme dans un environnement de plus en plus restrictif pour le tracking client-side.