Una vez que el Usuario llega a la página de destino, AppsFlyer debe capturar esa interacción mediante un listener integrado.

• SDK web (píxel): Un fragmento del lado del cliente implementado directamente en el sitio web o mediante Google Tag Manager (GTM).
• API de servidor a servidor (S2S): Una integración robusta del lado del servidor que te ayuda a evitar la prevención de la medición en el navegador y los bloqueadores de anuncios, al tiempo que te permite enriquecer los datos antes de que lleguen a AppsFlyer. La integración S2S puede hacerse directamente desde un servidor del cliente o mediante Google Tag Manager Server Side.

Después de recopilar los datos de la sesión, el sistema determina si debe crear un registro de primera visita. Este registro actúa como una capa de preprocesamiento que captura la actividad sin procesar del usuario antes de la resolución real de la fuente de medios y la atribución. No todas las sesiones se registran como visitas.

AppsFlyer registra una visita cuando alguien llega a tu sitio en una nueva sesión o con parámetros de fuente reconocibles, e ignora las visitas de dominios excluidos. Estas reglas de registro de visitas evitan la contabilización doble de las sesiones.

Para más información, consulta Registro de visitas.

Después de recopilar los datos y registrar la visita, el motor los evalúa según un orden de prioridad definido. Esta cascada admite tanto parámetros específicos de AppsFlyer como parámetros estándar del mercado, por lo que los clientes no necesitan cambiar sus enlaces de atribución actuales durante la migración. La primera señal coincidente de la cascada se utiliza para determinar el origen de la visita.

• PID: El sistema comprueba primero si hay parámetros propietarios de AppsFlyer.
• Parámetros UTM: Si no existe ningún PID, busca etiquetas estándar como utm_source.
• ID de clic: A continuación, busca ID específicos de la red, como Google Click ID (gclid) o TikTok Click ID (ttclid).
• Referrer: Como último recurso, identifica la URL en la que estaba el usuario inmediatamente antes de llegar.

Para más información, consulta Resolución de la fuente de medios.

Como la mayoría de los usuarios inician sesión en los 30 minutos posteriores a una visita, AppsFlyer retrasa intencionadamente las decisiones de atribución durante ese mismo tiempo. Este retraso evita una clasificación incorrecta como «orgánico», ya que permite al sistema capturar el CUID y vincular correctamente a los usuarios recurrentes con cookies caducadas a su fuente original.

Una vez identificada la fuente y completado el retraso de 30 minutos, el sistema pasa a "stitching" las sesiones fragmentadas del usuario en un único viaje.

• CUID Stitching: Si se captura un Customer User ID (por ejemplo, un correo electrónico con hash), el motor vincula la sesión con el historial entre dispositivos del usuario.
• Respaldo de cookies: Si no hay ningún CUID disponible, el sistema recurre a las cookies del navegador, aunque son menos estables y específicas del dispositivo.

Una vez que se resuelve la identidad del usuario, el motor busca la acción específica que lo define como adquirido. El estándar de la industria es first_visit, pero a menudo esto representa una señal débil: un usuario puede hacer clic en un anuncio por accidente o abandonar inmediatamente. Al configurar un evento de adquisición personalizado, como un registro o una compra, te aseguras de que el valor a largo plazo (LTV) se atribuya a la fuente de marketing que impulsó una acción significativa, y no solo un clic por curiosidad.

Cuando se produce un evento de adquisición de usuarios, el motor de atribución busca hacia atrás durante un periodo igual a la ventana de lookback (adquisición de usuarios) para encontrar una visita no orgánica a la que atribuir. Esta configuración define el tiempo máximo permitido entre la visita de un usuario y la finalización del evento de UA (valor predeterminado: 30 días). Si no se encuentra ningún punto de contacto no orgánico dentro de este periodo de lookback, el evento de UA se considera orgánico y no se atribuye. Puedes configurar la duración de la ventana de lookback del evento personalizado al añadir tu aplicación web a AppsFlyer; consulta Ventana de lookback (adquisición de usuarios).

Según el modelo de negocio, se pueden definir distintos eventos como desencadenante de la adquisición de usuarios, por ejemplo

• Evento de registro completado (p. ej., una aplicación bancaria). El evento de adquisición se activa solo cuando el flujo de registro se completa correctamente.
• Evento del primer pedido (p. ej., una aplicación de reparto de comida). Navegar o añadir artículos no cuenta; el evento se activa solo después de que la transacción se complete correctamente.
• Evento de activación de suscripción (p. ej., una aplicación de streaming o SaaS). El evento de adquisición se registra cuando se confirma la suscripción, no al iniciar la prueba ni con la instalación de la app.

Para obtener más información sobre cómo configurar un evento de adquisición de usuarios, consulta Configuración de adquisición de usuarios.

Después de que el sistema resuelve la identidad del usuario, pero antes de que se considere adquirido, puede haber una brecha en el recorrido llamada periodo previo a la adquisición. Esto solo es relevante si defines un evento de adquisición de usuarios (UA) personalizado en lugar de usar first_visit de forma predeterminada. En este periodo, los usuarios pueden realizar acciones significativas, como añadir artículos al carrito, navegar por productos o interactuar con contenido, antes de completar el evento que oficialmente los adquiere, como el registro o una primera compra.

AppsFlyer recopila y atribuye estos eventos previos a la adquisición a la fuente de marketing y los marca en los reportes como previos a la adquisición. La diferencia clave entre la atribución previa a la adquisición y la posterior a la adquisición es la ventana de atribución. Durante el periodo previo a la adquisición, la ventana de atribución es más corta y coincide con la ventana de lookback del evento de UA, porque estos eventos se producen antes del evento de UA que define al usuario como adquirido. Después de que se activa el evento de UA personalizado y se adquiere al usuario, la ventana de atribución se amplía para medir el valor a largo plazo (LTV), lo que da crédito a largo plazo a la fuente de marketing que adquirió al usuario.

Una vez adquirido un usuario, puede volver al sitio más adelante. Se activa una atribución de re-engagement (revisita) cuando un usuario que regresa hace clic en un anuncio y visita tu sitio.

Aunque el re-engagement se centra en los usuarios existentes, un regreso también puede clasificarse como una readquisición si el usuario ha estado inactivo durante un período prolongado. Para poder optar a la readquisición, el usuario debe primero superar la ventana de inactividad (valor predeterminado: 90 días), que define el período de inactividad necesario para considerarlo «churned». Una vez transcurrida esta ventana, si el usuario regresa, el motor registra un nuevo evento de adquisición de usuarios en lugar de una revisita estándar.

Para obtener más información, consulta Configuración de re-engagement y Configuración de readquisición

Tanto si el usuario llegó a través de una campaña de adquisición inicial como de una acción posterior de retargeting, el objetivo final es medir su valor total a lo largo del tiempo. Una vez que un usuario se atribuye correctamente a una fuente, el sistema mide su actividad continua para calcular el Lifetime Value (LTV).

Esta medición se rige por la ventana de atribución, que está configurada como «Forever» de forma predeterminada. Esto garantiza que cada acción posterior —como compras repetidas o renovaciones de suscripciones— se atribuya a la fuente de marketing original que llevó al usuario al sitio. Al capturar estos datos a largo plazo, puedes ir más allá del simple recuento de conversiones y determinar el verdadero Return on Ad Spend (ROAS) de tus campañas.

Para obtener más información sobre cómo configurar la ventana de atribución, consulta la Ventana de atribución.