Conversiones de app en iOS a cero en Google Ads: la solución de gBraid

Si tu cuenta de Google Ads muestra conversiones de app sanas en Android mientras iOS marca cero, y el diagnóstico dice “Your gBraid conversion measurement setup is incorrect” (la configuración de medición de conversiones con gBraid es incorrecta), lo más probable es que tus datos estén bien. Tu atribución no. Los clics en anuncios de iOS llevan un parámetro gbraid en lugar de un GCLID, y si tu app nunca pasa ese parámetro a sus SDKs de medición, ninguna conversión de iOS recibe crédito.

Me pasó exactamente esto con un marketplace de reservas suizo cuya medición gestiono. El MMP de la app mostraba que iOS generaba más del triple de compras in-app que Android. Google Ads atribuía una sola conversión a iOS, frente a veinte en Android. Mismas campañas, misma app, mismas semanas. iOS superaba a Android en silencio en todas partes menos en el informe que decide los presupuestos.

Esta es la tercera parte de la serie sobre seguimiento de apps (primera parte: la arquitectura de doble stack, segunda parte: fallos silenciosos en los ingresos). Es la más específica de las tres, a propósito: este fallo tiene un síntoma preciso, una causa precisa y una solución precisa, y casi nada de lo que se ha escrito sobre él cubre el lado de la app.

En resumen

• Síntoma: las conversiones de la app en Android se atribuyen con normalidad, las acciones de conversión de iOS marcan cero o “Needs attention”, y el diagnóstico de Google Ads informa de una configuración de gBraid incorrecta, a menudo tanto en tus acciones de conversión de Firebase como en las del MMP.
• Causa: desde ATT, los clics en anuncios web-to-app de iOS se miden con gbraid/wbraid en lugar de GCLID. El parámetro viaja en la URL del clic. Si tu app no pasa de forma explícita la URL de apertura a Firebase, el parámetro nunca se captura y las conversiones de iOS no se pueden asociar a las campañas.
• La solución principal es una sola llamada: Analytics.handleOpen(url) en cada punto de entrada de URL de iOS (.onOpenURL de SwiftUI, los métodos del delegate de UIScene, los handlers de Universal Links), con el SDK de Firebase para iOS 6.32.2 o posterior.
• Requisitos complementarios: Universal Links con la query string intacta de principio a fin, el etiquetado automático activado y el reenvío de gbraid web-to-app de tu MMP habilitado como vía secundaria.
• La recuperación es gradual, no inmediata: la captura de gbraid solo existe en las versiones actualizadas de la app, así que la atribución se recupera a medida que los usuarios actualizan. Prevé una ventana de validación de una a dos semanas.

Primero, confirma que es un hueco de atribución y no una pérdida de datos

Antes de tocar código, comprueba que las conversiones existen. Abre tu MMP o Firebase y compara los eventos de compra in-app de iOS y Android en el mismo periodo. En nuestro caso la imagen no dejaba lugar a dudas: iOS disparaba más del triple del volumen de compras de Android, con los ingresos llegando correctamente, mientras la vista por canal de Google Ads le atribuía a iOS una única conversión.

Esa distinción lo cambia todo en la solución. Los eventos se disparan, los valores van adjuntos, los usuarios convierten. El único eslabón roto es la asociación entre un clic en un anuncio de iOS y la conversión in-app posterior. No dejes que nadie reconstruya el seguimiento de eventos para resolver un problema de atribución.

Revisa también la cronología: la última conversión de iOS registrada en Google Ads tenía tres semanas. Si la tuya coincide con un lanzamiento de la app o una actualización del SDK, ahí tienes tu punto de regresión.

gBraid vs. wbraid vs. GCLID: por qué se rompe la atribución en iOS

En Android, y en iOS antes de App Tracking Transparency, un clic en Google Ads lleva un GCLID que sobrevive hasta la app y permite a Google asociar el clic con la conversión.

Desde ATT, ese mecanismo ha desaparecido para la mayor parte del tráfico de iOS. Google lo sustituyó por dos parámetros que protegen la privacidad: wbraid para recorridos web-to-web y gbraid para web-to-app. El recorrido que importa aquí: un usuario toca tu anuncio en Safari en iOS, llega a tu sitio o a un intersticial de la App Store, abre la app y convierte. Ese recorrido lleva gbraid en la URL.

Aquí está la trampa. En la web, las etiquetas de Google capturan estos parámetros automáticamente. En una app, nada es automático. Las apps construidas con UISceneDelegate o SwiftUI tienen que pasar de forma explícita la URL de apertura a Firebase para que pueda extraer el valor de gbraid. Si te saltas esa llamada, el parámetro muere en la puerta de la app: el clic ocurrió, la conversión ocurrió, y ningún sistema del mundo puede conectarlos después.

Por eso el fallo solo afecta a iOS, por eso afecta a la vez a tus acciones de conversión de Firebase y del MMP, y por eso puede aparecer de la nada cuando una app migra a SwiftUI o a un ciclo de vida basado en escenas.

La solución

1. Pasa la URL de apertura a Firebase (la solución principal)

Una llamada, en cada lugar donde iOS le entrega una URL a tu app:

SwiftUI:

import FirebaseAnalytics

.onOpenURL { url in
    Analytics.handleOpen(url)
}

Delegate de UIScene:

// scene(_:openURLContexts:)  and  scene(_:continue:) for Universal Links
Analytics.handleOpen(url)

Objective-C:

@import FirebaseAnalytics;
[FIRAnalytics handleOpenURL:url];

Cubre todos los puntos de entrada: los esquemas de URL personalizados, los Universal Links y la vía de continue-user-activity. El gbraid puede llegar por cualquiera de ellos, y el que te saltes es justo el que usa tu tráfico.

SDK mínimo de Firebase para iOS: 6.32.2. Si tu app es anterior, actualizar el SDK forma parte de la solución.

2. Asegúrate de que la URL llega de verdad a ese handler, con los parámetros intactos

Analytics.handleOpen(url) solo puede extraer lo que le llega. Antes, en la cadena, se tienen que cumplir dos cosas:

• Los Universal Links funcionan: el entitlement de associated domains en la app y un archivo AASA válido en tu dominio, para que la URL de destino con gbraid abra la app y no el navegador.
• La query string sobrevive: ninguna redirección de la cadena (acortadores de enlaces, páginas intersticiales, herramientas de deferred deep linking) puede eliminar los parámetros de la URL. Una redirección que descarta la query string mata la atribución igual que la llamada al handler que falta.

Pruébalo de principio a fin: haz clic en una URL etiquetada real desde un dispositivo iOS y registra la URL que recibe tu handler. Si no contiene gbraid=, recorre la cadena hacia atrás.

3. Los requisitos previos (verifícalos, no los des por hechos)

Firebase vinculado a GA4, GA4 vinculado a Google Ads, los eventos in-app marcados como conversiones, las acciones de conversión importadas en Google Ads y el etiquetado automático activado en la cuenta de Google Ads. Todo esto suele existir en una configuración de Android que funciona, y precisamente por eso nadie lo vuelve a comprobar. Vuelve a comprobarlo.

4. La vía paralela del MMP

Si usas el doble stack de la primera parte, tu MMP es la fuente de conversiones Secondary para Google Ads y también debería reenviar el gbraid en sus postbacks del lado del servidor:

• Actualiza el SDK del MMP para iOS a una versión con soporte nativo de gbraid/wbraid.
• Confirma que los Universal Links y el deferred deep linking están configurados en el SDK del MMP para que capture el parámetro de la URL de destino.
• En la configuración de partner de Google Ads del MMP, confirma que la medición web-to-app está habilitada.

Verificación y qué esperar

Después de desplegar la versión corregida:

• Diagnóstico: el error de gBraid en Google Ads (Objetivos y, dentro, el diagnóstico) debería desaparecer en las acciones de conversión afectadas.
• Latencia: las conversiones basadas en gbraid pueden tardar hasta 72 horas en procesarse, frente a menos de 12 con GCLID. No juzgues la solución a la mañana siguiente.
• Recuperación gradual: esta es la parte que sorprende. La solución solo existe en la versión actualizada, así que la atribución se recupera a medida que tus usuarios de iOS actualizan la app. Cuenta con una o dos semanas antes de que la tendencia se pueda leer, menos si incentivas las actualizaciones.
• La métrica de éxito: las conversiones de iOS atribuidas en Google Ads deberían subir desde casi cero hasta acercarse a lo que tu MMP dice que iOS produce realmente. En nuestro caso eso significaba que el recuento atribuido pasara de una hacia las decenas, como en Android, que el volumen real siempre había justificado.

Errores comunes

1. Reconstruir el seguimiento de eventos para arreglar un hueco de atribución. Los eventos nunca estuvieron rotos. Confirma que los datos existen antes de cambiar lo que los produce.
2. Añadir el handler en un punto de entrada de URL y olvidar los demás. SwiftUI, el delegate de escena y la continuación de Universal Links son tres puertas. Cubre las tres.
3. Una redirección que elimina la query string. Todo lo que viene después está bien y la atribución muere igualmente. Prueba con un dispositivo real y un clic etiquetado real.
4. Juzgar la solución a las 24 horas. Entre las 72 horas de procesamiento y un despliegue que depende de las actualizaciones, el silencio de los primeros días no significa nada.
5. Olvidar la vía del MMP. Google se recupera, pero tu fuente Secondary sigue ciega, y la comprobación cruzada de la segunda parte pierde su sentido.

FAQ

¿Cómo sé si esto afecta a mi app?

Compara las conversiones de iOS y Android en Google Ads con el mismo reparto en tu MMP o en Firebase. Un volumen real de iOS sano junto con una atribución de iOS casi nula en Google Ads es la firma. El diagnóstico explícito (“gBraid conversion measurement setup is incorrect”) lo confirma.

¿Es lo mismo que SKAdNetwork?

No. SKAN (ahora AdAttributionKit) es la capa de atribución agregada e independiente de Apple para las campañas de instalación de apps. gBraid cubre específicamente la medición web-to-app de Google en entornos con consentimiento limitado. Una configuración completa de iOS necesita que ambas funcionen; este post cubre la mitad de gbraid.

¿Afecta a las App Campaigns de Google o solo a las campañas web?

gBraid se aplica a los recorridos que empiezan en la web: clics de Search, Shopping, Display y Performance Max que terminan en la app. Las instalaciones de App Campaigns se miden por su propia vía.

Lo arreglamos y iOS sigue por debajo de Android. ¿Por qué?

Tres razones legítimas: no todos los usuarios han actualizado la app todavía, el procesamiento de gbraid tarda hasta 72 horas, y algunos recorridos de iOS siguen siendo imposibles de medir por diseño con ATT. El objetivo es la tendencia hacia la realidad de iOS que muestra tu MMP, no la paridad desde el primer día.

¿Puedo arreglarlo sin publicar una nueva versión de la app?

No. La llamada que falta vive en el binario de la app. Por eso la recuperación también es gradual: la solución llega con la versión, y la atribución vuelve usuario a usuario a medida que actualizan.

Puntos clave

1. iOS a cero con Android sano es casi siempre un problema de atribución, no de datos. Demuestra que las conversiones existen en tu MMP antes de tocar nada.
2. La causa raíz es una sola llamada que falta: pasa cada URL de apertura a Firebase con Analytics.handleOpen(url), con el SDK 6.32.2 o posterior, en todos los puntos de entrada de URL.
3. El parámetro tiene que sobrevivir al recorrido: Universal Links funcionando, AASA válido, ninguna redirección que elimine la query string.
4. Arregla también el reenvío de gbraid del MMP, o tu fuente Secondary seguirá ciega.
5. La recuperación depende de la versión y es gradual. Dale dos semanas y mídela contra el volumen de iOS de tu MMP, no contra la esperanza.

Con esto se cierra la serie sobre seguimiento de apps: la arquitectura, los fallos silenciosos y el hueco de iOS. Si quieres revisar las tres cosas contra tu stack de una sola vez, eso es exactamente lo que cubre mi auditoría de seguimiento de apps.

Fuentes: Google Ads Help, set up gBraid conversion measurement for iOS; Google Ads Help, iOS 14 campaign measurement updates; diagnóstico y solución propios en una app de iOS en producción para un marketplace de reservas suizo (junio de 2026).