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) |
|
Fuente multicanal atribución |
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. | |
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.
Recomendamos configurar las ventanas de atribución en AppsFlyer según valores de Anuncios de Meta como se muestra en la siguiente pantalla: Consulta la documentación de Meta for Developers sobre cómo comparar la configuración de atribución.
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.
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 |
|---|---|---|
| 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. |
| Atribución de fuente multicanal | El recuento de un evento in-app específico (por ejemplo, un evento de compra) en el dashboard de Facebook (FB) difiere de su recuento correspondiente en el dashboard de AppsFlyer (AF). | El dashboard de Facebook (FB) se basa en la actividad, mientras que los dashboards Overview y Event de AppsFlyer (AF) se basan en el LTV. Para comparar recuentos de eventos, usa un dashboard de AF basado en la actividad. Para más información, consulta LTV frente a actividad |
¿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.
Discrepancias del modelado probabilístico de Meta (AEM) en aplicaciones iOS
Cuando la medición de eventos agregados (AEM) está habilitada para aplicaciones iOS, Meta puede atribuir instalaciones o eventos in-app mediante su modelado probabilístico. Meta puede aplicar distintos métodos de modelado en sus informes internos en comparación con lo que comparte con AppsFlyer. Debido a estas diferencias en los métodos de modelado, los recuentos de instalaciones que se muestran en Meta Ads Manager y AppsFlyer pueden variar; a veces son más altos y otras, más bajos. En concreto:
- Meta puede registrar conversiones internamente, pero optar por no enviar a AppsFlyer las reclamaciones de AEM correspondientes.
- Meta puede enviar a AppsFlyer una reclamación de AEM por una conversión modelada que no aparece en Ads Manager.
This article was translated automatically and may contain errors. The English version is the most accurate - use the language selector below to switch.