GCLID, GBRAID, WBRAID : le guide du tracking B2B en 2026

Le GCLID (Google Click ID) est l’identifiant que Google Ads attribue à chaque clic sur une annonce. Le GBRAID est son équivalent pour le trafic iOS impacté par les restrictions Apple (ATT), utilisé principalement sur les campagnes Search, Shopping, Display et Performance Max. Les deux servent à relier une vente offline (devis signé, chantier confirmé) au clic publicitaire d’origine, mais ils ne fonctionnent pas de la même manière, n’ont pas la même durée de vie, et même la documentation officielle de Google ne les définit pas de façon cohérente d’une page à l’autre.

Si vous gérez du lead gen B2B sur Google Ads, vous avez probablement déjà entendu parler du GCLID. Vous avez peut-être configuré son import pour remonter vos ventes réelles. Ce que beaucoup d’agences n’ont pas encore vu venir : Google a ajouté un second identifiant, le GBRAID, et il concerne une part croissante de votre trafic sans que vous vous en rendiez compte.

Ce guide répond à quatre questions concrètes : à quoi sert chacun des deux identifiants, ce que les sources Google elles-mêmes ne définissent pas de la même façon, pourquoi la fenêtre de 90 jours du GCLID peut casser votre tracking sur un cycle de vente B2B, et ce qui change concrètement avec la bascule vers la Data Manager API.

Qu’est-ce que le GCLID et à quoi il sert

Le GCLID (Google Click Identifier) est une chaîne de caractères que Google ajoute automatiquement à l’URL de destination quand un utilisateur clique sur une de vos annonces. Il ressemble à ceci : gclid=Cj0KCQjw....

C’est un identifiant déterministe : il est lié à un clic précis, d’un utilisateur précis, sur une campagne, un groupe d’annonces et un mot-clé précis. Tant que vous capturez ce paramètre au moment où le prospect remplit votre formulaire et que vous le stockez dans votre CRM, vous pouvez plus tard renvoyer une conversion offline (devis signé, chantier confirmé) à Google Ads en lui associant ce GCLID exact. Google referme alors la boucle : il sait que ce clic précis a débouché sur une vente.

Ce mécanisme suppose que le prospect passe par votre site. Ce n’est pas le cas des formulaires de lead hébergés par Google, qui s’ouvrent directement dans l’annonce : Google connaît déjà l’origine du clic et n’a besoin d’aucun GCLID pour refermer la boucle. C’est ce que permet le gestionnaire de prospects, au prix d’un périmètre limité aux seuls leads que Google a lui-même collectés.

C’est le mécanisme derrière l’import de conversions offline, et il alimente directement le reporting Google Ads : sans ce paramètre, aucune vente réelle ne remonte dans vos rapports de campagne. Si vous découvrez le sujet, notre guide sur l’import de conversions offline dans Google Ads détaille chaque étape, de la capture jusqu’à l’envoi de la vente à Google.

Le GCLID existe depuis les débuts de Google Ads. Ce qui a changé récemment, c’est qu’il ne couvre plus tout le trafic à lui seul.

GBRAID et WBRAID : ce que Google dit, et ce qu’il ne dit pas de la même façon partout

Depuis les changements de confidentialité d’Apple (App Tracking Transparency, iOS 14.5 et versions suivantes), une partie des utilisateurs iOS refuse le pistage publicitaire classique, dans le navigateur comme dans l’app, un mouvement plus large de disparition des cookies tiers et de protection de la vie privée sur le web. Sur ce trafic, Google ne peut plus générer de GCLID individuel : ce serait contraire aux règles d’Apple. Google a donc introduit deux nouveaux paramètres d’URL pour mesurer la performance publicitaire sans identifier l’utilisateur : le GBRAID et le WBRAID.

Là où ça se complique : les propres pages d’aide de Google ne racontent pas exactement la même histoire. Voici ce que dit chaque source, verbatim, sans arbitrage de notre part :

Ce que ça veut dire en pratique pour une agence : ne perdez pas de temps à vouloir trancher la définition exacte de chaque paramètre, y compris Google ne le fait pas de façon uniforme sur ses propres pages d’aide. Ce qui compte opérationnellement, c’est que Google traite le GBRAID et le WBRAID comme des identifiants agrégés (pas de reconstruction du parcours d’un individu, contrairement au GCLID), compatibles avec les règles de confidentialité d’Apple, et que le seul point ferme et non ambigu dans toute la documentation est la restriction de campagnes du GBRAID : Search, Shopping, Display et Performance Max uniquement, aucun autre type de campagne.

En clair : si une partie de vos prospects cliquent depuis un iPhone et refusent le tracking, vous ne verrez jamais de GCLID pour ces clics. Vous verrez un GBRAID ou un WBRAID. Si votre formulaire ne capture que le GCLID, vous perdez silencieusement ces prospects du radar de l’attribution offline, sans même le savoir.

GCLID vs GBRAID : le tableau comparatif

Depuis octobre 2025, Google autorise l’envoi simultané d’un GCLID et d’un GBRAID pour un même événement de conversion, quelle que soit la campagne publicitaire d’origine. Le moteur de correspondance de Google évalue les deux signaux et privilégie le plus précis pour l’attribution directe, tout en utilisant le second pour son modèle d’attribution agrégée. Concrètement, si votre outil de capture stocke les deux identifiants sans avoir à choisir, vous couvrez l’ensemble du trafic, iOS compris.

La bascule vers la Data Manager API : la date à retenir

Google a fixé une date précise pour la fin de l’ancienne méthode d’import. La Data Manager API est une interface de programmation unique qui centralise l’envoi de données first-party (conversions, audiences) vers l’ensemble des produits Google, à la place d’une API dédiée par produit.

À partir du 15 juin 2026, l’import de conversions offline et les Enhanced Conversions for Leads via l’API Google Ads classique seront bloqués et redirigés vers la Data Manager API. C’est écrit noir sur blanc dans la documentation officielle : « Starting June 15, 2026, offline conversions import and enhanced conversions for leads uploads will be migrated to the Data Manager API and blocked in the Google Ads API » (Google Ads Help, answer/2998031). Un jeton développeur resté inactif entre janvier et juin 2026 ne sera pas non plus réautorisé sur l’ancien accès legacy. Second jalon distinct : dès avril 2026, les Enhanced Conversions unifient website tags, Data Manager et connexions API en un seul réglage.

Si votre agence ou votre développeur maintient encore un script basé sur l’ancienne API Google Ads, la fenêtre pour migrer se referme au 15 juin 2026, pas dans un vague “courant 2026”.

L’expiration à 90 jours du GCLID : ce qu’elle change pour votre tracking offline

Google impose une fenêtre d’attribution de 90 jours entre le clic et la conversion importée. Passé ce délai, même si vous avez conservé le GCLID et que la vente a réellement eu lieu, Google refuse l’import : le clic est trop ancien pour être crédité.

Pour un e-commerce ou un cycle de vente court, ce délai est confortable. Pour du lead gen B2B, c’est une contrainte réelle, et elle se chiffre facilement.

Prenez un cycle de vente B2B de 120 jours, ce qui n’a rien d’exceptionnel dans le conseil, l’industrie ou les services techniques. Le prospect clique sur l’annonce à J0. Le rendez-vous de découverte a lieu à J+10. Le devis part à J+45. La signature arrive à J+125. Si vous attendez la signature pour envoyer votre conversion offline avec le GCLID capturé au premier clic, vous êtes hors délai depuis 35 jours : la fenêtre de 90 jours s’est refermée à J+90, cinq semaines avant que le contrat ne soit signé. Le GCLID d’origine, pourtant toujours dans votre CRM, n’a plus aucune valeur aux yeux de Google.

La solution n’est pas de renoncer au tracking offline sur les cycles longs. C’est d’importer des micro-conversions intermédiaires qui restent dans la fenêtre :

• Un rendez-vous de découverte confirmé, avec une valeur symbolique
• Une démonstration réalisée
• Un devis envoyé

Chacun de ces événements, importé avec le GCLID d’origine dans les 90 jours qui suivent le clic, garde l’algorithme informé pendant que la vente se construit. Vous ne remontez pas la vente finale directement : vous jalonnez le parcours avec des signaux valorisés à chaque étape, tant que chaque signal reste dans la fenêtre. Sur l’exemple des 120 jours, le devis envoyé à J+45 reste largement dans les clous et donne à Google un signal de qualité bien avant que la fenêtre ne se ferme.

C’est le même principe que le signal stacking utilisé pour les faibles volumes de conversion : donner à Google plusieurs points de contact valorisés plutôt qu’un seul signal tardif qui arrive hors délai.

Le parallèle avec Meta : GCLID côté Google, fbclid côté Meta

Si vous diffusez aussi sur Meta Ads, la même logique s’applique avec un identifiant différent : le fbclid. Le principe est identique, capturer l’identifiant de clic au moment du formulaire, le stocker, puis l’associer à la vente quand elle se confirme. Mais les mécaniques de fenêtre d’attribution et de matching diffèrent entre les deux plateformes.

Nous détaillons la configuration complète, l’Event Match Quality Score et les pièges spécifiques à Meta dans notre guide sur Meta CAPI et les conversions offline. Pour une agence qui gère les deux canaux pour un même client, le vrai enjeu n’est pas de maîtriser chaque identifiant séparément : c’est d’avoir une seule infrastructure qui capture GCLID, GBRAID et fbclid en même temps, sur le même formulaire, sans configuration différente pour chaque plateforme.

Comment capturer GCLID et GBRAID sans bricolage

En théorie, la capture est simple : un script lit les paramètres d’URL au chargement de la landing page, dans le navigateur du visiteur, et les stocke dans un champ caché du formulaire, avant transmission au CRM. Le principe vaut pour n’importe quel site web, du plus simple formulaire de contact à un tunnel de conversion complexe.

En pratique, trois choses cassent régulièrement ce flux :

Les UTMs qui écrasent le paramètre. Si votre outil marketing ajoute ses propres paramètres UTM sans préserver le GCLID existant dans l’URL, l’identifiant est perdu avant même d’atteindre le formulaire.

Les formulaires non couverts. Un script présent sur la landing page principale mais absent d’un formulaire secondaire (popup, page de remerciement, outil tiers) laisse passer des clics sans capture.

L’absence de gestion du GBRAID. La plupart des scripts maison ont été écrits avant son existence. Ils capturent le GCLID, ignorent tout le reste, et perdent silencieusement une part croissante du trafic iOS.

C’est précisément ce que Sevya automatise : le script capture GCLID, GBRAID, WBRAID et fbclid sur l’ensemble des formulaires d’un client, quel que soit l’outil utilisé pour les construire (WordPress, no-code, landing page custom). Chaque identifiant est stocké dès la création du lead. Quand l’artisan ou le commercial qualifie ce lead comme rendez-vous confirmé, devis envoyé ou vente signée, Sevya envoie automatiquement l’événement à Google Ads avec le bon identifiant et la bonne valeur, dans la fenêtre des 90 jours.

L’agence n’a plus à se demander si le GCLID a survécu au parcours, ni si le trafic iOS est correctement couvert. L’infrastructure s’en charge une fois, pour tous les clients gérés.

Questions fréquentes

Qu’est-ce qu’un GCLID en Google Ads ?

Le GCLID est l’identifiant unique que Google Ads attribue à chaque clic sur une annonce. Il permet de relier une conversion, y compris une conversion offline enregistrée plus tard dans un CRM, au clic publicitaire exact qui l’a générée.

Quelle est la différence entre GCLID et GBRAID ?

Le GCLID est un identifiant déterministe, lié à un clic individuel, disponible sur la majorité du trafic. Le GBRAID est un identifiant agrégé, généré principalement sur le trafic iOS impacté par les restrictions Apple ATT. Il ne permet pas de reconstituer le parcours d’un utilisateur précis, mais il reste exploitable pour l’import de conversions.

Le GBRAID couvre-t-il les campagnes Display et Performance Max ?

Oui, Google le confirme explicitement pour Search, Shopping, Display et Performance Max, mais pas pour les autres types de campagne. C’est le seul point que toutes les pages d’aide de Google énoncent sans se contredire.

Le GCLID expire-t-il vraiment après 90 jours ?

Oui. Google refuse l’import d’une conversion offline si le clic associé au GCLID date de plus de 90 jours. Pour les cycles de vente B2B plus longs, la solution est d’importer des événements intermédiaires (RDV confirmé, devis envoyé) qui restent dans cette fenêtre, plutôt que d’attendre la vente finale.

Peut-on envoyer un GCLID et un GBRAID pour la même conversion ?

Depuis octobre 2025, oui. Google accepte l’envoi simultané des deux identifiants pour un même événement et choisit automatiquement le plus précis pour l’attribution.

Quand l’ancienne API Google Ads pour l’import de conversions offline sera-t-elle bloquée ?

Le 15 juin 2026. Passé cette date, l’import de conversions offline et les Enhanced Conversions for Leads via l’API Google Ads classique sont bloqués et redirigés vers la Data Manager API, selon la documentation officielle de Google.

Que faire si le GCLID est manquant sur un lead ?

Si le GCLID n’a pas été capturé au moment du clic, l’import de conversion classique n’est plus possible pour ce lead. Les Enhanced Conversions for Leads (email et téléphone hachés) offrent une solution de repli, à condition que ces données aient été collectées et transmises à Google au moment du formulaire.

En résumé

Le GCLID reste le socle du tracking offline sur Google Ads, mais il ne couvre plus tout le trafic à lui seul depuis que Google a introduit le GBRAID et le WBRAID pour s’adapter aux restrictions de confidentialité d’Apple. Une partie croissante de vos prospects iOS n’a tout simplement plus de GCLID à capturer, et même les pages d’aide officielles de Google ne définissent pas ces deux paramètres de façon identique d’une documentation à l’autre.

Trois réflexes à intégrer en 2026 : capturer les deux identifiants dès le formulaire, sans faire de tri ; importer des micro-conversions intermédiaires quand votre cycle de vente dépasse largement 90 jours, pour ne jamais perdre l’attribution en cours de route ; et anticiper la bascule du 15 juin 2026 vers la Data Manager API si votre stack d’import repose encore sur l’ancienne API Google Ads.

Ce n’est pas une question de complexité technique. C’est une question d’infrastructure fiable, qui capture ce qu’il faut, sans intervention manuelle, pour chaque client géré.

Par Cyril Vescan, Fondateur de Sevya.