Google Ads : le guide complet des paramètres wbraid et gbraid pour le suivi iOS

Introduction et enjeux

La mise à jour iOS 14.5 d'Apple et l'introduction du framework App Tracking Transparency (ATT) ont bouleversé le paysage de l'attribution publicitaire. En exigeant le consentement explicite des utilisateurs pour le suivi inter-applications, Apple a forcé les acteurs du marché à revoir leurs standards techniques.

Pour Google Ads, cela s'est traduit par la fin de l'utilisation du GCLID (Google Click Identifier : "?gclid=123") pour les utilisateurs iOS non-consentants. Pour maintenir la mesure des performances et continuer d'alimenter les algorithmes de Smart Bidding, Google a introduit deux nouveaux identifiants privacy-centric : les paramètres WBRAID et GBRAID.

Cet article détaille le fonctionnement de ces paramètres, leurs impacts sur votre analytique, et surtout, comment adapter votre infrastructure technique (GTM Server-Side, API de conversion) pour ne perdre aucune donnée.

💡 Ce qu'il faut retenir

Comprendre les identifiants : GCLID vs WBRAID vs GBRAID

Pour garantir la conformité avec le framework ATT tout en préservant l'attribution, Google a segmenté ses paramètres selon les environnements de conversion :

• GCLID (Google Click ID) : le standard historique. Il permet un suivi déterministe et individuel des clics. Il reste actif pour les environnements non-iOS (Android, Desktop) et les utilisateurs iOS ayant consenti au suivi.
• WBRAID (Web Browser Ad ID : "?wbraid=456") : principalement utilisé pour le trafic iOS sans consentement (ou limité par l'ATT). Il couvre les parcours "Web-to-App" et "App-to-Web", ainsi que le trafic Search sur iOS où le GCLID n'est pas disponible.
• GBRAID (Google Bridge for Attribution ID : "?gbraid=789") : conçu spécifiquement pour la mesure "App-to-App". Il entre en jeu lorsqu'un clic provient d'une propriété Google (comme l'application YouTube ou Gmail) et redirige l'utilisateur vers une autre application via un deep link.

Impacts sur Google Analytics et le pilotage Google Ads

L'intégration de wbraid et gbraid marque la transition d'un reporting "observé" vers un reporting "modélisé".

Modélisation et latence

Dans Google Analytics, le trafic impacté par l'ATT utilise l'apprentissage automatique pour combler l'absence de GCLID. Cette approche agrégée s'accompagne d'une latence statistique volontaire : il y a souvent un délai pouvant aller jusqu'à 48 heures avant que les conversions modélisées ne soient pleinement intégrées aux rapports. Ce délai est une protection technique intégrée pour empêcher la rétro-ingénierie des identités des utilisateurs sur de petits volumes de conversions.

Bidding et optimisation

L'objectif final des paramètres WBRAID et GBRAID est de "ré-alimenter" les modèles d'enchères intelligentes (Target CPA, Target ROAS) rendus aveugles par la perte du GCLID.

Implémentation technique : les nouveaux standards de collecte

Si vous envoyez des conversions hors ligne (Offline Conversion Imports) ou des leads via l'API Google Ads, les règles de validation sont devenues extrêmement strictes :

• Règle d'exclusivité : l'objet ClickConversion exige actuellement exactement un seul de ces trois identifiants : GCLID, WBRAID ou GBRAID. Fournir plus d'un identifiant déclenchera une erreur de validation.
• Variables personnalisées : Google Ads ne supporte pas l'utilisation de variables de conversion personnalisées (custom_variables) pour une conversion attribuée via un paramètre WBRAID ou GBRAID.
• Hachage des données 1st-party : l'utilisation de ces paramètres doit être combinée avec le Suivi avancé des conversions (Enhanced Conversions). Les données PII doivent être normalisées et hachées en SHA-256.

Roadmap 2025-2026 : anticipez les évolutions de Google

L'écosystème WBRAID et GBRAID n'est pas statique. Plusieurs jalons majeurs ont redéfini la manière dont nous gérons ces paramètres :

Octobre 2025 : importation possible du double identifiant

Depuis la mise à jour majeure de fin 2025 (active depuis le 3 octobre 2025), Google permet l'importation simultanée d'un GCLID et d'un GBRAID pour un même événement de conversion. Le moteur de matching de Google évalue les deux signaux, choisissant le plus précis pour l'attribution directe, tout en utilisant le second pour la modélisation agrégée.

Février 2026 : migration vers la Data Manager API

Depuis le 2 février 2026, l'API Google Ads standard n'accepte plus de nouveaux intégrateurs pour les session_attributes (qui fournissent le contexte de l'environnement de la conversion). Google a imposé une migration vers la Data Manager API, conçue pour consolider l'ingestion des paramètres WBRAID et GBRAID, des données first-party et des attributs de session dans un moteur unique et évolutif pour toute la Google Marketing Platform.

L'avis d'EdgeAngel

La prise en compte des paramètres WBRAID et GBRAID est désormais indispensable pour garantir la fiabilité du suivi de l'attribution sur iOS.

En 2026, on ne peut plus se contenter d'un tracking basique. Les annonceurs qui réussiront à maintenir un ROAS fiable sont ceux qui combineront :

• Le Server-Side Tagging (sGTM) pour un tracking robuste.
• La mise en place de Consent Mode v2.
• Les données 1st-party hachées pour combler les pertes de signaux déterministes.

Sources et liens utiles

• https://support.google.com/google-ads/answer/10417364?hl=fr
• https://support.google.com/analytics/answer/11367152?hl=fr
• https://support.google.com/google-ads/answer/16297842?hl=fr
• https://support.google.com/google-ads/answer/15479791?hl=fr
• https://support.google.com/google-ads/answer/16194756?hl=fr
• https://ads-developers.googleblog.com/2025/08/maximize-performance-of-your-google-ads.html
• https://developers.google.com/google-ads/api/docs/conversions/upload-clicks
• https://developers.google.com/google-ads/api/docs/conversions/troubleshooting
• https://developers.google.com/data-manager/api/devguides/events/send-events
• https://developers.google.com/tag-platform/security/concepts/consent-mode