{"user_id":{"customer_user_id":"15667737-366d-4994-ac8b-653fe6b2be4a"},"event_name":"af_purchase","event_revenue":49.99,"event_revenue_currency":"USD","af_customer_event_id": "550e8400-e29b-41d4-a716-446655440000","event_value":{"af_content_id":"SKU-001","af_quantity":2,"custom_parameters":{"promo_code":"SUMMER10"}},"event_url":"https://example.com/checkout/success","timestamp":1712000000000,"ip":"35.244.183.10","user_agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) ...","email_hashed":"a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2"}

{"user_id":{"appsflyer_id":"1234567890abcdef","customer_user_id":"15667737-366d-4994-ac8b-653fe6b2be4a"},"event_url":"https://example.com/products/sneakers","timestamp":1712000000000,"ip":"35.244.183.10","user_agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) ...","http_referrer":"https://www.google.com/","email_hashed":"a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2"}

Una visita incluye los parámetros de atribución de los que depende cada evento posterior, y el sistema espera una visita antes de cualquier evento del usuario. Si envías un evento antes de una visita, el sistema lo clasifica como orgánico.

Como no hay ningún SDK web que configure por ti la cookie afUserId, debes asignarla y gestionarla tú mismo como una cookie HTTP configurada en la cabecera de respuesta Set-Cookie, no como una cookie del lado del cliente escrita en JavaScript.

Por eso es importante: una cookie del lado del cliente (configurada mediante document.cookie) caduca rápidamente, en tan solo 7 días en Safari o 24 horas en dominios bajo ITP. Cuando caduca, el identificador se restablece y un visitante recurrente parece nuevo. Una cookie configurada por tu servidor no está sujeta a ese límite y puede mantenerse hasta el máximo permitido por el navegador (Chrome permite hasta 400 días). También se puede marcar como HttpOnly, por lo que los scripts de la página y los bloqueadores de anuncios no pueden leerla ni eliminarla, y además no depende en absoluto de que se ejecute ningún script en la página.

Para configurarla y leerla:

1. En la primera solicitud de un visitante sin cookie, genera en tu servidor un ID estable y único (por ejemplo, un UUID).

2. Devuélvelo en una cookie propia:

   Set-Cookie: af_web_id=<generated-id>; Max-Age=34128000; Path=/; Secure; HttpOnly; SameSite=Lax

3. En cada solicitud posterior, lee el valor de la cabecera Cookie entrante y reutilízalo. No lo regeneres.
4. Envía ese valor a AppsFlyer en cada llamada como appsflyer_id como parte del objeto user_id de la solicitud.

Puedes ponerle a la cookie el nombre que quieras; AppsFlyer lee el valor que envías, no el nombre de la cookie. Solo asegúrate de configurarla desde tu propio dominio de primera parte.

Cada llamada necesita un objeto user_id con al menos uno de estos identificadores: appsflyer_id (el valor de la cookie) o customer_user_id (tu ID interno de usuario). Enviar ambos, cuando los tengas, mejora la resolución de identidad.

Esto es lo que debes recordar: las visitas son mayoritariamente anónimas, así que envía siempre el valor de la cookie. En los eventos del sitio, añade customer_user_id una vez que se identifique al usuario y sigue enviando la cookie junto con él. En los eventos que no se originan en el navegador, customer_user_id por sí solo es suficiente, siempre que AppsFlyer ya conozca a ese usuario por una sesión identificada anterior.

El objeto user_id es obligatorio en todas las solicitudes. Debes proporcionar al menos uno de los siguientes identificadores.

Los eventos y las visitas deben recibirse como máximo a las 00:30 del siguiente día natural, según la zona horaria de la aplicación. Los eventos tardíos pasan a usar la hora de recepción del servidor.

Todos los campos de datos personales deben estar hashed con SHA256 antes de enviarse. Normaliza el texto (en minúsculas y sin espacios al principio ni al final) antes de aplicar hashing. Cada hash debe tener exactamente 64 caracteres hexadecimales (sin distinguir entre mayúsculas y minúsculas).

• Patrón para todos los campos hashed: ^[a-fA-F0-9]{64}$
• Los números de teléfono que usan el campo phone_number_e164_hashed deben ajustarse al formato E.164 (por ejemplo, +14155552671) antes del hashing.

• El parámetro afUserId es un identificador único que establece el SDK web cuando un usuario visita tu sitio por primera vez.
• Si necesitas afUserId, utiliza uno de los métodos que se indican a continuación.

Obtener el afUserId del encabezado de la cookie HTTP

• El afUserId lo envía el navegador del visitante en las llamadas a tu sitio.
• Extráelo del encabezado de la cookie HTTP si es necesario.

Ver el afUserId en el navegador del visitante

• Visualiza el afUserId en el navegador del visitante para solucionar problemas y depurar.
• Para que esté disponible, el visitante tiene que haber visitado primero una página que tenga el SDK web al menos una vez.
• La cookie que contiene afUserId es una cookie de origen en relación con tu dominio.
• El siguiente procedimiento se preparó con Chrome 81. Puede haber diferencias entre navegadores y sistemas operativos.

Para obtener el afUserId del navegador del visitante:

1. En tu navegador, ve a tu sitio web.
2. Haz clic con el botón derecho y selecciona Inspeccionar. Se abre la ventana de inspección de elementos del navegador.
3. Ve a la pestaña (A) Aplicación.
4. En el menú lateral, (B) expande Cookies.
5. Selecciona tu sitio web. Si no aparece, actualiza el navegador.
6. En el campo (C) filtro, introduce afUserId. Se muestra el valor de afUserID.

AppsFlyer todavía no tiene un destino de Segment predefinido para la API S2S, así que tendrás que configurarlo como un destino personalizado en Segment que envíe cada evento al endpoint de S2S. Hay dos formas de hacerlo, según cuánto control necesites sobre el formato de los datos.

Opción 1: destino de Webhooks (acciones)

Este es el punto de partida recomendado. No requiere código y toda la configuración se hace en la interfaz de usuario de Segment.

Para configurarlo:

1. En Segment, añade el destino de Webhooks desde el catálogo de destinos.
2. Conéctalo a la fuente que recopila los eventos que quieres enviar.
3. Para cada tipo de evento, crea una asignación que defina la URL de AppsFlyer, establezca el método en POST, añada los encabezados obligatorios y genere el payload JSON a partir de los campos del evento.

Opción 2: función de destino

Usa esta opción solo si la asignación de Webhooks no puede generar el formato de payload que necesita AppsFlyer. Una Destination Function es una pequeña función de JavaScript que se ejecuta dentro de Segment, recibe cada evento y lo envía al endpoint de AppsFlyer mediante fetch.

Usa esta opción cuando:

• El payload necesita una estructura anidada, por ejemplo, envolver user_id dentro de un objeto user, que la interfaz de usuario de asignación de Webhooks no puede generar.
• Los datos del evento deben transformarse antes de enviarse, por ejemplo, convirtiendo una timestamp a un formato diferente.

Independientemente de la configuración que uses, apúntala a este endpoint:

POST https://events.appsflyer.com/v2.0/s2s/inapps/app/web/website-{your_domain}

Authorization: Bearer {s2s-token}
Content-Type: application/json

Obtén tu clave de la API S2S en la página de gestión de tokens de AppsFlyer (consulta Autenticación). En la ruta, usa el ID de la app web (por ejemplo, website-www.your_domain), no el UUID del Web SDK ID en la página de configuración de la app.

Crea el cuerpo JSON de cada evento asignado con estos campos:

{
  "user_id": {
    "customer_user_id": "<tu ID de usuario interno>",
    "appsflyer_id": "<valor de la cookie afUserId, cuando esté disponible>"
  },
  "event_name": "signup",
  "event_url": "<URL de la página donde se produjo el evento>",
  "ip": "<IP del usuario final>",
  "user_agent": "<user agent del usuario final>",
  "af_customer_event_id": "<messageId de Segment>"
}

1. Mantén el SDK web en funcionamiento en el sitio de marketing: registra las visitas y Segment gestiona los eventos. Como se explica en la introducción de esta sección, un usuario necesita una visita antes de un evento; de lo contrario, el evento se atribuye como orgánico. Si en su lugar quieres una configuración totalmente del lado del servidor, sin ningún SDK web, sigue Configura una integración totalmente del lado del servidor.
2. Cada llamada también necesita los identificadores correctos: envía la misma combinación de appsflyer_id o customer_user_id descrita en Envía los identificadores correctos en cada llamada.

Cuando el destino y el payload estén listos, sigue estos tres pasos:

1. Asigna uno o dos eventos en Segment (el evento de registro es una buena primera opción) y envía un evento de prueba desde el probador de asignaciones.
2. Verifica que lleguen correctamente al reporte sin procesar y que coincidan con la visita al sitio de marketing.
3. Cuando lo hayas confirmado, amplía la asignación al resto de los eventos.

Cuando el destino y el payload estén listos, sigue estos tres pasos:

1. Asigna uno o dos eventos en Segment (el evento de registro es una buena primera opción) y envía un evento de prueba desde el probador de asignaciones.
2. Verifica que lleguen correctamente al reporte sin procesar y que coincidan con la visita al sitio de marketing.
3. Cuando lo hayas confirmado, amplía la asignación al resto de los eventos.