AppsFlyer
Cómo Relo recibe datos de AppsFlyer — Pull API, S2S postbacks, atribución y mapeo de campos.
Relo recibe datos de AppsFlyer por dos caminos. Ambos alimentan el mismo servicio de ingesta en Go, que escribe eventos en ClickHouse para análisis y sincroniza agregados a Supabase para el dashboard.
Pull API
Método recomendado. El servicio Go consulta AppsFlyer cada 60 minutos. Sin configuración extra del lado de AppsFlyer.
S2S Postback
Postbacks en tiempo real desde AppsFlyer a s2s.relo.mx. Menor latencia, pero requiere configuración por media source.
Flujo de datos
Flujo de atribución primaria
Pull API
El servicio Go ejecuta un timer de systemd que consulta la Pull API de AppsFlyer cada 60 minutos. Obtiene installs y eventos in-app (compras, add-to-cart, registros, etc.).
| Aspecto | Detalle |
|---|---|
| Frecuencia | Cada 60 minutos |
| Alcance | Installs y eventos in-app |
| Deduplicación | Por event_id (ULID) |
| Atribución | Solo eventos con Is Primary Attribution = true |
| Requisitos | App ID y API Token configurados en Relo |
Re-consultar la misma ventana de tiempo es seguro. Los eventos típicamente aparecen en el dashboard de Relo dentro de 60-120 minutos.
Cada 60 min: UA purchases + RT purchases (eventos af_purchase)
Diario 4 AM MX: Installs + eventos de fraude (una vez al día)
Notas:
- Se procesan tanto UA como Retargeting.
- Filtro crítico: solo eventos donde Is Primary Attribution = true.Después de cada pull, el sistema revisa:
- Media sources bloqueadas — redes conocidas de fraude.
- Reciclaje de dispositivos — mismo
appsflyer_iden múltiples partners. - Picos horarios — concentración anormal de eventos.
- Patrones uniformes — timing sospechosamente regular entre eventos.
Los resultados se guardan en ClickHouse y se muestran en el dashboard de admin.
S2S Postback
POST https://s2s.relo.mx/v1/postback/appsflyerProxeado por Cloudflare Worker al servicio Go en ingest.relo.mx/postback/appsflyer.
Relo verifica la firma HMAC que AppsFlyer envía en el header X-AF-Signature. Esto asegura que los postbacks son genuinos y no han sido manipulados.
{
"event_name": "af_purchase",
"event_time": "2026-03-10 14:30:00.000",
"appsflyer_id": "1709654321000-1234567",
"media_source": "affiliate_relo",
"campaign": "mx_pd_affiliate_relo_none_always-on_sub1",
"adset": "banner_none",
"ad": "SAM-MX-A1B2C3",
"event_revenue": 17703.40,
"event_revenue_currency": "MXN",
"event_value": "{\"af_order_id\":\"MX260310-12345\",...}",
"country_code": "MX",
"city": "Ciudad de Mexico",
"device_model": "SM-S928B",
"is_primary_attribution": true,
"is_retargeting": false
}Mapeo de eventos
| Evento AppsFlyer | Evento Relo | Descripción |
|---|---|---|
install | install | Instalación de app. Usado para identity graph y funnel. |
af_purchase | purchase | Conversión principal. Contiene order ID, productos y revenue. |
af_add_to_cart | engagement | Adición al carrito. Para retargeting y funnels. |
af_complete_registration | custom | Registro. Para métricas de calidad de partner. |
| Otros eventos | custom | Nombre original preservado en event_name. |
Todos los eventos se ingieren en ClickHouse, pero solo af_purchase se parsean en registros individuales de product_sales. Esos son los datos usados para comisiones y dashboards.
Prioridad de revenue
Relo extrae el revenue por producto de los eventos de compra en este orden:
| Prioridad | Fuente | Descripción |
|---|---|---|
| 1 | awin_cg | Desglose por producto. Formato Categoría:Monto|Categoría:Monto. Se usa cuando la suma coincide con Event Revenue. |
| 2 | Event Revenue | Revenue total real de la orden. Distribuido proporcionalmente por af_price. |
| 3 | af_price | Precio de lista. Último recurso cuando faltan las dos anteriores. |
Nunca uses af_price como revenue real. Es el precio de lista antes de descuentos y puede inflar el revenue 40-60%.
Atribución primaria
AppsFlyer puede reportar la misma compra tanto en datos UA como de Retargeting. Relo solo procesa el evento que AppsFlyer designa como primario.
UA Report:
Order: MX260310-12345
Is Primary Attribution: false → se ignora
RT Report:
Order: MX260310-12345
Is Primary Attribution: true → se procesaAdemás del filtro de atribución primaria, Relo deduplica por sale_hash (SHA-256 de order_id + product_id + quantity). Aunque el mismo evento llegue por Pull API y S2S, solo se registra una vez.
Mapeo de campos
| Campo AppsFlyer | Campo Relo | Notas |
|---|---|---|
Event Name | event_name | Preservado tal cual. Determina event_type. |
Event Time | event_time | DateTime64 con precisión de ms. |
AppsFlyer ID | device_id | Mapeado a ID unificado vía identity graph. |
Media Source | media_source | Fuente de tráfico. |
Campaign | campaign | Nombre de campaña con CID del partner. |
Adset | adset | Ad set / ad group. |
Ad | ad | Creativo. Puede contener asset tracking ID. |
Event Revenue | revenue | Revenue por producto vía awin_cg o proporcional. |
Event Value → af_order_id | order_id | Extraído del JSON. |
Event Value → af_content_id | product_id | SKU del producto. Una fila por producto. |
Event Value → items[].af_content | product_name | Nombre de display. |
Event Value → af_quantity | quantity | Cantidad por producto. |
Country Code | country_code | ISO 3166-1 alpha-2. |
City | city | Nombre de ciudad. |
Device Model | device_model | Ej. SM-S928B. |
Is Retargeting | UA/RT flag | Determina User Acquisition vs Retargeting. |
Is Primary Attribution | filtro | Eventos false se omiten completamente. |
Solución de problemas
| Problema | Causa probable | Solución |
|---|---|---|
| No aparecen eventos | App ID o API Token no configurados o expirados | Verifica credenciales y salud del backbone en ingest.relo.mx/health. |
| Ventas no atribuidas | Campaña sin CID del partner o reglas mal configuradas | Revisa reglas de atribución y formato de campaña. |
| Revenue muy alto | Se está usando af_price en lugar de Event Revenue | Relo lo maneja automáticamente; si persiste, contacta soporte. |
| Eventos duplicados | Mismo evento por ambos canales | Relo deduplica por sale_hash. Revisa la pestaña Audit. |
| Partner incorrecto | Reglas superpuestas (ej. sub1 con contains matchea sub10) | Cambia a match exact para CIDs que colisionen. |
| Eventos retrasados | Pull API normal (60 min) | Si necesitas casi-tiempo-real, configura S2S como complemento. |
| S2S rechazado (401) | Firma HMAC no coincide | Verifica que el secreto en AppsFlyer coincida con el de Relo. |
| Productos en segmento incorrecto | Nombre/categoría no coincide con reglas | Revisa y ajusta reglas de clasificación de segmentos. |
¿Necesitas ayuda? Contacta a tu account manager o al equipo de ingeniería. Para diagnósticos en tiempo real, usa el dashboard de admin en portal.relo.mx → pestaña Audit.