En resumen: AppsFlyer identifica la fuente de medios que lleva a un usuario a instalar o volver a involucrarse con una aplicación y atribuye la acción del usuario a esa fuente utilizando su modelo de atribución.
¿Qué es la atribución?
La atribución consiste en determinar qué ha motivado a un usuario a instalar una aplicación o a realizar acciones posteriores, como el reengagement o la reatribución. El resultado de la atribución puede ser:
- Una fuente de medios no orgánica: El usuario interactuó (comúnmente mediante una impresión o un clic) con una fuente de medios.
- Orgánico: El usuario no interactuó con una fuente de medios. ¡Nota importante! Para simplificar, a menudo hablamos de un usuario atribuido orgánicamente. Sabemos que esto no es totalmente exacto, ya que los usuarios que instalan orgánicamente no están atribuidos.
La atribución es fundamental para optimizar la adquisición de usuarios, las estrategias de reengagement y sus resultados.
Consejo
¿Te interesa saber más sobre la atribución? Explora este breve e informativo curso en el AppsFlyer Learning Portal.
¿Qué es una instalación de la aplicación?
El modelo de atribución es un conjunto de reglas que decide cómo se asigna el crédito de un evento a los puntos de contacto en los caminos de conversión. Cada componente del ecosistema de marketing de aplicaciones, como Google Play, App Store, Apple, las plataformas CTV, PC y consola, ad networks como Meta Ads y X Ads, y empresas de medición móvil, tiene su propio modelo de atribución. Cada uno cuenta las instalaciones y eventos de manera distinta.
Lo relevante no es tanto la diferencia entre los modelos, sino que las reglas sean claras e imparciales. Esto permite a los anunciantes optimizar campañas y evaluar la calidad del rendimiento de los usuarios de manera efectiva.
Es crucial conocer los modelos y reglas de los actores con los que trabajas. Lo más importante es entender el modelo y las particularidades de los métodos compatibles con AppsFlyer.
En AppsFlyer, un evento atribuible ocurre cuando pasa cualquiera de lo siguiente:
- En el contexto de la adquisición de usuarios: Una instalación se registra y atribuye después de que el usuario descarga y abre la aplicación. Esto significa que en AppsFlyer, la marca temporal de una instalación es la primera apertura de la aplicación. Por el contrario, las ad networks utilizan el tiempo de engagement y las tiendas de aplicaciones usan el tiempo de descarga.
- En el contexto del retargeting:
- Re-engagement
- Re-atribución
Métodos de atribución
AppsFlyer utiliza varios métodos de atribución, enumerados en la tabla a seguir:
| Método | Utiliza el ID del dispositivo | Técnica | Atribuido por |
Android (Google Play y tiendas de terceros)
|
iOS | Universal Windows Platform (UWP) | Plataformas CTV, PC y consola (3) |
|---|---|---|---|---|---|---|---|
| Referencia (1) | No | Determinista | AppsFlyer | Sí (2) | No | Sí | No |
| Coincidencia de ID de dispositivo (1) | Sí | Determinista | AppsFlyer | Sí | Sí | Sí | Sí |
| Modelado probabilístico (1) | No | Probabilístico | AppsFlyer | Sí | Sí | No | Sí |
| Privacidad avanzada agregada (AAP) (1) | No | Agregado | AppsFlyer | No | Sí | No | No |
| Precarga (1) | No | Determinista | AppsFlyer | Sí | No | Sí | No |
| SKAdNetwork (SKAN) | No | Determinista | Apple | No | Sí | No | No |
| Apple Search Ads (1) | No | Determinista | Apple | No | Sí | No | No |
| Deep link (1) | No | Determinista | AppsFlyer | Sí | Sí | Sí | No |
|
(1) A veces se denomina "método de atribución clásico" en los dashboards y reportes de AppsFlyer (2) Compatible con algunas tiendas de terceros |
|||||||
Prioridades de los métodos de atribución (cascada de atribución)
En una nueva instalación, 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. Los métodos de atribución se utilizan de acuerdo con las prioridades mostradas en el gráfico.
Encuentra a continuación descripciones detalladas de los modelos de atribución de AppsFlyer.
Referente de instalación (solo Android)
- Las aplicaciones de Android descargadas de Google Play y algunas otras tiendas de aplicaciones generalmente se atribuyen mediante el método del referente de instalación. El referente proporciona la URL original donde se hizo clic antes de redireccionar a la tienda de Android. Este es el método principal para la atribución en Android. Actualmente, Google Play, la tienda de aplicaciones de Huawei, Samsung Galaxy Store y Xiaomi GetApps Store admiten la atribución mediante referente de instalación. Atribución de tiendas de aplicaciones alternativas usando el referente.
- Referente de instalación de Meta: AppsFlyer admite la atribución de anuncios meta para aplicaciones de Android al recibir metadatos de campañas publicitarias del almacenamiento local de un dispositivo. Estos datos se utilizan para la medición de atribución (atribución de Meta en el dispositivo).
Coincidencia de ID de dispositivo
Un método clásico de atribución en el que la ad network, que tiene acceso al dispositivo del usuario, envía el ID del dispositivo a AppsFlyer en la URL de clic o al notificar a AppsFlyer que se ha servido una impresión. Esto permite a AppsFlyer emparejar el ID del dispositivo del clic con el ID del dispositivo obtenido por el SDK de AppsFlyer.
La coincidencia de ID de dispositivo es el método principal de atribución en iOS.
Los IDs disponibles son:
- Dispositivos iOS: IDFA, IDFV
- Dispositivos Android con servicios de Google Play: GAID
- Dispositivos Android sin servicios de Google Play: OAID, Android ID, IMEI, Fire ID
Los IDs de dispositivos pueden ser codificados con SHA1 o MD5 en los enlaces de atribución.
Coincidencia de ID de dispositivo usando IDFV (iOS)
- Un método clásico de atribución que utiliza el identificador para proveedores (IDFV) está disponible en iOS 6.0+. No está sujeto a los mecanismos ATTrackingManager y LAT de Apple. Siempre está disponible y se puede usar para publicidad cruzada de aplicaciones del mismo proveedor.
- El SDK de AppsFlyer recopila IDFV por defecto.
- Según Apple, el valor de esta propiedad es el mismo para las aplicaciones que provienen del mismo proveedor y se ejecutan en el mismo dispositivo.
- Apple genera un IDFV cuando el usuario instala la primera aplicación de un proveedor concreto. Esto significa que Apple verifica que no haya otras aplicaciones del mismo proveedor en el dispositivo. Por lo tanto, al eliminar todas las aplicaciones de un proveedor específico y luego instalar una aplicación del mismo proveedor se genera un nuevo IDFV.
- Debes enviar el IDFV si está disponible. Esto mejora la atribución. Hacemos uso del IDFV en varios escenarios, entre ellos:
- Atribución de promoción cruzada.
- Atribución de reinstalación en el mismo dispositivo.
- Reporte de raw data.
- Audiences.
Coincidencia de ID de dispositivo para redes de autoreporte.
Un método clásico de atribución donde, al iniciar por primera vez la aplicación, AppsFlyer comprueba en la configuración si se espera tráfico de alguna de las redes de autoreporte (SRNs), como Meta Ads, Snapchat y Google Ads.
AppsFlyer consulta a las SRNs relevantes utilizando el ID de dispositivo único de la nueva instalación. La consulta hace uso de las APIs de Mobile Measurement Partners (MMP) según lo definido por las SRNs. Dependiendo de la respuesta, AppsFlyer puede atribuir los nuevos usuarios a una SRN.
Modelado probabilístico
El modelado probabilístico es una técnica estadística que utiliza el aprendizaje automático para estimar el rendimiento de las campañas. Se recopilan los parámetros del modelado probabilístico:
- Inicialmente, al hacer clic o al ver un anuncio (si está habilitado)
- Y nuevamente cuando se inicia la aplicación
Características de implementación
- Se basa en estadísticas y no en IDs únicos.
- Es un método alternativo que se utiliza en ausencia de un referente o IDs publicitarios. Los métodos de atribución determinista, como los clics con referentes o coincidencia de ID, tienen prioridad si ocurren dentro de la ventana de lookback.
- Para aplicaciones móviles, AppsFlyer determina dinámicamente la ventana de atribución 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).
- Para aplicaciones de CTV, PC y consola, la ventana de atribución se determina por el parámetro de enlace
af_lookback_window, pero no puede exceder los 7 días. - El modelado probabilístico click-through siempre está activado.
- El modelado probabilístico view-through debe activarse en la página de configuración de la aplicación y en la pestaña de integración para las que no son SRNs. Para las aplicaciones de CTV, PC y consola, esto está activado por defecto.
Parámetros del modelado probabilístico para ad networks
Las ad networks que implementan la atribución mediante modelado probabilístico deben enviar los siguientes parámetros a través del enlace de atribución o mediante los encabezados de solicitud HTTP:
Privacidad Avanzada Agregada (AAP)
La Privacidad Avanzada Agregada (AAP) es un método clásico de atribución en el cual los resultados del rendimiento de las campañas se exponen de forma agregada, evitando así la posibilidad de registrar usuarios en aplicaciones y sitios web propiedad de distintas empresas, y la capacidad de identificar de manera única a un usuario o dispositivo.
AAP utiliza los niveles de privacidad de Apple SKAdNetwork como estándar mínimo para sus umbrales que preservan la privacidad. AAP es el modelo de atribución predeterminado para los dispositivos Apple con iOS 14.5+, salvo en casos permitidos explícitamente por Apple, como los medios propios y usuarios con consentimiento ATT.
A diferencia de otros métodos de atribución, el objetivo del algoritmo de aprendizaje automático de AAP es maximizar la precisión del rendimiento agregado de la campaña, y no la precisión de la atribución del usuario final.
Campañas precargadas
Un método clásico de atribución para campañas precargadas, cuando las aplicaciones son instaladas en el dispositivo del usuario por un partner de precarga, ya sea en la fábrica o al activar el dispositivo. Los partners de precarga pueden ser:
- Original Equipment Manufacturers (OEMs)
- Plataformas de descubrimiento de aplicaciones
- Operadores móviles
Hay 3 métodos para atribuir campañas precargadas. Los tres métodos pueden utilizarse simultáneamente, ya que no interfieren entre sí.
Los tres métodos y algunas especificaciones clave se presentan en la tabla siguiente. 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 desde la activación del dispositivo hasta el inicio de la aplicación* | Ventana de lookback** | Tipo de coincidencia en raw data |
|---|---|---|---|---|
| Referente de AppsFlyer* |
|
Sí |
|
|
| Instalación automática de Google Play** | Precargado al activar el dispositivo (para aplicaciones de Google Play) | No |
|
precarga_pai |
| Precarga en fábrica vía System Property o manifest (Android)** |
|
No | Sin límite | precarga_conf |
|
* La solución de precarga de referente de AppsFlyer proporciona capacidades de visibilidad y medición desde la primera activación del dispositivo hasta el primer inicio de la aplicación. Esto te permite ver cuántos dispositivos fueron activados con la aplicación precargada por un partner específico y luego observar cuándo se lanza la aplicación por primera vez. Para los otros dos métodos, la atribución solo se determina después de que el usuario inicia la aplicación por primera vez; no está disponible la cantidad de dispositivos que tenían la aplicación instalada antes de ese momento. ** Puede tardar días o semanas desde que el usuario enciende el dispositivo hasta que abre por primera vez la aplicación precargada. Por ello, AppsFlyer otorga la máxima prioridad a las campañas de precarga en la determinación de la atribución, utilizando ventanas de lookback más largas.
| ||||
Deep link
Un método clásico de atribución solo para re-engagements, cuando los usuarios no son redirigidos a una tienda de aplicaciones para descargar la app. Por lo tanto, la información de la URL se puede relacionar directamente con el clic (y la posterior apertura de la app). Este método de atribución se denomina enlace profundo porque es la URL del enlace profundo la que lleva la información utilizada para atribuir el reengagement.
Métodos de atribución por fuente de medios y característica de AppsFlyer
Consulta las siguientes secciones para obtener un desglose completo de los métodos de atribución compatibles, dependiendo de:
- Fuente de medios: propia o de pago
- Funcionalidad 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 ESPs), SMS, publicaciones en redes sociales, influencers/afiliados, medios impresos, etc. | OneLink |
|
Modelado probabilístico |
| Sitio web móvil/landing page propia con tráfico entrante, ya sea de pago u orgánico | Smart Banners |
|
Modelado probabilístico |
| Smart Script de OneLink |
|
Modelado probabilístico | |
| Aplicaciones móviles propias | Invitaciones/referencias de usuarios |
|
Modelado probabilístico |
| Promoción cruzada |
|
Coincidencia de ID de dispositivo | |
Medios de pago
| Fuente de medios | Método de atribución | ||
|---|---|---|---|
| Android | iOS | Plataformas CTV, PC y consolas | |
| SRNs | Coincidencia de ID de dispositivo |
|
Coincidencia de ID de dispositivo |
|
|
|
|
| Preinstalado en el dispositivo | Preinstalaciones | -- | |
Tipos de atribución por engagement de usuario
La atribución se lleva a cabo basándose en engagements click-through y view-through. La atribución de la fuente de medios se logra utilizando técnicas de modelado probabilístico y coincidencia de identificadores de dispositivos.
Atribución click-through
La mayoría de las instalaciones son resultado de clics de usuarios en anuncios, como banners, videos e intersticiales.
Al hacer clic en el anuncio, se abre una ventana de lookback con una duración predeterminada de 7 días. Las instalaciones que ocurren dentro de este período no son orgánicas y se atribuyen a la fuente de medios. Las instalaciones que se producen después del final de la ventana de lookback se consideran orgánicas. A menudo se denominan atribuidas orgánicamente.
- Una ventana de lookback de siete días se considera el estándar de la industria. Establece la duración de la ventana según tu acuerdo con la fuente de medios.
- Alinea las ventanas de lookback del SRN con la duración determinada por el propio SRN.
| Tipo de atribución | Método de atribución | Rango | Predeterminado |
|---|---|---|---|
|
Click-Through (Todos los partners integrados)
|
Referente, coincidencia de ID | 1–30 días | 7 días |
| Modelado probabilístico | 0–24 horas |
|
Atribución view-through
Los usuarios que ven anuncios pero no interactúan con ellos pueden atribuirse a las ad networks que los muestra.
La ventana de lookback para la atribución view-through:
- es más corta que la de atribución click-through
- Es configurable.
Esto resulta especialmente útil para las ad networks de video, que tradicionalmente tienen CTR bajos en sus anuncios, pero también para ad networks convencionales.
En los casos donde se produce tanto un clic como una impresión, el clic siempre prevalece, ya que representa un engagement activo.
| Tipo de atribución | Método de atribución | Rango |
Predeterminado |
|---|---|---|---|
|
View-through (para partners integrados seleccionados)
|
Coincidencia de ID | 0-24 horas | 1 día |
| Modelado probabilístico | 0-24 horas |
|
Para activar la atribución view-through:
- Configura la ventana de lookback en la ventana de configuración.
Temas avanzados de atribución
Eventos in-app
AppsFlyer utiliza el ID del dispositivo o ID único de AppsFlyer para atribuciones (como una instalación, reinstalación o reatribución de la app) para atribuir eventos in-app a la fuente de medios. Los anunciantes pueden utilizar esta información para seguir los viajes de los usuarios en los raw data de su app. En el agregado diario, el ID del dispositivo/ID de AppsFlyer se utiliza para calcular el número de usuarios únicos, por ejemplo, la cantidad de usuarios únicos que realizan un evento in-app.
Para más información sobre la atribución de eventos, haz clic aquí.
Instalaciones asistidas
AppsFlyer atribuye completamente solo una fuente de medios por instalación, generalmente utilizando el último clic en el anuncio o la última impresión (si no hubo clics).
Las instalaciones asistidas (también llamadas atribución multitáctil) son instalaciones en las que la fuente de medios o campaña no fue el último punto de contacto, sino que interactuó con el usuario antes de la instalación, dentro de la ventana de atribución.
Las redes que ayudan se muestran como contribuyentes a la instalación en AppsFlyer.
Para más información, haz clic aquí.
Reinstalaciones
Una reinstalación ocurre cuando un usuario instala la aplicación, la desinstala y luego vuelve a instalarla. La atribución de reinstalación está regulada por la ventana de reatribución de la siguiente manera:
- Si la reinstalación se produce después de que expire la ventana de reatribución: se registra una nueva instalación.
- Si la reinstalación ocurre durante la ventana de reatribución, se aplica una de las siguientes situaciones:
- Si el usuario interactuó 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 interactuó con ninguna campaña o solo participó en una campaña de UA: no se registra ninguna instalación. Dependiendo del estado de Atribución de eventos posteriores a la reinstalación, los eventos in-app de estos usuarios que reinstalan la aplicación se atribuyen a la instalación orgánica o a la original.
Para probar el dispositivo y realizar múltiples instalaciones, registra el dispositivo en AppsFlyer. Si no se registra el dispositivo, solo se registrará la primera instalación.
Ten en cuenta que AppsFlyer permite mayor precisión al atribuir reinstalaciones de iOS sin un ID de anunciante. Puedes activar esta función en la página de configuración de la aplicación.
Reinstalar aplicaciones de iOS respaldadas en iCloud
Cuando una aplicación se respalda utilizando iCloud y luego se restaura (en el mismo dispositivo o en otro), AppsFlyer no la cuenta como una nueva instalación o reinstalación. Un usuario que restaura una aplicación desde iCloud conserva su ID de AppsFlyer y sus datos de atribución.
Atribución de retargeting
Un usuario que reinstala una aplicación dentro de la ventana de reatribución (por defecto, 90 días) se considera una reatribución. Si esta instalación ocurre tras interactuar con una campaña de retargeting, se registra como una reinstalación de retargeting, también conocida como reatribución, y se reporta en retargeting.
Actualizaciones de la aplicación
- Cuando los usuarios ya existentes actualizan la aplicación a una versión posterior, no se considera un evento atribuible, si el usuario fue previamente atribuido por AppsFlyer. ¡Importante! Si migras a AppsFlyer desde otro MMP, los usuarios ya existentes en la primera apertura de la app tras la migración, se atribuyen como orgánicos.
- Las métricas relacionadas con el número de usuarios por versión de la app están disponibles en el dashboard de información del SDK.