Modelo de atribución de AppsFlyer

De un vistazo: AppsFlyer determina la fuente de medios que motiva a un usuario a instalar o volver a interactuar con una aplicación y atribuye la acción del usuario a esa fuente mediante el modelo de atribución de AppsFlyer. 

Mobile_user_journey.png

¿Qué es la atribución?

La atribución es la acción mediante la cual se determina qué generó que un usuario instalara una aplicación o que realizara acciones post-instalación, como el re-engagement o la reatribución. El resultado de la atribución puede ser:

  • Fuente de medios no orgánica: si el usuario interactuó, generalmente por medio de la impresión o el clic, con una fuente de medios.
  • Orgánica: si el usuario no interactuó con una fuente de medios. Nota: Para facilitar la comprensión, a menudo nos referimos a un usuario como atribuido orgánicamente. Sabemos que esto no es estrictamente cierto, ya que los usuarios que instalan orgánicamente no se atribuyen en absoluto. 

La atribución es esencial para optimizar la adquisición de usuarios, las actividades de re-engagement y los resultados.

 Consejo

¿Quieres saber más sobre la atribución? Consulta este breve curso informativo en el portal de aprendizaje de AppsFlyer.

¿Qué es la instalación de una aplicación?

El Modelo de atribución es un conjunto de reglas que determinan cómo se asigna el crédito para un evento a los puntos de contacto en las rutas de conversión. Todos los actores del ecosistema del marketing de aplicaciones, Google Play, App Store, Apple, plataformas de CTV, PC y consola, redes de publicidad como Anuncios de Meta y Twitter, y empresas de medición móvil, tienen sus propios modelos de atribución. Cada actor cuenta las instalaciones y los eventos de manera diferente.

Lo que es importante no es la diferencia entre los modelos, sino que las reglas son claras y se implementan de manera imparcial. Permitir a los anunciantes optimizar campañas y comparar la calidad del rendimiento de los usuarios.

Es importante entender el modelo de atribución de los actores con los que trabajas. Lo más importante es comprender el modelo y matices de los métodos compatibles con AppsFlyer.

En AppsFlyer, un evento atribuible ocurre cuando suceden cualquiera de las siguientes situaciones:

  • En el contexto de la adquisición de usuarios: se registra y atribuye una instalación después de que el usuario descarga e inicia la aplicación. Esto significa que en AppsFlyer la marca de tiempo de la instalación de una aplicación es el primer inicio. Por el contrario, las redes de publicidad usan la hora del engagement y las tiendas de aplicaciones usan la hora de descarga.
  • En el contexto del retargeting:
    • Re-engagement
    • Reatribución 

Métodos de atribución

AppsFlyer usa una serie de métodos de atribución, enumerados en la siguiente tabla: 

Método Usa un ID Técnica

Atribuido por

Android (1)

 

iOS  Plataforma universal de Windows Plataformas de CTV, PC y consola (3)
Referente No Determinista AppsFlyer Sí (2) No No
Coincidencia de ID de dispositivo Determinista AppsFlyer Sí 
Modelado probabilístico No Probabilístico AppsFlyer Sí  Sí  No
Privacidad avanzada agregada (AAP) No Agregados AppsFlyer No No No
Precarga No Determinista AppsFlyer No No
SKAdNetwork (SKAN) No Determinista Apple No No No
Apple Search Ads No Determinista Apple No No No
Enlace profundo No Determinista AppsFlyer No

(1) Google Play y tiendas de terceros

(2) Admitido por algunas tiendas de terceros

(3) Ver lista completa de plataformas de CTV, PC y consola 

 

Los métodos de atribución se usan de acuerdo con las prioridades que se muestran en el gráfico. Después de una instalación nueva, si hay más de un engagement válido, AppsFlyer prioriza los clics sobre las impresiones y los métodos deterministas sobre los probabilísticos

Attribution method priorities 23.png

A continuación, encontrarás descripciones detalladas de los modelos de atribución de AppsFlyer.

Referente de instalación (solo para Android)

Las aplicaciones de Android descargadas de Google Play y de otras tiendas de aplicaciones generalmente se atribuyen por el método del referente de instalación. El referente proporciona la URL original, en la que se ha hecho clic antes de redirigir a la tienda de Android. Este es el método principal para la atribución de Android. Actualmente, Google Play, Huawei App Store, Samsung Galaxy Store y Xiaomi GetApps Store admiten la atribución de referente de instalación. Atribución alternativa de la tienda de aplicaciones utilizando el referente.

Coincidencia de ID de dispositivo

La red de publicidad, que tiene acceso al dispositivo del usuario, envía el ID de dispositivo a AppsFlyer en la URL en la que se hizo clic, o cuando notifica a AppsFlyer que se ha efectuado una impresión. Esto permite que AppsFlyer haga coincidir el ID de dispositivo con el que se hizo clic con el ID de dispositivo capturado por el SDK de AppsFlyer.

La coincidencia de ID de dispositivo es el método de atribución principal en iOS.

Los ID disponibles son:

  • Dispositivos iOS: identificador de anunciante (IDFA), identificador de proveedor (IDFV)
  • Dispositivos Android: con servicios de Google Play: ID de publicidad de Google (GAID) 
  • Dispositivos Android sin servicios de Google Play: OAID, ID de Android, IMEI, ID Fire 

Los ID de dispositivo permiten el hash con SHA1 o MD5 en los enlaces de atribución.

Coincidencia del ID de dispositivo usando el IDFV (iOS)

  • El identificador de proveedor (IDFV) está disponible en iOS 6.0+. No está sujeto a los mecanismos ATTrackingManager y LAT de Apple. Siempre está disponible y puede utilizarse para la publicidad de promoción cruzada de aplicaciones del mismo proveedor. 
  • El SDK de AppsFlyer recopila el IDFV de forma predeterminada. 
  • Según Apple, el valor de esta propiedad es el mismo para las aplicaciones que vienen del mismo vendedor y que funcionan en el mismo dispositivo. 
  • Apple genera un identificador de proveedor (IDFV) cuando el usuario instala la primera aplicación de un proveedor determinado. Es decir, Apple comprueba que no hay otras aplicaciones del mismo proveedor en el dispositivo. Como resultado, borrar todas las aplicaciones de un determinado proveedor y luego instalar una aplicación del mismo proveedor genera un IDFV nuevo. 
  • Debes enviar el IDFV si está disponible. Este mejora la atribución. Usamos el IDFV en una serie de situaciones que incluyen: 
    • Atribución de promociones cruzadas.
    • Atribución de reinstalaciones en el mismo dispositivo.
    • Reportes de raw data.
    • Audiencias.

Coincidencia de ID de dispositivo para redes de autorreporte 

Tras el primer lanzamiento de la aplicación, AppsFlyer verifica la configuración de la aplicación si se espera tráfico de cualquiera de las redes de autorreporte (SRN), como Anuncios de Meta, Snapchat y Google Ads. 

AppsFlyer envía consultas a todas las SRN pertinentes mediante el ID de dispositivo exclusivo de la nueva instalación. La consulta se efectúa mediante las API de partners de medición móvil (MMP), según lo definido por las SRN. En función de las respuestas, AppsFlyer puede atribuir usuarios nuevos a una SRN.

Modelado probabilístico

El modelado probabilístico es una técnica estadística que aprovecha el aprendizaje de máquina para estimar el rendimiento de la campaña. Los parámetros de modelado probabilístico se recogen:

  • Inicialmente en la vista de clic o anuncio (si está habilitado)
  • Una vez más, cuando se inicie la aplicación

Nota para las aplicaciones de iOS:

A partir de iOS 14.5+, el modelado probabilístico se puede utilizar en el contexto de los medios propios, la promoción cruzada y los flujos acordados de la web a la aplicación. En otros contextos, se utiliza la Privacidad avanzada agregada.

Características de implementación

  • Usa estadísticas y no se basa en ID únicos.
  • Es un método alternativo que se utiliza cuando no hay un referente o un ID de publicidad. Los métodos de atribución determinista, es decir, los clics con referencia o coincidencia de ID, tienen prioridad si se producen dentro de la ventana retrospectiva.
  • AppsFlyer determina la ventana de atribución de forma dinámica, en función de la red del usuario. La duración de la ventana es adaptativa pero más corta que la de otros métodos (hasta 24 horas).
  • El modelado probabilístico de clics siempre está habilitado. 
  • El modelado probabilístico por impresiones debe estar habilitado en la página de configuración de la aplicación y en la pestaña de integración de las no SRN pertinentes. Para las aplicaciones de CTV, PC y consola, esto está habilitado de forma predeterminada.

Parámetros de modelado probabilístico para redes de publicidad

Las redes de publicidad que implementen la atribución de modelado probabilístico deben enviar los siguientes parámetros a través del enlace de atribución o de encabezados de solicitud HTTP:

Privacidad avanzada agregada (AAP)

La privacidad avanzada agregada (AAP) expone los resultados del rendimiento de la campaña de manera agregada, lo cual evita cualquier opción para rastrear a los usuarios en aplicaciones y sitios web propiedad de diferentes empresas, y la capacidad de identificar de forma única a un usuario o un dispositivo.

AAP utiliza los niveles de privacidad de Apple SKAdNetwork como un punto de referencia mínimo para sus umbrales de preservación de la privacidad. AAP es el modelo de atribución predeterminado para los dispositivos Apple que operan con iOS 14.5+, excepto en los casos en que Apple lo permita explícitamente, como medios propios y usuarios que dieron su consentimiento para ATT.

A diferencia de los otros métodos de atribución descritos, el objetivo del algoritmo de aprendizaje de máquina AAP es maximizar la precisión del rendimiento agregado de la campaña, no la precisión de la atribución del usuario final.

Campañas de precarga

En las campañas de precarga, las aplicaciones son instaladas en el dispositivo de un usuario por un partner de precarga, ya sea en la fábrica o después de la activación del dispositivo. Los partners de precarga pueden ser:

  • Fabricantes de equipos originales (OEM)
  • Plataformas de descubrimiento de aplicaciones
  • Compañías de telefonía móvil

Existen 3 métodos para atribuir campañas de precarga. Los tres métodos se pueden utilizar simultáneamente; no interfieren con los mecanismos del otro.

Los 3 métodos y algunas de las especificaciones principales se describen en la tabla que sigue. Haz clic en los enlaces para obtener más información sobre cada método de precarga.

Método de atribución de precarga Caso de uso Información de activación del dispositivo para el inicio de la aplicación* Ventana retrospectiva** Tipo de concordancia en el raw data
Referente de AppsFlyer*
  • Precargado en fábrica
  • Precargado tras la activación del dispositivo
  • Hasta 180 días
  • El valor predeterminado es de 90 días
  • Precarga: preload_rfr
  • Haz clic para descargar: af_referrz
Instalación automática de Google Play**

Precargado al activar el dispositivo (para aplicaciones de Google Play)

No
  • Hasta 180 días
  • El valor predeterminado es de 90 días
preload_pai
Precarga en fábrica a través de la propiedad del sistema (Android)**
  • Precargado en fábrica
  • Precargado tras la activación del dispositivo
No

Sin límite

preload_conf

* La solución de precarga del referente de AppsFlyer proporciona capacidades de visibilidad y medición entre la activación del primer dispositivo y el primer inicio de la aplicación. Esto te permite ver cuántos dispositivos fueron activados con la aplicación precargada en los dispositivos por un partner específico, y luego ver cuándo se inicia la aplicación por primera vez.

Para los otros dos métodos, la atribución se determina solo después de que el usuario inicie la aplicación por primera vez, el número de dispositivos que tenían la aplicación instalada antes del primer inicio no está disponible.

** Puede tomar días o semanas, desde la primera vez que el usuario enciende su dispositivo hasta que inicia la aplicación precargada por primera vez. En consecuencia, AppsFlyer da a las campañas de precarga la máxima prioridad a la hora de determinar la atribución, con ventanas retrospectivas más largas.

 

Enlace profundo

Solo para re-engagements, los usuarios no se redirigen a una tienda de aplicaciones para descargar la aplicación. Por lo tanto, la información en la URL se puede conectar directamente al clic (y a la posterior apertura de la aplicación). Este método de atribución se conoce como enlace profundo, ya que es la URL de enlace profundo la que lleva la información utilizada para atribuir el re-engagement.

Métodos de atribución por fuente de medios y característica de AppsFlyer

Consulta las secciones a continuación para obtener un desglose completo de qué métodos de atribución particulares se admiten, según:

  • Fuente de medios: propia o paga
  • Característica de AppsFlyer utilizada
  • Dispositivo del usuario: Android o iOS

Medios propios

Fuente de medios Característica Método de atribución
Android iOS
Medios propios: correo electrónico (incluidos ESP), SMS, publicaciones en redes sociales, influencers/afiliados, impresión, etc. OneLink
  • Referente de instalación
  • Modelado probabilístico

Modelado probabilístico

Página de aterrizaje/sitio web móvil propio con tráfico entrante pagado u orgánico banners inteligentes y la PBA? Modelado probabilístico Modelado probabilístico
Script de OneLink Smart
  • Referente de instalación
  • Modelado probabilístico
Modelado probabilístico
Aplicaciones móviles propias Referencias/invitaciones de usuarios

Modelado probabilístico

Modelado probabilístico

Promoción cruzada Coincidencia de ID de dispositivo Coincidencia de ID de dispositivo

Medios pagados

Fuente de medios Método de atribución
Android iOS Plataformas CTV, PC y consola
SRN

Coincidencia de ID de dispositivo

  • Coincidencia de ID de dispositivo
  • AAP (iOS 14.5+)
  • SKAdNetwork (iOS 14+)

Coincidencia de ID de dispositivo

 

  • Referente de instalación
  • Coincidencia de ID de dispositivo
  • Modelado probabilístico
  • Coincidencia de ID de dispositivo
  • Modelado probabilístico (antes de iOS 14.5)
  • AAP (iOS 14.5+)
  • SKAdNetwork (iOS 14+)
 

Preinstalado en el dispositivo

Instalaciones previas --  

Tipos de atribución de captación de usuarios

La atribución se realiza en función de los engagements por impresiones y clics. La atribución de fuentes de medios se logra usando técnicas de coincidencia de ID de dispositivo y modelado probabilístico.

Atribución por clics

La mayoría de las instalaciones son el resultado de los clics de los usuarios en anuncios, como banners, videos e intersticiales.

Al hacer clic en un anuncio, se abre una ventana retrospectiva por clics con una duración predeterminada de 7 días. Las instalaciones que ocurren en el período de la ventana retrospectiva se consideran no orgánicas y se atribuyen a la fuente de medios. Las instalaciones que ocurren fuera de la ventana retrospectiva se consideran instalaciones orgánicas. A menudo se conocen como atribuidas orgánicamente. 

  • Una ventana retrospectiva de siete días se considera el estándar de la industria. Configura la duración de la ventana según tu acuerdo con la fuente de medios. 
  • Alinea las ventanas retrospectivas de SRN con la duración determinada por la SRN. 

Tipo de atribución

Método de atribución

Intervalo

Predeterminado

Por clics

(Todos los partners integrados)

 

Coincidencia de ID, referente

1 – 30 días

7 días

Modelado probabilístico

0-24 horas

  • Adaptativa
  • Determinado por AppsFlyer

Aprender más sobre las ventanas retrospectivas

Atribución por impresiones

Los usuarios que visualizan anuncios, pero que no hacen clic en ellos, pueden atribuirse a las redes de publicidad donde se presentaron los anuncios.

Ventana retrospectiva para la atribución por impresiones:

  • es más corta que la ventana retrospectiva de atribución por clics.
  • es configurable.

Para habilitar la atribución por impresiones, configura la ventana retrospectiva en la ventana de configuración.

Esto es especialmente útil para redes de publicidad de video que suelen tener CTR bajos en sus anuncios de video. También resulta útil para redes de publicidad tradicionales que ofrecen anuncios regulares.

Tipo de atribución

Método de atribución

Intervalo

Predeterminado

Por impresiones

(Partners integrados seleccionados)

 

Coincidencia de ID

0-24 horas

1 día

Modelado probabilístico

0-24 horas

  • Adaptativa
  • Determinado por AppsFlyer

En los casos en que hay un clic y una impresión, el clic siempre prevalece, ya que es una instancia de engagement activo.

Aprender más sobre la atribución por impresiones

Temas avanzados sobre atribución

Eventos in-app

AppsFlyer crea un ID único de AppsFlyer para una instalación de una aplicación, que se asocia con los detalles de atribución. Esto permite que la plataforma atribuya los eventos in-app a la fuente de medios original. Los anunciantes pueden usar esta información para seguir las trayectorias de los usuarios en el raw data de su aplicación.

Para obtener más información sobre la atribución de eventos, haz clic aquí.

Instalaciones asistidas

AppsFlyer atribuye totalmente solo una fuente de medios por instalación, por lo general según el último clic en el anuncio o la última impresión del anuncio (si no hubo clics).

Las instalaciones asistidas (lo que también se conoce como atribución multi toque) son instalaciones en las que la campaña/fuente de medios no fue el último punto de toque, pero sí "tocó" al usuario antes de la instalación, y esto tuvo lugar dentro de la ventana de atribución retrospectiva.

Las redes de asistencia se muestran como colaboradores de la instalación en AppsFlyer.

Para obtener más información, haz clic aquí.

Reinstalaciones

Una reinstalación ocurre cuando un usuario instala la aplicación, la desinstala y, luego, la vuelve a instalar. La atribución de reinstalaciones está regulada por la ventana de reatribución de la siguiente manera:

  • Si la reinstalación ocurre después del vencimiento de la ventana de reatribución: se registra una instalación nueva.
  • Si la reinstalación ocurre durante la ventana de reatribución, aplica una de las siguientes situaciones:
    • Si el usuario se involucró con una campaña de retargeting antes de la reinstalación: se registra una reinstalación de retargeting (también conocida como reatribución).
    • Si el usuario no se involucró con una campaña o se involucró con una campaña de UA: no se registra ninguna instalación. Dependiendo del estado de la atribución de eventos posteriores a la reinstalación, los eventos in-app de estos usuarios que reinstalan se atribuyen a la instalación orgánica o a la original. 

Para pruebas de dispositivos e instalaciones múltiples, registra el dispositivo en AppsFlyer. Si no lo registras, solo se registra la primera instalación.

Ten en cuenta que AppsFlyer permite una mayor precisión para atribuir las reinstalaciones de iOS sin ID de anunciante. Puedes habilitar esta función en la página Configuración de la aplicación.

Reinstalar aplicaciones de iOS desde una copia de seguridad de iCloud

Cuando se realiza una copia de seguridad de una aplicación mediante iCloud y luego se restaura (en el mismo dispositivo o en otro), AppsFlyer no la cuenta como una instalación nueva o reinstalación. Un usuario que restaura una aplicación desde iCloud mantiene su ID de AppsFlyer y sus datos de atribución.

Atribución de retargeting

Retargeting_-_Flow__2_.png

Un usuario que reinstala una aplicación dentro de la ventana de reatribución (90 días de forma predeterminada) se considera una reatribución. Si esta instalación ocurre después de involucrarse con una campaña de retargeting, se registra como una reinstalación de retargeting, también conocida como una reatribución, y se reporta en el retargeting

Actualizaciones de aplicaciones

  • Cuando los usuarios existentes actualizan la aplicación a una versión posterior, esto no se trata como un evento de atribución contable, si AppsFlyer atribuyó previamente al usuario. Nota: Si migras a AppsFlyer desde un MMP diferente los usuarios existentes en la primera apertura de la aplicación, después de la migración, se atribuyen a orgánico. 
  • Las métricas relacionadas con la cantidad de usuarios por versión de la aplicación están disponibles en el panel de control de información de SDK.