gad_source et GBRAID : vos clics Ads passent en organic

Votre Paid Search recule depuis quelques semaines pendant que votre organic grimpe, et personne ne comprend pourquoi : le budget Google Ads n’a pas bougé, les campagnes tournent, l’interface Ads affiche les mêmes clics qu’avant. La tentation est de féliciter l’équipe SEO. Ne le faites pas tout de suite. Il y a de fortes chances qu’une partie de vos sessions payées soit en train de se faire recompter en google / organic, et la cause n’est pas chez Google : elle est sur votre propre site. Depuis le 30 juillet 2026, GA4 affiche un nouveau diagnostic, « Campaign data accuracy is affected by missing URL parameters », qui pointe précisément ce problème. Cet article vous montre comment vérifier en dix minutes si votre site rabote les paramètres gad_source et GBRAID, pourquoi c’est le pire type de bug pour un annonceur, et comment réparer la chaîne.

Le symptôme, en clair

Voici la signature du problème, telle que vous la lirez dans vos rapports. Votre canal Paid Search baisse sans raison de diffusion. En parallèle, votre google / organic monte, ou bien vous voyez gonfler une part de sessions en (not set) sur la dimension source/medium. Rien n’a changé côté campagnes : même budget, mêmes enchères, même volume de clics dans l’interface Google Ads. L’écart entre les clics affichés par Google Ads et les sessions Paid Search de GA4 s’ouvre, semaine après semaine.

Ce qui rend ce bug particulièrement vicieux, c’est qu’il ne ressemble pas à une panne. Une balise cassée, un tag qui ne charge plus, un pic de (not set) brutal : ça, tout le monde le repère et le traite en urgence. Ici, c’est l’inverse. Le chiffre déplacé va gonfler un canal que vous êtes ravi de voir monter. Votre SEO paraît enfin décoller, votre ROAS payant se dégrade « mystérieusement », et vous vous apprêtez à réallouer du budget sur la foi d’une donnée fausse. Un bug qui ressemble à une bonne nouvelle ne déclenche aucune alerte mentale. C’est exactement pour ça qu’il faut le chercher activement.

Si vous préférez partir d’un arbre de décision général avant de creuser ce cas précis, je l’ai détaillé dans le guide GA4 données manquantes : bug Google ou votre tracking ?. Ici, on va droit à la cause 2026.

Où trouver l’alerte dans GA4

Le nouveau diagnostic n’est pas une bannière plein écran. C’est un indicateur de qualité des données (data quality indicator) qui apparaît directement dans les rapports concernés, pas dans un centre de notifications que personne ne consulte. Le libellé exact à chercher est « Campaign data accuracy is affected by missing URL parameters ».

Deux détails opérationnels comptent. D’abord, tout le monde peut voir l’indicateur, mais seul un rôle Editor ou supérieur peut réellement agir sur la propriété : si c’est un analyste en lecture seule qui repère l’alerte, il faudra faire remonter. Ensuite, l’alerte propose un bouton « View URLs » qui liste les chemins de page fautifs, c’est-à-dire les landing pages où les paramètres arrivent rabotés. Cette liste est votre point de départ pour le débogage : ce sont ces URLs qu’il faut tester en priorité.

Dernier point, et c’est un piège classique : après correction, comptez 24 à 48 heures de latence avant que l’indicateur ne se mette à jour. Ne concluez pas que votre correctif a échoué parce que l’alerte est encore là le lendemain matin. Attendez un cycle complet avant de rejuger.

GBRAID et gad_source : que sont vraiment ces paramètres

Pour réparer, il faut d’abord comprendre ce qu’on répare. Ces paramètres ne sont pas des UTM, et ce ne sont pas non plus le GCLID auquel vous pensez.

GBRAID

GBRAID est un identifiant de clic hérité de l’écosystème iOS post-ATT (App Tracking Transparency, iOS 14+). Il a été introduit pour permettre l’attribution des campagnes qui touchent le trafic app-vers-web sur les appareils Apple, là où le GCLID classique ne pouvait plus être utilisé pour des raisons de confidentialité. Retenez surtout ceci : sur une part significative des sessions Safari, le GCLID est déjà retiré côté navigateur, mais GBRAID, lui, reste présent. GBRAID devient donc le dernier filet d’attribution payant sur ces sessions. Si vous voulez le détail de ce que Safari retire aujourd’hui, je l’ai documenté dans Safari 27 : ce qui casse vraiment dans votre tracking.

gad_source et gad_campaignid

gad_source (anciennement gad) est un paramètre qui identifie la source de l’annonce ayant généré le clic. Point important : il n’est pas personnalisable et il est partagé entre annonceurs, ce n’est donc pas un identifiant unique par utilisateur mais une information de provenance. gad_campaignid complète le dispositif en portant l’identifiant de campagne. Ensemble, ils permettent à GA4 de rattacher une session à Google Ads même quand l’identifiant de clic individuel manque.

Nuance à conserver, car elle évite les faux diagnostics : Google déploie gad_source progressivement. Sa propre documentation indique un déploiement « dans les mois qui viennent », et à l’heure où j’écris (septembre 2026), la généralisation est en cours mais pas terminée. Il est donc possible que le paramètre ne soit pas encore ajouté sur toutes vos URLs de clic. On y revient dans la section sur les faux positifs.

Le point clé : des identifiants agrégés

Voici l’idée qui change tout et que la quasi-totalité des contenus sur « GA4 Google Ads en organic » ratent, parce qu’ils traitent l’ancien problème (auto-tagging désactivé, liaison Ads-GA4 manquante, GCLID absent). GBRAID et les gad_* sont des identifiants agrégés. Ils servent de repli, activé précisément quand le GCLID ne peut plus faire son travail, c’est-à-dire quand l’utilisateur refuse ad_user_data. C’est le mécanisme que je décris dans Consent Mode v2 dans GA4 : sur refus de consentement publicitaire, l’attribution bascule vers ces signaux agrégés.

Conséquence logique et redoutable : le segment sur lequel vos identifiants agrégés opèrent est exactement celui sur lequel le GCLID a déjà lâché. Si votre site perd le GCLID côté navigateur (Safari) et rabote les identifiants agrégés côté redirection, vous n’avez plus aucun signal d’attribution payant sur ces sessions. Elles n’ont plus rien qui dise « Google Ads », donc GA4 fait ce qu’il fait toujours en pareil cas : il les range en organic.

Le test en 10 minutes

Assez de théorie, voici la manip concrète. L’objectif est de vérifier que les paramètres survivent jusqu’au moment où le tag se charge, pas seulement au premier hop de redirection.

Prenez une de vos landing pages Google Ads (idéalement une de celles listées par « View URLs ») et forgez une URL de test avec des paramètres factices, par exemple :

https://votre-site.com/landing/?gclid=test123&gad_source=1&gad_campaignid=123456

Ouvrez ensuite les outils de développement du navigateur, onglet Réseau, en cochant « Preserve log » (conserver le journal) pour ne pas perdre l’historique à chaque redirection. Collez l’URL, validez, et suivez la chaîne de requêtes. Ce que vous cherchez : l’URL finale effectivement chargée. Regardez si gad_source et gad_campaignid y sont encore présents, et à quelle position. Deux règles pratiques : les paramètres doivent rester dans la query string de l’URL finale, et ils doivent se situer avant le fragment # s’il y en a un, sinon le tag ne les lira pas.

Le point le plus important, celui que la plupart des tests ratent : ne vous arrêtez pas au premier saut. Un paramètre peut survivre à la redirection http vers https, puis disparaître à la redirection de canonicalisation qui suit. Ce qui compte, c’est l’état des paramètres au moment exact où votre tag Google (gtag ou GTM) s’exécute. Si le paramètre a disparu à ce moment-là, il est perdu, peu importe qu’il ait existé trois hops plus tôt.

Les cinq coupables habituels

Dans la quasi-totalité des cas, le paramètre saute à cause d’un maillon de votre propre chaîne. Voici les cinq suspects, par ordre de fréquence, avec le correctif :

Coupable	Ce qui se passe	Le correctif
Redirection de canonicalisation	La redirection www vers non-www (ou l’ajout/retrait du slash final) reconstruit l’URL sans recopier la query string	Configurer la règle pour préserver et repasser la query string (`$args` sur Nginx, `QSA` sur Apache)
Redirection de langue ou de géo	Le routage vers `/fr/` ou vers un sous-domaine pays réécrit l’URL et perd les paramètres	Propager les paramètres dans la cible de redirection, ou faire le routage côté serveur sans redirection visible
CDN ou WAF	Le CDN ou le pare-feu applicatif filtre les query strings inconnues qu’il juge suspectes	Ajouter `gad_source`, `gad_campaignid`, `gbraid`, `wbraid`, `gclid` à la liste des paramètres autorisés
Cache qui normalise l’URL	La couche de cache supprime les paramètres pour améliorer le taux de hit, servant une version « propre » de la page	Exclure les paramètres publicitaires de la normalisation de clé de cache
CMP ou script qui réécrit l’URL	Une CMP ou un script front modifie l’URL (souvent via `history.replaceState`) avant le chargement du tag	Vérifier l’ordre de chargement : le tag doit lire l’URL avant toute réécriture, ou lire les paramètres depuis une copie prise au plus tôt

Le fil rouge de ces cinq cas : le problème n’est presque jamais chez Google, il est dans un maillon que vous contrôlez. C’est une bonne nouvelle, parce que ça veut dire que vous pouvez le réparer sans dépendre de personne.

Chiffrer l’exposition dans BigQuery

Détecter le problème, c’est bien. Le chiffrer, c’est ce qui transforme un doute en décision. Si vous avez l’export GA4 vers BigQuery, vous pouvez mesurer précisément quelle part de vos sessions est concernée. L’idée : repérer les page_location qui portent un gclid mais où gad_source et gbraid sont absents, puis croiser avec le canal attribué pour voir combien atterrissent en organic.

-- Sessions avec gclid présent mais gad_source / gbraid absents de l'URL
SELECT
  COUNTIF(has_gclid AND NOT has_gad) AS clics_gclid_sans_gad,
  COUNTIF(has_gclid) AS total_clics_gclid,
  ROUND(SAFE_DIVIDE(COUNTIF(has_gclid AND NOT has_gad), COUNTIF(has_gclid)) * 100, 1) AS pct_exposes
FROM (
  SELECT
    (SELECT value.string_value FROM UNNEST(event_params)
       WHERE key = 'page_location') AS url
  FROM `votre_projet.analytics_XXXXXX.events_*`
  WHERE _TABLE_SUFFIX BETWEEN '20260801' AND '20260914'
    AND event_name = 'page_view'
), UNNEST([STRUCT(
  REGEXP_CONTAINS(url, r'[?&]gclid=') AS has_gclid,
  REGEXP_CONTAINS(url, r'[?&](gad_source|gbraid|gad_campaignid)=') AS has_gad
)])

La ligne pct_exposes vous donne le pourcentage de vos clics identifiés Google Ads (via gclid) qui arrivent sans le filet agrégé. Plus ce chiffre est élevé, plus votre risque de reclassement en organic est important le jour où le GCLID lâche. Pour aller plus loin sur le parsing de page_location et d’autres contrôles utiles, ma sélection est dans Les 10 requêtes BigQuery indispensables.

C’est cette section qui fait la différence avec les articles d’agence qui se contentent de décrire l’alerte : un chiffre chiffré sur vos données, c’est ce qui justifie de bloquer une heure d’ingénierie pour corriger une redirection.

Ce que ça ne répare pas

Soyons honnêtes jusqu’au bout, parce que promettre une solution miracle serait malhonnête et vous ferait perdre du temps.

Réparer votre chaîne de redirection ne récupère pas le GCLID que Safari retire côté navigateur : ça, c’est indépendant de votre site, c’est le navigateur qui décide. Ça ne récupère pas non plus les sessions où l’utilisateur a refusé le consentement au point qu’aucun signal n’est transmis. Et surtout, méfiez-vous du faux positif documenté par Google lui-même.

Encadré faux positif. Comme gad_source est encore en déploiement progressif (septembre 2026), il est possible que Google n’ait tout simplement pas encore commencé à l’ajouter sur les URLs de clic de votre compte. Dans ce cas, l’absence du paramètre n’est pas de votre fait : ce n’est pas votre site qui le rabote, c’est qu’il n’a jamais été ajouté à la source. Avant d’accuser vos redirections, faites le test des dix minutes : si vos paramètres factices survivent jusqu’au tag, votre chaîne est saine, et l’alerte reflète alors le déploiement en cours côté Google, pas un défaut chez vous.

Cette honnêteté n’est pas un aveu de faiblesse, c’est ce qui installe l’autorité : un audit qui distingue ce que vous pouvez corriger de ce qui vous échappe vaut mille fois mieux qu’une promesse creuse. Pour le reste des causes possibles de baisse de conversions cette année, voyez Attribution GA4 2026 : ce qui a changé.

La checklist de sortie

Voici ce que je déroulerais sur un compte concerné, dans l’ordre :

Repérez l’indicateur « missing URL parameters » dans vos rapports et cliquez sur « View URLs » pour récupérer la liste des pages fautives.
Faites le test des dix minutes sur deux ou trois de ces pages, en suivant la chaîne de redirection jusqu’à l’URL finale.
Identifiez le maillon coupable parmi les cinq suspects et appliquez le correctif correspondant.
Chiffrez votre exposition dans BigQuery pour prioriser (un problème sur 2 % des clics n’a pas la même urgence qu’un problème sur 40 %).
Écartez le faux positif : vérifiez que le paramètre est bien censé être présent sur votre compte avant d’incriminer votre site.
Attendez 24 à 48 heures après correction, puis vérifiez que l’indicateur se résorbe et que la ventilation Paid Search / organic se rétablit.

Ce cas rejoint une famille de bugs d’attribution que je documente cette année : c’est le jumeau interne de Microsoft Ads UTM : vos canaux GA4 ont changé, à cette différence près que là-bas le trafic sortait du Paid Search pour d’autres canaux payants, alors qu’ici il sort du payant tout court pour gonfler l’organic. À ajouter sans hésiter à votre audit GA4, surtout à l’approche du Q4 : réallouer un budget de Black Friday sur un organic qui est en réalité du payant mal rangé, c’est l’erreur qui coûte cher. Bouclez cette vérification avant le pic, elle est dans le même esprit que ma checklist tracking Black Friday 2026.