De un vistazo: Conoce las diferencias en los modelos de atribución entre Anuncios de Meta y AppsFlyer.
Discrepancias de Anuncios de Meta con AppsFlyer
Como dos de los principales actores del ecosistema de adquisición de usuarios móviles, AppsFlyer y Anuncios de Meta cuentan con modelos de atribución diferentes. Esto puede hacer que surjan discrepancias entre los paneles de control de Anuncios de Meta y de AppsFlyer.
Si bien trabajamos en estrecha colaboración con Anuncios de Meta para minimizar estas discrepancias, los anunciantes deben ser conscientes de los factores que suelen originarlas.
Detectar una discrepancia entre AppsFlyer y Anuncios de Meta
Compara los eventos listados en el Administrador de eventos de Anuncios de Meta con los de los reportes de AppsFlyer. Si el número de eventos varía significativamente, puede haber una discrepancia.
Diferencias en los modelos de atribución
| Causa | Meta ads | AppsFlyer |
|---|---|---|
|
Ventana retrospectiva de atribución por clics |
7 días (Ten en cuenta que hay algunos casos específicos en los que el valor predeterminado es diferente). |
1-30 días. Asegúrate de configurarlo en 7 días con Anuncios de Meta. |
|
Ventana retrospectiva de atribución por impresiones |
1 día (Ten en cuenta que hay algunos casos específicos en los que el valor predeterminado es diferente). |
1 día por defecto, pero puede configurarse en intervalos de entre 1 hora y 48 horas (mantener este valor por defecto) |
|
Atribución de fuente multicanal |
Anuncios de Meta se autoatribuye instalaciones a pesar de ser de fuentes de otros medios. |
AppsFlyer usa la atribución al último clic (puedes encontrar más información sobre la atribución de AppsFlyer aquí). |
|
Atribución de dispositivos cruzados |
Anuncios de Meta atribuye sus usuarios que hacen clic e instalan en distintos dispositivos; por ejemplo, iOS/Android/escritorio. |
AppsFlyer atribuye por tipo de dispositivo, aquellos en los que tenga lugar tanto el engagement como la instalación |
|
Distintas zonas horarias |
La zona horaria predeterminada de los reportes de Anuncios de Meta es PST. Asegúrate de cambiarla en el Administrador de anuncios de Meta para que coincida con la zona horaria de la aplicación definida en la configuración de la aplicación en AppsFlyer. |
La zona horaria predeterminada de la aplicación de AppsFlyer es UTC+0. Puedes cambiar la zona horaria establecida para la aplicación en la página de configuración de la aplicación, para que coincida con la zona horaria definida en el Administrador de anuncios de Meta. |
|
Referente de instalación de Google |
Cuando una instalación sin ID de anunciante se atribuyó a Anuncios de Meta mediante el referente de instalación de Google Play, AppsFlyer no lo comunica a Anuncios de Meta. Esto causará una discrepancia, ya que se mostrará en AppsFlyer y no en Anuncios de Meta. |
|
|
AEM para compartir datos |
Para compartir datos de AEM, Anuncios de Meta recibe todos los eventos de conversión. Esta atribución agregada no se muestra en AppsFlyer. Por lo tanto, hay un aumento en la discrepancia de datos entre ambas plataformas para las instalaciones (en la mayoría de los casos) y los eventos in-app, incluidas las sesiones. |
|
Atribución por clics y por impresiones
AppsFlyer admite tanto atribuciones por clics como por impresiones. Para minimizar las discrepancias entre Anuncios de Meta y AppsFlyer, asegúrate de que tanto la ventana retrospectiva por impresiones como la ventana retrospectiva por clics sean coherentes con las predeterminadas definidas por Anuncios de Meta.
La ventana retrospectiva por clics predeterminada de Anuncios de Meta está configurada en 7 días. Aunque hay algunos casos específicos en los que el valor predeterminado es diferente, se recomienda configurar la ventana retrospectiva por clics en AppsFlyer en 7 días para cubrir todas las opciones predeterminadas de Anuncios de Meta.
Para comparar las ventanas de atribución por clics e impresiones en Anuncios de Meta con las de AppsFlyer, visita Anuncios de Meta. Recomendamos configurar las ventanas de atribución en AppsFlyer según valores de Anuncios de Meta como se muestra en la siguiente pantalla:
Ejemplo
Supongamos que la ventana retrospectiva por clics de Anuncios de Meta se configura en AppsFlyer en 1 día para tu aplicación com.greatapp, mientras que en Anuncios de Meta mantiene el valor predeterminado de 7 días. Los usuarios que hacen clic en el anuncio de greatapp en Facebook, pero inician la aplicación por primera vez después de 2-7 días se atribuyen como usuarios orgánicos en AppsFlyer, a la vez que Anuncios de Meta autorreporta estos usuarios.
Discrepancias restringidas de medios
Hasta el 28 de octubre de 2021, los datos de atribución de los usuarios generados mediante atribución por impresiones (VTA) estaban restringidos y no están disponibles para los anunciantes.
A partir del 29 de octubre de 2021, las restricciones se aplican a los usuarios traídos por la atribución tanto por impresiones como por clics. Los reportes agregados no se vieron afectados por esto.
Dado que Anuncios de Meta no envía datos a nivel de usuario, es posible que AppsFlyer no atribuya las impresiones y los clics de asistencia a la conversión a Anuncios de Meta.
Ejemplo
- Un usuario ve o hace clic en un anuncio de AwesomeApp en Facebook. Más tarde, ve y hace clic en un anuncio de AwesomeApp en GreatAdNetwork y la instala.
- Anuncios de Meta reclama la conversión ya que ocurrió dentro de su ventana retrospectiva.
- AppsFlyer atribuye la conversión a GreatAdNetwork, ya que tuvieron la última acción antes de la instalación.
- AppsFlyer no considerará Anuncios de Meta como una red de asistencia a la conversión, ya que el raw data de Anuncios de Meta está restringido.
Sin embargo, para la atribución por clics, si el anuncio dirige a los usuarios a la Google Play Store, los campos de atribución están disponibles para los anunciantes en el referente de instalación de Google. Los campos proporcionados a través del referente completan los reportes de raw data de AppsFlyer disponibles para ti y permiten que AppsFlyer atribuya a los usuarios que no tienen un ID de publicidad (habilitado para LAT).
Diferencias de eventos in-app
Las diferencias entre plataformas también pueden estar presentes con eventos posteriores a la instalación (por ejemplo, compras in-app), que se muestran en Anuncios de Meta y en AppsFlyer. La siguiente tabla describe los motivos más frecuentes de estas diferencias y brinda consejos sobre cómo minimizarlos:
| Causa | Descripción | Consejo de AppsFlyer |
|---|---|---|
|
Autoatribución |
Anuncios de Meta siempre atribuye los eventos a sus propias campañas que los impulsaron, mientras que AppsFlyer atribuye estos eventos a la fuente de adquisición. |
Las instalaciones y eventos que Anuncios de Meta se autoatribuye incorrectamente se indican como asistencias en AppsFlyer. |
| Definición de tiempo de vida diferente | El ciclo de vida de un usuario en Anuncios de Meta se define como de hasta 7 días, lo que significa que Anuncios de Meta no muestra los eventos si ocurrieron más de 7 días después del clic en el anuncio. En AppsFlyer, la vida de un usuario de Anuncios de Meta se define como un máximo de 180 días. |
Cuando evalúes el valor de los usuarios de las campañas de Anuncios de Meta que ocurrieron después de 7 días, usa los datos de AppsFlyer para obtener una visión más amplia. |
| Eventos no asignados | AppsFlyer obtiene eventos originados en el SDK, pero no están asignados a Anuncios de Meta y, por lo tanto, no son enviados. | Asegúrate de asignar con Anuncios de Meta todos los eventos in-app que indican la calidad de los usuarios. |
| Ingresos no enviados | AppsFlyer recibe los ingresos de eventos originados en el SDK, pero estos no se envían a Anuncios de Meta. | Asegúrate de que las casillas Enviar ingresos de los eventos in-app estén siempre marcadas; por ejemplo, el evento de compra en la siguiente captura. |
| Faltan los valores de eventos en Anuncios de Meta | AppsFlyer envía parámetros y valores a Anuncios de Meta como parte de la asignación de eventos, si tienen las estructuras correctas. | Crea tus eventos in-app de SDK según las estructuras recomendadas por AppsFlyer para asignar completamente los valores de eventos con Anuncios de Meta. |
¿Instalaciones de campañas de re-engagement en mi panel de control de UA?
Una campaña de re-engagement puede hacer que los usuarios abran una aplicación ya instalada (re-engagement). Además, cuando AppsFlyer reconoce que ya hay una instalación anterior de la aplicación en el mismo dispositivo, AppsFlyer puede tomar esta conversión como una reatribución.
Si, en una campaña de re-engagement, Anuncios de Meta se dirige a nuevos usuarios o a usuarios que han instalado la aplicación por primera vez después de un período superior al de la ventana de reatribución establecida, luego de la instalación original, los usuarios en cuestión se registran como nuevas instalaciones de adquisición de usuarios en AppsFlyer, que corresponden a campañas de re-engagement en Anuncios de Meta.
Por otro lado, las instalaciones que tienen lugar dentro de la ventana de reatribución establecida, después de la instalación original, se consideran reatribuciones y aparecen en la página de retargeting de AppsFlyer, mientras que pueden aparecer como nuevas instalaciones en Anuncios de Meta.
Nota
Si bien Anuncios de Meta muestra todas las instalaciones de una campaña de retargeting en el mismo lugar, en el panel de control de AppsFlyer, las instalaciones se dividen entre la página de información general (nuevas instalaciones) y la página de retargeting (reatribución y re-engagements).
Atribución de dispositivos cruzados
Anuncios de Meta informa sobre la atribución de dispositivos cruzados. A veces esto puede causar problemas cuando una campaña para una plataforma (iOS/Android) muestra instalaciones en otra plataforma.
Ejemplo
Linda hace clic en un anuncio móvil de GreatApp en Facebook desde su teléfono Android. Anuncios de Meta registra el clic de Linda bajo la campaña dirigida original de Android "Mujeres con Android". Linda decide instalar GreatApp en el iPad de su casa. En el primer inicio, AppsFlyer solicita a Anuncios de Meta el origen de esta instalación de iOS y Anuncios de Meta responde con la campaña "Mujeres con Android".
Protect360 y reglas de validación
Si utilizas las reglas de validación de AppsFlyer, los resultados pueden diferir entre AppsFlyer y Anuncios de Meta cuando hay instalaciones rechazadas que originalmente provienen de Anuncios de Meta. En estos casos, Anuncios de Meta se autorreporta instalaciones, mientras que AppsFlyer rechaza esas mismas instalaciones.
Asimismo, si se utiliza la solución antifraude de AppsFlyer, Protect360, puede haber instalaciones dado que Anuncios de Meta autorreporta, mientras que AppsFlyer rechaza.
Ejemplo
Jeff, gerente de UA de GreatApp, crea una campaña llamada SPNA dirigida exclusivamente a personas de habla hispana de América del Norte. Para verificar esto, Jeff define una regla de validación, que acepta solo usuarios de Canadá y los Estados Unidos.
Cuando un usuario de Anuncios de Meta de España hace clic e instala la aplicación, Anuncios de Meta se autorreporta la instalación, mientras que AppsFlyer rechaza la instalación que no pasa la regla de validación.
Discrepancias relacionadas con el SDK
Podría haber varias ocasiones en las que los anunciantes implementen tanto el SDK de AppsFlyer como el de Facebook. Esto podría causar discrepancias para los eventos in-app. Anuncios de Meta no desduplica los eventos in-app que se reportan desde ambos SDK. Esto significa que Anuncios de Meta puede reportar falsamente los ingresos y otros eventos.
- Usa cualquiera de los métodos siguientes para evitar reportes de eventos in-app duplicados en Anuncios de Meta:
- No configures eventos en el SDK de Facebook.
- Deshabilita la asignación de eventos in-app de Anuncios de Meta desde AppsFlyer.