Discrepancias en los anuncios de Facebook

De un vistazo: Conoce las diferencias en los modelos de atribución entre Anuncios de Facebook y AppsFlyer.

Discrepancias de Anuncios de Facebook con AppsFlyer

Como dos de los principales actores del ecosistema de adquisición de usuarios móviles, AppsFlyer y Facebook cuentan con modelos de atribución diferentes. Esto puede hacer que surjan discrepancias entre los paneles de control de Facebook y de AppsFlyer.

Si bien trabajamos en estrecha colaboración con Facebook para minimizar estas discrepancias, los anunciantes deben ser conscientes de los factores que suelen originarlas.

Detectar una discrepancia entre AppsFlyer y Facebook

Compara los eventos listados en el Administrador de eventos de Facebook 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 Facebook 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 Facebook.

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

Facebook 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

Facebook 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 Facebook Ads es PST. Asegúrate de cambiarla en el Administrador de anuncios de Facebook 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 Facebook.

Referente de instalación de Google

Cuando una instalación sin ID de anunciante se atribuyó a Facebook Ads mediante el referente de instalación de Google Play, AppsFlyer no lo comunica a Facebook Ads. Esto causará una discrepancia, ya que se mostrará en AppsFlyer y no en Facebook Ads.  

Atribución de re-engagement de enlaces profundos

Un re-engagement con enlaces profundos no se reporta a Facebook Ads. Esto causará una discrepancia, ya que se mostrará en AppsFlyer y no en Facebook Ads.

Atribución por clics y por impresiones

AppsFlyer admite tanto atribuciones por clics como por impresiones. Para minimizar las discrepancias entre Facebook Ads 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 Facebook Ads.

La ventana retrospectiva por clics predeterminada de Facebook Ads 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 Facebook Ads. 

Para comparar las ventanas de atribución por clics e impresiones en Facebook con las de AppsFlyer, ingrese a Facebook. Recomendamos configurar las ventanas de atribución en AppsFlyer según valores de Facebook como se muestra en la siguiente pantalla:

Facebook_Discrepancies.png

 Ejemplo

Supongamos que la ventana retrospectiva por clics de Facebook se configura en AppsFlyer en 1 día para tu aplicación com.greatapp, mientras que en Facebook 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 Facebook 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 Facebook 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 Facebook.

 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 Facebook 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 Facebook como una red de asistencia a la conversión, ya que el raw data de Anuncios de Facebook 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 Facebook 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

Facebook 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 Facebook se autoatribuye incorrectamente se indican como asistencias en AppsFlyer.
Combina el raw data de las conversiones atribuidas de Facebook con el raw data donde Facebook es el colaborador.

Definición de tiempo de vida diferente El ciclo de vida de un usuario en Facebook se define como de hasta 7 días, lo que significa que Facebook 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 Facebook se define como un máximo de 180 días.
Cuando evalúes el valor de los usuarios de las campañas de Facebook 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 Facebook y, por lo tanto, no son enviados. Asegúrate de asignar con Facebook 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 Facebook.  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.
Valores de evento faltantes en Facebook AppsFlyer envía parámetros y valores a Facebook como parte de la asignación de eventos, si tienen las estructuras correctas.  Cree sus eventos in-app de SDK según las estructuras recomendadas por AppsFlyer para asignar completamente los valores de eventos con Facebook.

¿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, Facebook se dirige a nuevos usuarios o a usuarios que han instalado la aplicación por primera vez después de un período superioral de la ventana de reatribuciónestablecida, 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 Facebook.

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 Facebook.

 Nota

Si bien Facebook 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

Facebook 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. Facebook 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 Facebook el origen de esta instalación de iOS y Facebook responde con la campaña "Mujeres con Android".

Protect360 y reglas de validación

Si utiliza las reglas de validación de AppsFlyer, los resultados pueden diferir entre AppsFlyer y Facebook cuando hay instalaciones rechazadas que originalmente provienen de Facebook. En estos casos, Facebook 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 Facebook 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 Facebook de España hace clic e instala, Facebook 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 Anuncios de Facebook. Esto podría causar discrepancias tanto en las instalaciones como en los eventos in-app:

  • Instalaciones: En los casos en que el SDK de Anuncios de Facebook se inicializa en el inicio de la aplicación, antes del SDK de AppsFlyer, la instalación solo la registra Anuncios de Facebook y no AppsFlyer. Verifica que el SDK de AppsFlyer se inicialice al iniciar la aplicación, antes del SDK de Anuncios de Facebook.
  • Eventos in-app: Anuncios de Facebook no desduplica los eventos in-app que se reportan de ambos SDK. Esto significa que Anuncios de Facebook puede reportar falsamente ingresos y otros eventos.
    Usa cualquiera de los métodos siguientes para evitar reportes de eventos in-app duplicados en Anuncios de Facebook:

 

 

¿Fue útil este artículo?