Google Ads: la guía completa de los parámetros wbraid y gbraid para el seguimiento en iOS

Introducción y retos

La actualización iOS 14.5 de Apple y la introducción del framework App Tracking Transparency (ATT) trastocaron el panorama de la atribución publicitaria. Al exigir el consentimiento explícito de los usuarios para el seguimiento entre aplicaciones, Apple obligó a los actores del mercado a revisar sus estándares técnicos.

En Google Ads, esto se tradujo en el fin del uso del GCLID (Google Click Identifier: «?gclid=123») para los usuarios de iOS que no dan su consentimiento. Para mantener la medición del rendimiento y seguir alimentando los algoritmos de Smart Bidding, Google introdujo dos nuevos identificadores privacy-centric: los parámetros WBRAID y GBRAID.

Este artículo detalla el funcionamiento de estos parámetros, sus impactos en tu analítica y, sobre todo, cómo adaptar tu infraestructura técnica (GTM Server-Side, API de conversiones) para conservar todos los datos.

💡 Lo esencial

Entender los identificadores: GCLID vs WBRAID vs GBRAID

Para cumplir el framework ATT y preservar a la vez la atribución, Google segmentó sus parámetros según los entornos de conversión:

• GCLID (Google Click ID): el estándar histórico. Permite un seguimiento determinista e individual de los clics. Sigue activo en los entornos que no son iOS (Android, ordenador) y para los usuarios de iOS que han dado su consentimiento al seguimiento.
• WBRAID (Web Browser Ad ID: «?wbraid=456»): se usa principalmente para el tráfico de iOS sin consentimiento (o limitado por el ATT). Cubre los recorridos «Web-to-App» y «App-to-Web», así como el tráfico de Search en iOS cuando el GCLID no está disponible.
• GBRAID (Google Bridge for Attribution ID: «?gbraid=789»): diseñado específicamente para la medición «App-to-App». Entra en juego cuando un clic procede de una propiedad de Google (como la aplicación de YouTube o Gmail) y redirige al usuario a otra aplicación mediante un deep link.

Impactos en Google Analytics y en la gestión de Google Ads

La integración de wbraid y gbraid marca la transición de un reporting «observado» a un reporting «modelado».

Modelado y latencia

En Google Analytics, el tráfico afectado por el ATT usa el aprendizaje automático para suplir la ausencia de GCLID. Este enfoque agregado va acompañado de una latencia estadística deliberada: suele haber un retraso de hasta 48 horas antes de que las conversiones modeladas se integren por completo en los informes. Este retraso es una protección técnica integrada para impedir la ingeniería inversa de las identidades de los usuarios con volúmenes pequeños de conversiones.

Pujas y optimización

El objetivo final de los parámetros WBRAID y GBRAID es «volver a alimentar» los modelos de puja inteligente (CPA objetivo, ROAS objetivo), que la pérdida del GCLID había dejado a ciegas.

Implementación técnica: los nuevos estándares de recogida de datos

Si envías conversiones offline (Offline Conversion Imports) o leads a través de la API de Google Ads, las reglas de validación se han vuelto extremadamente estrictas:

• Regla de exclusividad: el objeto ClickConversion exige actualmente exactamente uno de estos tres identificadores: GCLID, WBRAID o GBRAID. Proporcionar más de un identificador provocará un error de validación.
• Variables personalizadas: Google Ads no admite el uso de variables de conversión personalizadas (custom_variables) en una conversión atribuida mediante un parámetro WBRAID o GBRAID.
• Hash de los datos 1st-party: el uso de estos parámetros debe combinarse con las conversiones mejoradas (Enhanced Conversions). Los datos PII deben normalizarse y pasar por un hash SHA-256.

Hoja de ruta 2025-2026: anticipa los cambios de Google

El funcionamiento de WBRAID y GBRAID evoluciona. Varios hitos importantes han redefinido la manera en que gestionamos estos parámetros:

Octubre de 2025: importación posible del doble identificador

Desde la gran actualización de finales de 2025 (activa desde el 3 de octubre de 2025), Google permite importar a la vez un GCLID y un GBRAID para un mismo evento de conversión. El motor de matching de Google evalúa las dos señales, elige la más precisa para la atribución directa y usa la segunda para el modelado agregado.

Febrero de 2026: migración a la Data Manager API

Desde el 2 de febrero de 2026, la API estándar de Google Ads ya no acepta nuevos integradores para los session_attributes (que aportan el contexto del entorno de la conversión). Google impuso una migración a la Data Manager API, diseñada para consolidar la ingesta de los parámetros WBRAID y GBRAID, de los datos first-party y de los atributos de sesión en un motor único y escalable para toda la Google Marketing Platform.

La opinión de EdgeAngel

Tener en cuenta los parámetros WBRAID y GBRAID es ahora imprescindible para que el seguimiento de la atribución en iOS sea fiable.

En 2026, un tracking básico ya no basta. Los anunciantes que mantengan un ROAS fiable serán los que combinen:

• El etiquetado server-side (sGTM) para un tracking sólido.
• La implementación de Consent Mode v2.
• Los datos 1st-party con hash para compensar la pérdida de señales deterministas.

Fuentes y enlaces útiles

• https://support.google.com/google-ads/answer/10417364?hl=es
• https://support.google.com/analytics/answer/11367152?hl=es
• https://support.google.com/google-ads/answer/16297842?hl=es
• https://support.google.com/google-ads/answer/15479791?hl=es
• https://support.google.com/google-ads/answer/16194756?hl=es
• 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