¿Por qué Meta web a app da clicks sin instalaciones 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 Meta muestra clicks en el link y AppsFlyer no muestra instalaciones, o las instalaciones están ahí bajo otra etiqueta, o el registro se rompió en alguna etapa entre el anuncio y la app. AppsFlyer reporta las instalaciones de Meta web a app bajo Facebook Ads, no bajo metaweb_int, así que la primera comprobación es si estás leyendo la etiqueta correcta. La segunda es trazar un solo click de prueba por todas las etapas hasta que falte un registro. En iOS, un ajuste cambia lo que recibe Meta mientras los reportes agregados de AppsFlyer siguen igual: con Advanced Privacy de AppsFlyer activado, los postbacks de los usuarios que no han concedido el permiso ATT no llevan click ID ni identificadores del dispositivo. Un móvil de prueba que concedió el permiso puede pasar la prueba mientras a los postbacks de todos los demás les falta el click ID que Meta usa para identificar el click.

Alcance: anuncios de Meta con la conversion location Website, medidos con la integración Meta Web de AppsFlyer (metaweb_int), para una app instalada desde el App Store o Google Play, con los eventos de trial y compra enviados por el SDK de AppsFlyer o por RevenueCat. Contrasté cada afirmación sobre una plataforma con la página del propio proveedor el 1 de octubre de 2026. Las campañas web que convierten en el propio sitio web usan otra guía de AppsFlyer y quedan fuera de este artículo. También quedan fuera las campañas de app promotion de Meta: un evento que llega a Meta ahí y aun así no se puede usar para optimizar se trata en ¿Por qué mi trial y mi compra no son elegibles para Meta AEM?

¿Qué puede significar “clicks pero no instalaciones”?

Una de tres cosas, y cada una necesita una solución distinta.

  1. Una diferencia de etiquetado. La guía de AppsFlyer Meta Ads: Create web-based campaigns (editada el 15 de septiembre de 2026) dice que las instalaciones de web a app se reportan “under the Facebook Ads PID” (bajo el PID de Facebook Ads) en los dashboards y en los datos en bruto. En los datos en bruto, el campo original_url conserva pid=metaweb_int, y los reportes de postbacks muestran metaweb_int como el media source al que se envió el postback.
  2. Dos clicks distintos. Meta cuenta el click en el anuncio. En el flujo con landing page de AppsFlyer, el click de AppsFlyer se registra cuando el usuario toca la llamada a la acción de tu página. Los visitantes que se van sin tocarla son una simple impresión, y esa impresión solo cuenta para una instalación si activas la atribución view through de AppsFlyer (lookback de hasta 24 horas).
  3. Un fallo real. El click ID nunca llegó al link de la store, la instalación no se pudo emparejar, o el evento posterior nunca llegó a Meta.

La prueba de abajo las distingue.

¿Cómo trazas un click de prueba por todas las etapas?

Compruebo una ruta de principio a fin antes de leer cifras agregadas.

Prepara la prueba para que un registro que falta solo pueda significar un problema de configuración:

  • Registra el móvil como dispositivo de prueba. La página de AppsFlyer Registering test devices (editada el 28 de agosto de 2026) dice que la ventana de reatribución limita las atribuciones de instalación a una cada 90 días, así que las instalaciones de prueba repetidas en el mismo móvil no registran nada si no está registrado. Para un iPhone que va a permitir el tracking, el método de AppsFlyer es registrarlo por IDFA.
  • Concede el permiso ATT en el móvil de prueba. Usa el móvil de alguien del equipo, toca Allow en el aviso de ATT de tu app y acepta tu banner de consentimiento si la landing page muestra uno. Según Apply Aggregated Advanced Privacy framework de AppsFlyer (editado el 11 de junio de 2026), el tráfico web hacia una app cuyo usuario autorizó ATT da acceso a datos de atribución a nivel de usuario, tanto a ti como a la red publicitaria, así que Advanced Privacy no limita lo que muestra esta prueba.
  • Haz click en el anuncio como lo haría un usuario. En el móvil, dentro de Facebook o Instagram, no desde una vista previa de escritorio. Si la página se abre en Safari, no uses Private Browsing: el boletín sobre Link tracking Privacy (LTP) de AppsFlyer, de 2023, dice que iOS 17 elimina fbclid en ese modo.
  • Anota la hora de cada paso, para poder encontrar las filas después.

Después recorre las etapas en orden y detente en la primera que falle.

Etapa Qué debería existir Dónde mirar Si falta Qué abrir después Resultado observado
1. Destino del anuncio La URL de la landing page, o el link de atribución, con pid=metaweb_int, c, af_c_id y los demás parámetros mapeados Vista previa del anuncio en Ads Manager, y luego la URL que el móvil abre de verdad Los parámetros de URL no están configurados en el anuncio La etapa 2 cuando la URL esté bien URL tal como se abrió, hora
2. Click de tracking fbclid en la URL de la landing page y el mismo fbclid en el link de salida hacia la store La URL de la landing page y el link de la llamada a la acción en el móvil; los datos en bruto de clicks solo existen en Data Locker El script no está reenviando los parámetros, o el usuario nunca tocó la llamada a la acción Versión de Smart Script y mapeo de parámetros fbclid visto en ambos links, sí o no
3. Primer arranque Una instalación del dispositivo de prueba Datos en bruto de AppsFlyer, instalaciones, filtradas por hora de instalación El SDK no arrancó, o el dispositivo no estaba registrado y la instalación contó como reinstalación Integración del SDK y lista de dispositivos de prueba Fila encontrada, hora
4. Instalación atribuida Esa instalación con media source Facebook Ads y metaweb_int en original_url La misma fila de datos en bruto La instalación se registró como orgánica: el click no se pudo emparejar con la instalación La etapa 2 otra vez, y luego los ajustes de privacidad Media source, original_url
5. Trial El evento de trial en el mismo usuario Datos en bruto de eventos in app de AppsFlyer; el historial del cliente en RevenueCat si es quien envía el evento El evento nunca se envió, o RevenueCat no lo envió porque el atributo $appsflyerId no estaba fijado Mapeo de eventos, atributos de cliente de RevenueCat Nombre del evento, hora
6. Transacción de pago El evento de compra con revenue y moneda Los mismos reportes; para las compras de sandbox, RevenueCat necesita una clave de AppsFlyer en su campo Sandbox developer key El revenue no se envió, o se envía dos veces Quién se encarga del revenue (ver más abajo) Revenue, moneda, recuento
7. Entrega de eventos al partner Postbacks a metaweb_int para la instalación y los eventos mapeados, y los eventos en Meta Reporte de postbacks de AppsFlyer con metaweb_int añadido a mano; Events Manager para el mismo pixel Postback sin mapear, compra no configurada para incluir el revenue, o pixel equivocado Página de la integración Meta Web en AppsFlyer Estado del postback, evento en Events Manager

La página Raw data reporting overview de AppsFlyer (editada el 11 de agosto de 2026) lista los datos en bruto de clicks como un reporte exclusivo de Data Locker, así que sin Data Locker compruebas la etapa 2 en los propios links. La Raw data export page de AppsFlyer (editada el 13 de agosto de 2026) dice que los PID web como metaweb_int no aparecen en el desplegable de media source; para ver los postbacks web añades el PID manualmente. La página de la integración con AppsFlyer de RevenueCat señala que la vista Events de AppsFlyer muestra los eventos in app por la fecha de instalación del usuario, así que una compra hecha hoy por un usuario que instaló la semana pasada queda en el rango de la semana pasada.

La guía de AppsFlyer nombra las opciones por destino:

  • Landing page: una página con OneLink Smart Script o un Smart Banner. AppsFlyer lo recomienda cuando la app está en varias plataformas, o cuando quieres que la página explique el producto o recoja datos. El Smart Banner solo construye links de OneLink; Smart Script también puede construir links de una sola plataforma para otras stores.
  • Directo a la store: un link de atribución de AppsFlyer, OneLink, de una sola plataforma o multiplataforma. AppsFlyer añade un aviso: “Sometimes, the use of AF attribution links may lead to errors” (a veces, el uso de links de atribución de AF puede dar lugar a errores). La solución que sugiere es preguntar a Meta o usar una landing page en su lugar.

En Ads Manager, la campaña usa la conversion location Website con el mismo pixel ID que introdujiste en AppsFlyer. En la sección Tracking, AppsFlyer dice que no elijas App Events, “otherwise Meta will claim those conversions using the SRN API” (de lo contrario Meta reclamará esas conversiones usando la API de SRN). Si AppsFlyer no muestra ningún click, impresión ni costo de la campaña web, su guía dice que el link necesita af_c_id y que la cuenta publicitaria debe estar conectada en la integración de Facebook Ads.

¿Qué tiene que pasar con fbclid?

Meta lo añade y AppsFlyer lo transporta. La página para desarrolladores de Meta ClickID and the fbp and fbc Parameters describe el click ID como un parámetro generado por Meta que se pasa con la URL cuando alguien hace click en un anuncio, y avisa de que el valor distingue entre mayúsculas y minúsculas. AppsFlyer dice que Meta añade fbclid a la URL de destino automáticamente.

En una landing page, la página Set up Smart Script to convert web visitors de AppsFlyer (editada el 2 de septiembre de 2026) dice que Smart Script reenvía fbclid a la URL de salida por sí solo desde la versión 2.8.1. Para la versión 2.8.0 e inferiores, la guía de Meta web dice que lo mapees a mano. Para ver el valor en los datos en bruto, mapéalo también a uno de los parámetros entre af_sub1 y af_sub5. La guía de Meta web califica fbclid de esencial para enviar postbacks de eventos in app a Meta, y por eso la etapa 2 de la tabla comprueba el valor en ambos links.

¿Por qué las instalaciones aparecen bajo Facebook Ads y no bajo metaweb_int?

Por diseño. La guía de Meta web dice que los eventos van a Meta bajo metaweb_int pero aparecen bajo Facebook Ads en los dashboards Overview y Activity y en el campo media_source de los datos en bruto y de los reportes de API. Para separar las campañas web de las de app, AppsFlyer sugiere un prefijo o sufijo web en el nombre de la campaña; para confirmar una instalación, lee su original_url.

¿Qué cambia el paso de Advanced Privacy y quién lo decide?

La guía de Meta web de AppsFlyer incluye, como paso de configuración, “Turn off Advanced Privacy (if you are setting an iOS app integration).” (desactiva Advanced Privacy si estás configurando una integración de app de iOS). Su artículo sobre Aggregated Advanced Privacy explica qué hace el ajuste. Con él activado, los partners reciben solo detalles agregados de campaña de los usuarios de iOS 14.5 y posteriores que no han concedido el permiso ATT. Los datos a nivel de usuario que no reciben incluyen el AppsFlyer ID, el customer user ID, el click ID, el IDFA, el IDFV, el user agent y la dirección IP. La guía de Meta web dice que Meta usa fbclid para identificar el click concreto, así que un postback sin él pierde ese vínculo. El artículo sobre Aggregated Advanced Privacy dice también que una red publicitaria sin integración de Advanced Privacy no recibe ningún postback de los usuarios que no dieron su consentimiento, y que el interruptor de un partner solo se puede desactivar una vez que el interruptor de Aggregated Advanced Privacy a nivel de app está desactivado.

No lo trato como un interruptor que se cambia mientras depuras. La propia AppsFlyer dice que trabajes con tus asesores legales y otros profesionales sobre cómo define Apple el tracking antes de desactivar el framework. La página de Apple User Privacy and Data Use dice que necesitas el permiso ATT para hacer tracking, y 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), sean cuales sean tus ajustes. AppsFlyer añade que incluso con el framework desactivado, los datos a nivel de usuario no se pueden usar para identificar un dispositivo de forma única. El dueño de la app decide con su asesor legal de privacidad, y el plan de medición sigue esa decisión. El móvil de prueba de arriba, con el permiso ATT concedido, te deja comprobar la configuración sin tocar el ajuste.

¿Están los postbacks a Meta configurados como documenta AppsFlyer?

El postback de instalación es automático; todo lo demás se mapea a mano. Según la guía de Meta web de AppsFlyer:

  • La integración necesita el pixel ID y un access token, y el interruptor del partner debe seguir activado.
  • Las instalaciones son el único postback automático por defecto. El trial y la compra necesitan un mapeo a un evento de Meta o a CUSTOM.
  • Un postback de compra debe incluir “Values and revenue”. Cualquier otra opción hace que el postback falle.
  • “This partner only” envía los eventos atribuidos a Meta; “All media sources, including organic” envía también los eventos atribuidos a otros partners y a orgánico. Es un ajuste de postback: cambia lo que recibe Meta, no si AppsFlyer atribuye una instalación a Meta.
  • Los eventos enviados de servidor a servidor a metaweb_int deben llevar ua e ip. El SDK los añade; tu servidor tiene que hacerlo.
  • Los postbacks de lo que AppsFlyer llama “re-engagement” no se admiten en esta integración.

Del lado de Meta, la página para desarrolladores Using the API dice que los eventos se pueden verificar en Events Manager 20 minutos después de enviarlos, donde la fuente de datos muestra los eventos en bruto, emparejados y atribuidos.

¿Puede SKAdNetwork ver estas instalaciones?

No para un anuncio en el que se hizo click dentro de la app de Facebook o Instagram. La página de Apple Signing and providing ads lista los anuncios web atribuibles, “where the ad network presents an ad on a Safari web page” (donde la red publicitaria presenta un anuncio en una página web de Safari), desde SKAdNetwork 4. La página de Google Understanding iOS App campaign measurement and reporting describe la observabilidad de web a app “only on Safari browsers” (solo en navegadores Safari) y dice que Chrome y Firefox no son compatibles con SKAdNetwork. Un anuncio en la app de Facebook o Instagram no está en una página web de Safari, y la guía de Meta web de AppsFlyer no menciona SKAdNetwork. No esperes que SKAN explique aquí una instalación que falta.

¿Y si RevenueCat envía el trial y la compra?

Entonces solo un sistema debería enviar el revenue a AppsFlyer. La página de RevenueCat sobre AppsFlyer dice “remove all client-side tracking of revenue” (elimina todo el seguimiento de revenue del lado del cliente), porque registrar también las compras con el SDK de AppsFlyer “can lead to double counting of revenue” (puede llevar a contar el revenue dos veces). También lista el atributo $appsflyerId como requerido, dice que RevenueCat solo envía eventos a AppsFlyer cuando los atributos requeridos están fijados, y avisa de que sin el AppsFlyer ID algunos eventos pueden no entregarse, lo que se ve como si faltara la etapa 5 o la 6.

Para las compras hechas en la web a través de Stripe, Paddle o RevenueCat Billing, el ajuste de enrutamiento de eventos de tiendas web de RevenueCat envía cada compra a una sola API de AppsFlyer, Mobile S2S por defecto o Web S2S, y la página dice “a purchase is never sent through both APIs” (una compra nunca se envía por ambas API). Si una compra web sigue apareciendo dos veces, busca un seguimiento de compras que siga activo en la app u otro sistema que envíe compras fuera de RevenueCat. La página dice también que AppsFlyer planea retirar People-Based Attribution para finales de 2026, lo cual es un plan declarado, no un cambio que haya ocurrido. Cómo comparo Meta, RevenueCat y un MMP cuando sus números no coinciden está en Meta contra RevenueCat contra Adjust: ¿en qué número confías?

¿Qué no deberías concluir de una sola prueba?

Una prueba superada demuestra que la ruta funciona para un usuario que concedió el permiso ATT en un móvil, no la tasa de match del resto. Una prueba que falla no muestra qué ajuste tiene la culpa hasta que cambias una cosa y la repites. Ninguna página de proveedor que revisé documenta un único ajuste como la solución para las instalaciones de web a app que faltan, y varios cambios a la vez ocultan cuál importó. Anota cada vez la etapa, el cambio y el nuevo resultado observado.

¿Dónde encaja esto en mi trabajo?

Este trazado forma parte del signal engineering: asegurarse de que el evento para el que optimiza la plataforma de ads es el que cuenta el negocio, y de que llega. Si no tienes claro que la medición sea el motivo de que una campaña web de Meta se vea floja, el growth audit lo comprueba, y se puede reservar por separado. La parte de Google de web a app, donde los click ID y las subidas de conversiones funcionan de otra forma, está en ¿Por qué Google web a app no muestra conversiones en AppsFlyer? Por qué un equipo enviaría tráfico de Google Search a una app de esta forma está en ¿Funcionan los Google Search Ads para instalaciones de apps?

Fuentes

Todas verificadas el 1 de octubre de 2026.

Preguntas frecuentes

¿Por qué mis instalaciones de Meta web a app no aparecen bajo metaweb_int en AppsFlyer?

Porque AppsFlyer las reporta bajo Facebook Ads. Su guía de campañas web de Meta dice que las atribuciones de web a app aparecen bajo Facebook Ads en los dashboards Overview y Activity y en el campo media_source de los datos en bruto, mientras que el campo original_url conserva pid=metaweb_int y los reportes de postbacks muestran metaweb_int. Un dashboard filtrado por metaweb_int puede parecer vacío mientras las instalaciones están ahí.

¿Un anuncio de Meta web a app debería ir a una landing page o directo al App Store?

AppsFlyer admite ambas opciones. Recomienda una landing page con Smart Script o Smart Banner cuando la app está en varias plataformas o quieres que la página explique el producto o recoja datos, y links de atribución OneLink, de una sola plataforma o multiplataforma para enviar a los usuarios directo a la store. También avisa de que los links de atribución pueden dar lugar a errores y nombra una landing page como alternativa.

¿Tengo que desactivar Advanced Privacy para las campañas web de Meta en iOS?

El paso de configuración de AppsFlyer dice que lo desactives para una integración de app de iOS. Con él activado, AppsFlyer no entrega a los partners datos a nivel de usuario como el click ID, el IDFV, el user agent y la dirección IP de los usuarios de iOS 14.5 y posteriores que no han concedido el permiso ATT. Decidir si se cambia es una cuestión de privacidad y legal del dueño de la app, no un paso de depuración, y Apple prohíbe derivar datos del dispositivo para identificarlo de todos modos.

¿Puede SKAdNetwork medir las instalaciones de los anuncios web de Meta?

Solo en un caso limitado. Apple documenta los anuncios web atribuibles para los anuncios que una red publicitaria firma y muestra en una página web de Safari, desde SKAdNetwork 4. La página de medición de iOS de Google dice que Chrome y Firefox no son compatibles con SKAdNetwork. La guía de Meta web de AppsFlyer no menciona SKAdNetwork, así que no esperes que cubra lo que falta.

¿Por qué una compra de web a app aparece dos veces en el revenue de AppsFlyer?

Comprueba si hay un segundo sistema que envíe la compra. RevenueCat te dice que elimines todo el seguimiento de revenue del lado del cliente cuando su integración con AppsFlyer está activada, porque registrar también las compras con el SDK de AppsFlyer puede contar el revenue dos veces. Para las compras de tiendas web dice que una compra nunca se envía por sus dos API de AppsFlyer, así que busca un seguimiento de compras que siga activo en la app o algún otro sistema fuera de RevenueCat que también las envíe.