How It Works

Como Funciona

Endpoint

POST https://s2s.relo.mx/v1/postback/appsflyer

// Proxied through Cloudflare Worker to:
// https://ingest.relo.mx/postback/appsflyer (Go ingest service)

Authentication

Autenticacion

RELO verifies the HMAC signature sent by AppsFlyer in the X-AF-Signature header. This ensures postbacks are genuinely from AppsFlyer and have not been tampered with.

RELO verifica la firma HMAC enviada por AppsFlyer en el header X-AF-Signature. Esto asegura que los postbacks son genuinos de AppsFlyer y no han sido manipulados.

Payload Format

Formato del Payload

{
  "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
}

How It Works

Como Funciona

Each client in RELO has an attribution_field setting (default: campaign). This determines which event field is read and compared against each partner's attribution rules.

Cada cliente en RELO tiene un campo attribution_field (default: campaign). Esto determina que campo del evento se lee y compara contra las reglas de atribucion de cada partner.

Campaign Name Format

Formato del Nombre de Campana

Partners embed their unique CID (Campaign ID) in the campaign name. RELO extracts the value from the configured field and matches it against each partner's attribution rules.

Los partners insertan su CID (Campaign ID) unico en el nombre de la campana. RELO extrae el valor del campo configurado y lo compara contra las reglas de atribucion de cada partner.

// Campaign name pattern:
mx_{category}_affiliate_relo_{...}_{CID}_{...}

// Example:
mx_pd_affiliate_relo_none_always-on_sub1_banner_none_conversion
                                      ^^^^
                                      Partner CID (e.g., Mobupps = sub1)

Match Types

Tipos de Match

Each partner can have multiple attribution rules, each with a match type. All matching is case-insensitive.

Cada partner puede tener multiples reglas de atribucion, cada una con un tipo de match. Todo el matching es case-insensitive.

Unmatched Events

Eventos Sin Match

Events that do not match any partner's rules are stored with partner_id = NULL. These represent organic sales or non-RELO channels. They are visible in admin dashboards for total market analysis but do not count toward partner commissions.

Los eventos que no hacen match con ninguna regla se almacenan con partner_id = NULL. Representan ventas organicas o canales no-RELO. Son visibles en dashboards de admin para analisis de mercado total pero no cuentan para comisiones de partners.

Revenue Priority (highest to lowest)

Prioridad de Revenue (de mayor a menor)

Product Extraction from Event Value

Extraccion de Productos del Event Value

The Event Value field contains a JSON object with product arrays. RELO parses this to create individual product records in product_sales.

El campo Event Value contiene un objeto JSON con arreglos de productos. RELO parsea esto para crear registros individuales de productos en product_sales.

{
  "af_order_id": "MX260310-12345678",
  "af_content_id": ["SKU-001", "SKU-002"],
  "af_price": [41998.99, 5999.00],         // List prices (NOT revenue)
  "af_quantity": [1, 1],
  "af_currency": "MXN",
  "awin_cg": "Mobile_Smartphone:16984.30|Mobile_Wearable:719.10",
  "items": [
    { "af_content": "Galaxy S24 Ultra", "item_category": "Mobile_Smartphone" },
    { "af_content": "Galaxy Buds3 Pro", "item_category": "Mobile_Wearable" }
  ]
}

// Event Revenue (CSV field): 17703.40
// awin_cg sum: 16984.30 + 719.10 = 17703.40 (matches!)
// Result: use awin_cg values as exact per-product revenue

The Problem

El Problema

When a user is exposed to both a UA campaign and an RT campaign before purchasing, AppsFlyer exports the purchase event in both reports. Without filtering, the same order would be counted twice, potentially attributed to two different partners.

Cuando un usuario esta expuesto a una campana UA y una RT antes de comprar, AppsFlyer exporta el evento de compra en ambos reportes. Sin filtro, la misma orden se contaria dos veces, potencialmente atribuida a dos partners diferentes.

// Same order appears in BOTH reports:

// UA Report (User Acquisition):
Order: MX260310-12345
Campaign: mx_pd_affiliate_relo_..._sub3  // Partner A
Is Primary Attribution: false          // NOT the winner

// RT Report (Retargeting):
Order: MX260310-12345
Campaign: mx_pd_affiliate_relo_..._sub1  // Partner B
Is Primary Attribution: true           // THE WINNER - only this is processed

The Solution

La Solucion

RELO checks the Is Primary Attribution field for every purchase event. Only events where this field is true are processed. This respects AppsFlyer's attribution decision and prevents double-counting.

RELO verifica el campo Is Primary Attribution para cada evento de compra. Solo se procesan los eventos donde este campo es true. Esto respeta la decision de atribucion de AppsFlyer y previene la doble contabilizacion.