¿Por qué Google web a app no muestra conversiones en AppsFlyer?

Soy Samet Durgun, fractional Head of UA. Llevo el paid UA de apps de suscripción y juegos móviles, y aquí escribo lo que veo en las cuentas que manejo. Este artículo pertenece al tema Signal engineering; más sobre mí.

Cuando una campaña web de Google no muestra conversiones de app, comprueba cuatro pasos distintos en orden y párate en el primero que falle: el link de tracking encaja con la Final URL, el anuncio está aprobado, AppsFlyer atribuyó la instalación bajo el media source que estás leyendo y Google aceptó la subida de conversiones. Empieza por el tipo de campaña y la Final URL, porque el destino cambia la respuesta. Si tus anuncios envían a la gente directamente al App Store o a Google Play, la ruta que documenta AppsFlyer es su subida a la Offline Conversion API de Google, y Google dice que su propio Web to App Acquisition Measurement no está disponible para las cuentas cuyas campañas web envían a los usuarios a una tienda de apps.

Alcance: campañas web de Google Ads (cualquier objetivo excepto App promotion) que promocionan una app de iOS o Android, medidas con la integración Google Ads Web de AppsFlyer (googleads_int). Anoto también las diferencias de Singular y Adjust. Ninguna de las páginas de más abajo indica un límite regional. Contrastado con las páginas de cada proveedor el 1 de octubre de 2026. Para ver por qué podrías elegir esta ruta en lugar de las App Campaigns, mira ¿Funcionan los Google Search Ads para instalaciones de apps?. Este artículo trata solo de conseguir que mida.

¿Qué deberías comprobar primero?

El tipo de campaña y la Final URL, porque todas las demás reglas dependen de ellos. La guía de AppsFlyer, Google Ads (AdWords): Create web-based campaigns, se aplica a todos los objetivos de Google excepto App promotion y a todos los tipos de campaña excepto Shopping. Una App Campaign es una integración distinta, así que si eso es lo que llevas, este artículo no es el que necesitas.

Después lee la Final URL del anuncio. Es una ficha de store, tu propia página web o (por error) un link de AppsFlyer, y cada caso necesita un link de tracking distinto.

En la tabla, las reglas de links son de AppsFlyer y las de medición son de Google.

Final URL Tracking template (AppsFlyer) Qué falla De dónde vienen las conversiones de Google Cómo validar Límites conocidos
Ficha del App Store o de Google Play Link de atribución de una sola plataforma con af_r={lpurl} Un OneLink aquí devuelve el error “Tracking call unsuccessful” de Google La subida de AppsFlyer a la Offline Conversion API (OCI) de Google. El propio Web to App Acquisition Measurement de Google no está disponible para una cuenta con campañas web que envían a los usuarios a una store El botón Test de Google en el template, y después un click real que aparezca en AppsFlyer Los parámetros de AppsFlyer solo pueden ir en el template. La atribución view through de AppsFlyer para estas campañas necesita una landing page con Smart Script o Smart Banners, así que aquí no se aplica
Tu propia página web con Smart Script o Smart Banners Opcional. OneLink con af_android_url, af_ios_url y af_web_dp puestos todos en {lpurl}, o af_r={lpurl} Sin template: no se puede atribuir a quienes se saltan el botón de la página y van a la store por su cuenta. Con uno: quienes tocan el botón registran dos clicks La subida a OCI de AppsFlyer, y por separado el Web to App Acquisition Measurement de Google si importas first opens y ninguna campaña web de la cuenta envía a los usuarios a una store La URL de salida del botón lleva gclid, gbraid o wbraid Smart Script reenvía gclid automáticamente desde la versión 2.8.1, y gbraid y wbraid desde la 2.9.0. Smart Banners genera solo links OneLink. La propia página debe cumplir la política de destino de Google
Un link de AppsFlyer (OneLink o de una sola plataforma) No procede AppsFlyer avisa de que esto puede hacer que rechacen la campaña Ninguna hasta que se corrija la Final URL No procede La Final URL debe ser una dirección directa sin redirects

Mantén separadas las dos fuentes. La subida de AppsFlyer envía lo que AppsFlyer atribuyó, emparejado con los clicks de Google por click ID. El Web to App Acquisition Measurement de Google es Google contando las instalaciones por su cuenta a partir de first opens importados. En una cuenta cuyas campañas web van directas a la store, solo está disponible la primera.

¿Qué necesita el tracking template?

La guía de AppsFlyer enumera las partes, y basta con que una falte o esté mal para romper el link o el anuncio:

  • pid=googleads_int, obligatorio.
  • af_siteid, obligatorio, con el valor que elijas.
  • c, obligatorio y estático. AppsFlyer dice que no hay ningún parámetro ValueTrack para él, así que escribe el nombre a mano. Pon el ID de campaña en af_c_id={campaignid}, que AppsFlyer también necesita para los datos de costo, clicks e impresiones.
  • af_force_transparent=true, obligatorio. AppsFlyer dice que sin él Google puede no aprobar el anuncio.
  • Un redirect a {lpurl}. El valor de {lpurl} debe usar HTTPS, estar codificado y pertenecer a un dominio de tu allowlist de redirects.

AppsFlyer rechaza af_dp, af_android_store_csl, af_ios_store_cpp, af_og_title, af_og_description y af_og_image en este flujo, y prohíbe af_base_params_forward y af_param_forwarding porque alteran {lpurl}. Nada de parámetros duplicados, ni parámetros sin valor, ni parámetros ValueTrack que Google deje vacíos, y los valores definidos en Campaign URL options en Google Ads deben coincidir con el template.

En el lado de Google, About tracking in Google Ads dice que el template y todos los redirects deben ser HTTPS y hacerse en el servidor, y el botón Test comprueba que la Final URL más tu tracking se resuelve. About parallel tracking dice que el parallel tracking es obligatorio para Search, Shopping, Display, Video y Performance Max: el usuario va directo a la Final URL mientras el template carga en segundo plano. AppsFlyer vincula su regla del redirect a {lpurl} exactamente a eso.

¿Por qué un redirect que funciona no prueba que la configuración funcione?

Un click que aterriza en el sitio correcto solo ha pasado la primera de cuatro comprobaciones. Pruébalas por separado, con un click real en un teléfono, y anota la primera que falle.

  1. Validación del link. El botón Test de Google se resuelve, y el click de prueba aparece en AppsFlyer bajo la campaña que esperas. Un error “Tracking call unsuccessful” remite al tipo de link de la tabla.
  2. Aprobación del anuncio. La política Destination requirements de Google no aprueba un tracking template que no lleve al mismo contenido que la Final URL, ni los destinos “solely designed to send users elsewhere” (diseñados únicamente para enviar a los usuarios a otro sitio), lo que importa si tu landing page solo reenvía a la gente a la store. About ValueTrack parameters dice que los cambios en el template tardan de 24 a 48 horas en llegar a los anuncios que se están publicando, así que prueba después de ese plazo. About tracking in Google Ads dice que las opciones de URL definidas o editadas a nivel de anuncio, keyword o sitelink vuelven a pasar por revisión, mientras que las de nivel de cuenta, campaña o ad group no.
  3. Atribución del MMP. La instalación aparece en AppsFlyer. AppsFlyer la atribuye de forma probabilística, o determinista cuando hay un install referrer disponible.
  4. Aceptación de la subida. Google recibió la conversión, la emparejó con un click y la contó en la acción de conversión correcta.

Una prueba de redirect no dice nada de los pasos 3 y 4, que son de lo que trata un reporte de “sin conversiones”.

¿Dónde aparecen en AppsFlyer las instalaciones de Google web a app?

En su mayoría, no bajo el partner que configuraste. AppsFlyer envía las conversiones a Google bajo googleads_int, pero sus dashboards y datos en bruto las reportan bajo googleadwords_int, el media source de su integración principal de Google Ads, de modo que los resultados de las campañas web y de las App Campaigns quedan en una misma vista. El campo original_url de los datos en bruto y los reportes de postbacks conservan googleads_int. La tabla de características de la misma página añade que las instalaciones pueden aparecer bajo googleads_int y las reactivaciones bajo googleadwords_int cuando hay una integración SRN de googleadwords_int activa en paralelo. AppsFlyer dice también que Google puede reclamar por su cuenta algunas instalaciones de campañas web, como atribuciones googleadwords_int reportadas por el propio Google (self reported), y que esto “may become more common as Google expands support for web campaign install attribution” (puede volverse más común a medida que Google amplíe el soporte de la atribución de instalaciones de campañas web). Para iOS remite estas campañas al Classic Dashboard y dice que el SKAN Dashboard, en la mayoría de los casos, no es relevante para ellas.

Así que antes de concluir que no hay instalaciones, yo filtraría el dashboard por googleadwords_int y el ID de campaña, revisaría también googleads_int y después confirmaría en los datos en bruto que original_url contiene googleads_int.

¿Por qué AppsFlyer muestra la instalación pero Google no muestra nada?

Entonces la subida está fallando, o está llegando a donde no estás mirando. Los pasos de configuración y de resolución de problemas de AppsFlyer dan las comprobaciones:

  • Los eventos están mapeados. Las instalaciones son el único postback automático. Cualquier otro evento necesita una acción de conversión de Google creada como importación de clicks, con su valor ctid pegado en el mapeo de eventos de AppsFlyer. Una acción de conversión nueva aparece como Inactive hasta que llegan datos.
  • Count está en Every. AppsFlyer dice que la acción de conversión debe usar Every, no One, para aceptar subidas de gbraid y wbraid.
  • Los click ID sobreviven. Google añade gclid para Android y para los usuarios de iOS que dan su consentimiento, y gbraid y wbraid para los usuarios de iOS que no lo dieron. En una landing page, la URL de salida del botón debe llevar uno de ellos o el postback no puede registrarse. Para verlos en los datos en bruto, mapea además cada uno a su propio parámetro af_sub.
  • El token funciona. El scope de OAuth https://www.googleapis.com/auth/adwords, Sign in with Google hecho en AppsFlyer, y el ID de la cuenta de administrador (MCC) en los dos campos Customer ID cuando más de una cuenta de Google Ads lleva la app. Un error “Missing token” significa que este paso no está hecho.
  • Cuentas de agencia. Si una agencia lleva la campaña, deben estar activas las integraciones googleads_int tanto del anunciante como de la agencia, y la agencia debe hacer Sign in with Google, o el postback falla.
  • El plan. AppsFlyer dice que googleads_int está disponible solo en sus planes Growth y Enterprise, no en Zero ni Welcome.
  • Ajuste de privacidad de iOS. La configuración de AppsFlyer pide a las apps de iOS que desactiven Advanced Privacy para este partner. Su página Apply Aggregated Advanced Privacy framework dice que mientras esté activado el interruptor de Aggregated Advanced Privacy a nivel de app o el interruptor de Advanced Privacy de un partner, identificadores como los click ID, el IDFV, el user agent y la IP de los usuarios de iOS 14.5+ sin consentimiento de ATT no están disponibles para los partners, y que el interruptor del partner solo se puede cambiar una vez desactivado el de nivel de app. También pide a los anunciantes que trabajen con asesores legales sobre cómo define Apple el tracking antes de desactivar el ajuste a nivel de app. La página User Privacy and Data Use de Apple dice que “you may not derive data from a device for the purpose of uniquely identifying it” (no puedes derivar datos de un dispositivo para identificarlo de forma única). Esa decisión corresponde al dueño de la app y a su asesor legal de privacidad, y se toma antes de la prueba.

En Google Ads, abre la acción de conversión que aparece en el mapeo, porque la columna Conversions puede dejarla fuera. La página About primary and secondary conversion actions de Google dice que las acciones secundarias se reportan en All conversions y no se usan para la puja, salvo que estén en un objetivo personalizado.

La aceptación tampoco es el final. En una prueba de App Campaign de Google que corrí en febrero y marzo de 2026, medida en AppsFlyer, el evento de revenue enviaba $1 en lugar de $0 cuando no había valor. Google recibió esos valores, y su ROAS reportado estaba inflado en todos los casos, sobre todo en iOS, donde los volúmenes de conversión eran más bajos. Aquello era una App Campaign, no una campaña web, pero la lección vale igual: comprueba los valores que recibió Google además del recuento. Escribí el resto de esa prueba en qué estrategia de puja de Google Ads funciona mejor para apps.

¿En qué se diferencia la medición web a app propia de Google?

Es Google contando instalaciones sin la subida de tu MMP. La página About Web to App Acquisition Measurement de Google dice:

  • Cubre las campañas de Search, Performance Max, Shopping, Hotel, Video y Demand Gen, en Android e iOS, y no está disponible para cuentas con campañas web que envían a los usuarios a una tienda de apps.
  • Las instalaciones indirectas necesitan eventos first open de las dos plataformas importados en la cuenta que tiene las campañas web, y aparecen en All conv. La columna Web to app first conv. necesita además acciones in app importadas y que se puje por una de ellas como acción primaria.
  • Integrated Conversion Measurement se ha ampliado a la adquisición web a app mediante la medición en el dispositivo, lo que según Google mejora la atribución de las instalaciones de iOS del inventario de Search y Shopping de tus campañas web en los partners de atribución de terceros. El inventario de Video y Display se describe como algo que llegará más adelante.
  • Una conversión se atribuye a una sola campaña, sin doble reporting entre App Campaigns y campañas web, y Google dice que la misma lógica se extiende al reporting de los partners.

Google dice también que ha empezado a reclamar y reportar los first opens de la app generados por el inventario de Search y Shopping en las campañas de Search, Performance Max y Shopping. Según Google, ese cambio y la ampliación de ICM explican que las instalaciones atribuidas a campañas web puedan subir en tu partner de atribución sin que cambies nada en tus links. En AppsFlyer, las instalaciones que Google reclama llegan como atribuciones googleadwords_int reportadas por el propio Google, no a través de tu subida de googleads_int. Lo que ICM y la medición en el dispositivo necesitan dentro de la app, según el MMP, está en mi guía de configuración para App Campaigns de iOS.

¿Funciona igual en Singular o Adjust?

No, y las diferencias importan para iOS.

La guía Google Ads Web - Web to App Campaigns de Singular pone el link de Singular en el tracking template con la URL de la store como Final URL (o tu propio sitio con su Web SDK), exige _global_redirect={lpurl} en el link o el anuncio se rechaza, y dice que el deep linking debe estar desactivado. Su FAQ dice que la subida offline pasa gclid automáticamente y lista gbraid y wbraid como próximamente, y da como límites de la Offline Conversions API que solo admite conversiones de click, sin modelado. También exige tener activadas las enhanced conversions for leads en Google Ads. Su resumen de la integración marca view through y reactivación como no soportados. Así que, según la propia página de Singular, los clicks de iOS sin consentimiento, que llevan gbraid o wbraid en lugar de gclid, todavía no tienen un click ID que Singular pueda subir.

La página Extend your Google Ads setup beyond app campaigns de Adjust dice que Google Ads no acepta los universal links ni los branded links de Adjust como tracking template, que editar el link de Adjust puede hacer que lo rechacen, y que Google Ads podría no reclamar la atribución de ciertos usuarios en las campañas web a app.

¿Dónde encaja esto en mi trabajo?

Devolver a Google las conversiones de app de una campaña web es signal engineering: la puja solo puede optimizar sobre las conversiones que recibe. El orden sale de las reglas de arriba: fija la Final URL, ajusta a ella el tipo de link de tracking, pasa las cuatro comprobaciones y lee el rendimiento solo después de que la subida sea aceptada. Si sospechas que la medición es lo que frena la cuenta, puedes reservar el growth audit por separado para comprobarlo. Para ver cómo se compara esta ruta con las App Campaigns, mira por qué una App Campaign de Google gasta en YouTube. El mismo trazado para Meta está en por qué Meta web a app muestra clicks pero no instalaciones en AppsFlyer.

Fuentes

Todas verificadas el 1 de octubre de 2026.

Preguntas frecuentes

¿Puedo usar un OneLink como tracking template cuando la Final URL es el App Store?

No. La guía de AppsFlyer para campañas web de Google dice que cuando la Final URL apunta directamente a Google Play o al App Store, el tracking template debe ser un link de atribución de una sola plataforma, y que un OneLink en ese lugar devuelve un error "Tracking call unsuccessful" de Google. OneLink va en el template cuando la Final URL es tu propia página web.

¿Funciona Web to App Acquisition Measurement de Google si mis anuncios envían a la gente directamente al App Store?

No. La página de ayuda de Google dice que la función no está disponible para cuentas con campañas web que dirigen a los usuarios a una tienda de apps como el Apple App Store o Google Play. En una cuenta así, la ruta que AppsFlyer documenta para una Final URL de store es su subida a la Offline Conversion API de Google. Verificado el 1 de octubre de 2026.

¿Por qué mis instalaciones web de Google aparecen bajo googleadwords_int en lugar de googleads_int?

Porque AppsFlyer las reporta así. Las conversiones se envían a Google bajo googleads_int, pero los dashboards y los datos en bruto de AppsFlyer las muestran bajo googleadwords_int. El campo original_url conserva googleads_int, y los reportes de postbacks también. La tabla de características de AppsFlyer añade que las instalaciones pueden aparecer bajo googleads_int y las reactivaciones bajo googleadwords_int cuando también está activa una integración SRN de googleadwords_int, así que revisa los dos antes de concluir que no se atribuyó nada.

¿Tengo que desactivar Advanced Privacy en AppsFlyer para web a app en iOS?

Los pasos de configuración de AppsFlyer dicen que lo desactives para una integración de iOS. Su página de Aggregated Advanced Privacy dice que mientras ese ajuste está activado, identificadores como los click ID, el IDFV, el user agent y la IP de los usuarios de iOS 14.5+ sin consentimiento de ATT no están disponibles para los partners, y pide a los anunciantes que trabajen con asesores legales sobre cómo define Apple el tracking antes de desactivar el ajuste a nivel de app. Cambiarlo lo deciden el dueño de la app y su asesor legal, antes de empezar a depurar.