[Beta] Atribución multiplataforma basada en usuarios

¿Qué es la atribución basada en usuarios?

Es un modelo multiplataforma que se basa en un ID de usuario cliente (CUID) persistente para vincular eventos de conversión entre plataformas. Mediante el uso del CUID, el modelo atribuye toda la actividad a la fuente de medios original que impulsó el primer evento de conversión del usuario.

Un ejemplo de viaje de usuario multiplataforma

Por ejemplo, un usuario hace clic en un anuncio web de Google, se registra y completa una compra en un navegador de desktop. Más tarde, el mismo usuario hace clic en un anuncio móvil de Instagram, instala la aplicación móvil y realiza otra compra in-app. Una semana después, el usuario instala la aplicación CTV de la marca, inicia sesión con el mismo CUID y también inicia una suscripción de pago allí.

Debido a que el CUID identifica constantemente al usuario en todas las plataformas y a que la campaña web de Google fue el primer evento de lanzamiento no orgánico asociado a ese CUID, toda la actividad posterior, incluida la compra de aplicaciones móviles y la suscripción a CTV, se atribuye a la campaña de Google.

Atribución basada en usuarios vs basada en dispositivos

Este modelo aborda una limitación clave de la atribución basada en dispositivos, que trata cada dispositivo como un usuario separado y fragmenta la trayectoria del usuario entre plataformas. Por el contrario, la atribución centrada en el usuario vincula los eventos entre dispositivos mediante un CUID persistente, lo que permite una medición coherente, un acreditamiento preciso de la campaña y una comprensión real del LTV en toda la línea de productos.

El siguiente ejemplo de viaje del usuario ilustra la diferencia entre la atribución centrada en el dispositivo y la centrada en el usuario:

Un usuario hace clic en un anuncio de Meta en la web, es redirigido al sitio web del anunciante, se registra y crea una cuenta. Más tarde, el mismo usuario instala la aplicación de iOS del anunciante, inicia sesión y realiza una compra de $50. Unos días después, el usuario ve un anuncio de YouTube, instala la aplicación de PC del anunciante, inicia sesión de nuevo y realiza una compra de $100.

La atribución basada en dispositivos acredita $0 a Meta Ads, mientras que la atribución basada en usuarios acredita $150. La tabla a continuación muestra cómo se atribuiría este viaje en cada modelo:

¿Por qué un evento es candidato para la atribución multiplataforma?

Un evento se considera candidato a atribución multiplataforma si cumple todas las condiciones a seguir:

• El CUID está presente: El evento debe incluir un ID de usuario válido (CUID), es decir, un identificador persistente proporcionado por el anunciante (por ejemplo, ID de acceso o correo electrónico con hash) que identifique de manera única a un usuario en todos los dispositivos y plataformas. 
  • Si a un evento le falta un CUID pero comparte el mismo appsflyer_id, AppsFlyer puede rellenar el CUID en un breve periodo de procesamiento, hasta 4 horas antes de que llegue el primer evento con un CUID. Para más información, consulta la ventana de procesamiento de enriquecimiento de CUID a continuación.
  • Los eventos que llegan sin un CUID y no se pueden enriquecer a través del proceso de enriquecimiento de CUID todavía se incluyen en la atribución multiplataforma. En estos casos, la atribución se determina utilizando su método de atribución a nivel de dispositivo (clásico).
• Pertenece a una línea de productos: La aplicación que genera el evento debe formar parte de una línea de productos, es decir, una agrupación de aplicaciones relacionadas (por ejemplo, iOS, Android, CTV) bajo la misma marca, para las que la atribución se amplía y configura colectivamente. Para más información, consulta Agrupar aplicaciones para la atribución multiplataforma.
• Dentro de la ventana de restauración de inactividad: El evento debe estar dentro de la ventana de inactividad, es decir, un período configurable (por ejemplo, de 7 a 390 días) durante el cual un CUID se considera activo y elegible para la atribución dentro de una línea de productos determinada. Si el CUID no se ha visto dentro de esta ventana, se descarta su asignación de atribución anterior. 
• Los campos de atribución a nivel de dispositivo están presentes: El evento ya debe contener parámetros de atribución válidos a nivel de dispositivo (por ejemplo, fuente de medios, ID de campaña) derivados del modelo clásico de atribución basada en dispositivos de AppsFlyer.

¿Cómo se determina la fuente de atribución?

Este modelo atribuye todos los eventos de un usuario determinado (CUID) a la fuente de medios original que impulsó la primera conversión del usuario.

La fuente de medios original atribuida se determina siguiendo la siguiente lógica:

• Para cada evento in-app con un CUID en una línea de productos, AppsFlyer identifica el evento de inicio más temprano para ese CUID (es decir, un evento de inicio con una fuente de medios válida).
• La fuente de medios atribuida a ese evento de inicio por atribución clásica centrada en el dispositivo se considera la fuente de atribución para el evento in-app.
• Esta fuente de medios se utiliza como fuente de atribución multiplataforma de adquisición de usuarios para todos los eventos posteriores asociados con ese CUID y esa línea de productos.
• Si falta el CUID en un evento in-app, AppsFlyer intenta rellenarlo durante la ventana de procesamiento de enriquecimiento de 1-4 horas. 
• Si un evento sin CUID llega fuera de la ventana de enriquecimiento de CUID definida, seguirá incluido en la atribución multiplataforma. Estos eventos se atribuyen utilizando su método de atribución a nivel de dispositivo (clásico).

La ventana de procesamiento de enriquecimiento de CUID

Es el período (de 1-4 horas) durante el cual AppsFlyer procesa los eventos in-app recién llegados para rellenar los ID de usuario (CUID) de los clientes que faltan. Esto permite la atribución multiplataforma incluso si algunos eventos in-app llegan sin un CUID.

¿Cómo funciona el enriquecimiento CUID?

• Cada 1-4 horas, AppsFlyer ejecuta un trabajo de procesamiento.
• Si un evento llega sin un CUID pero comparte el mismo appsflyer_id que otro evento con un CUID, AppsFlyer rellena el CUID que falta.
• Esta vinculación solo se aplica a los eventos recibidos durante la ventana de procesamiento.

Ejemplo de enriquecimiento de CUID

• 8:01: Un evento de primera apertura de la aplicación se registra con appsflyer_id = XYZ.
• 9:00: Se registra un evento de registro con cuid = 123 y appsflyer_id = XYZ.
• 12:00: Finaliza la ventana de procesamiento de 4 horas. AppsFlyer une cuid = 123 retroactivamente al evento de primera apertura de la aplicación.
• 12:30: Un evento de compra se registra con appsflyer_id = XYZ pero sin CUID. Como el evento llega después de que se cierra la ventana, AppsFlyer no le da cuid = 123.

Limitaciones de enriquecimiento de CUID

• Los eventos sin CUID que llegan fuera de la ventana se atribuyen mediante la atribución clásica de AppsFlyer y se agregan a los resultados del método de atribución multiplataforma.
• La vinculación del CUID no se aplica de forma retroactiva fuera de la ventana de procesamiento.

Configuración de la atribución multiplataforma

Para configurar la atribución multiplataforma, debes aplicar algunas configuraciones en AppsFlyer e implementar funciones específicas del SDK en el código de tu aplicación. 

• En AppsFlyer, asigna tus aplicaciones a una línea de producto, opta por la atribución multiplataforma y especifica la ventana de restauración de inactividad. Para más información, consulta Configurar una línea de productos.
• En tu aplicación, configura el SDK de AppsFlyer para enviar eventos con CUID. Para obtener instrucciones para desarrolladores, consulta Configurar ID de usuario de cliente.

Ver resultados de atribución multiplataforma

• Para ver los resultados de la atribución multiplataforma, consulta el reporte multiplataforma de eventos de usuario final de Data Locker.
• Planificado: Un nuevo método de atribución disponible en My Dashboard

.