Cómo funciona el seguimiento S2S y la postbeca

1) ¿Qué es S2S y por qué lo necesita?

S2S (server-to-server) el seguimiento es el intercambio de eventos entre los servidores de origen de tráfico (su redirector/rastreador/red) y los servidores del operador (casino), sin depender de cookies de navegador y bloqueos.

Postback: una solicitud HTTP saliente con un evento (reg/KYC/FTD/2nd_dep/...) desde el backend del remitente a la URL del destinatario.

Ventajas:

Los datos no se pierden debido a adblock/ITP/modos privados.
Mejora la precisión de la atribución y la calidad de la facturación.
Puede transferir de forma segura la cantidad/moneda y las banderas de servicio.

2) Cadena básica y roles

1. Clic: el usuario hace clic en el anuncio → su redirector crea 'click _ id' y lógica los parámetros (utm, geo, device, sub_id).

2. Redireccionamiento: el usuario sale al landing del operador, 'click _ id' está volcado en la URL o cifrado.

3. El registro/CUS/depósitos ocurren en el operador.

4. Postbeki: el servidor del operador envía a su rastreador los eventos 'registration', 'kyc _ approved', 'deposit _ success', etc., enlazándolos al' click _ id 'original.

5. BI/Reporting: agregas eventos por cortes UTM/creativo/geo/device, cuenta CPA/ROAS/LTV.

Esquema de texto:


Ad → Click → [Su redirector: genera click_id] → LP/App → (Reg/KYC/FTD en el lado del operador)
↑             │
└──────── Postback (S2S) ─┘

3) Identificadores y asociación de eventos

click_id (obyaz.) - ID único del primer toque; clave de atribución.

event_id (deseado.) - ID única de cada evento (para la idempotencia).

user_id/ account_id (opz.) - ID del jugador en el lado del operador (transferido sólo a S2S).

session_id (opz.) - para desmontajes UX/velocidad.

aff_sub/campaign/ creative_id - cortes para análisis.

Regla: click_id se crea con usted; el operador de su lado almacena el mapping 'click _ id ↔ user/account'.

4) Campos de eventos: composición mínima

4. 1. Registration

json
{
"event": "registration",  "event_id": "reg_8f9...",  "click_id": "clk_123...",  "account_id": "u_456...",  "geo": "BR",  "device": "android",  "ts_event": "2025-10-21T14:54:12Z",  "ip": "203. 0. 113. 7",  "ua": "Mozilla/5. 0",  "signature": "hmac_sha256(payload)"
}

4. 2. KYC Approved

json
{
"event": "kyc_approved",  "event_id": "kyc_b21...",  "click_id": "clk_123...",  "account_id": "u_456...",  "ts_event": "2025-10-21T15:10:05Z",  "kyc_level": "basic    full",  "signature": "..."
}

4. 3. Deposit (FTD/Repeat)

json
{
"event": "deposit_success",  "event_id": "dep_9aa...",  "click_id": "clk_123...",  "account_id": "u_456...",  "amount": 100. 00,  "currency": "USD",  "is_ftd": true,  "payment_method": "card    pix    crypto    wallet",  "ts_event": "2025-10-21T15:12:31Z",  "signature": "..."
}

Campos obligatorios: 'event', 'event _ id', 'click _ id', 'ts _ event' (UTC), 'signature'.

Campos monetarios siempre junto con 'currency' (ISO-4217) y como números, no líneas.

5) Seguridad: firmas y acceso

Подпись (HMAC-SHA256): `signature = HMAC(secret, canonical_payload)`; canonizar el orden de los campos → una verificación estable.

Tokens de vida corta (JWT/opaque) a nivel de autorización: TTL 5-15 minutos.

Idempotencia: un POST repetido con el mismo 'event _ id' debe dar '200 OK' sin toma.

IP allow-list y mTLS (si es posible) en venta.

Rate limiting: protege el endpoint de «bourst» y bots.

Prohibición de redirecciones HTTP desde el punto de vista postbec; sólo respuestas directas.

6) Fiabilidad: retraídas, colas y orden

Cola (Kafka/RabbitMQ/SQS) entre la recepción del evento y el procesamiento de informes - para no perder datos en picos.

Retrés con pausa exponencial y backoff-jitter; límite de intento y DLQ (dead-letter queue).

El orden no es obligatorio, pero es recomendable tener 'ts _ event' para ordenar en BI.

Logs consulta/respuesta (sin datos sensibles), correlación por 'event _ id'.

7) Zonas temporales, moneda y consistencia

Todas las marcas de tiempo en UTC ('2025-10-21T15: 12: 31Z').

En los informes, especifique la timezone del proyecto, pero almacene los eventos en UTC.

Almacene los importes en la divisa de la transacción y duplíquelos en la divisa del informe a través de un tipo de cambio fiable (FX basado en fecha y hora).

8) Desduplicación y reglas de negocio

Idempotencia por event_id: repetición de → «ya procesada».

Deduplicación por (click_id + tipo de evento + ventana ts) como mecanismo de repuesto.

Reglas de validez de FTD: depósito mínimo, sin recargos de bonificación «cero»; fijar en el contrato.

Chargeback/Refund son eventos individuales de «ingresos negativos» para una NGR honesta.

9) Confidencialidad y cumplimiento

No pase PII a la URL y al frente; S2S es un lugar para campos sensibles.

Almacenar consent/consentimiento (analytics/ads) y versionarlos.

Minimice los campos: sólo lo que necesita para la atribución y la facturación.

Revise regularmente las políticas de retention de los registros.

10) Web2App y realidad móvil

Para aplicaciones, asocie 'click _ id' ↔ 'install _ id' en el lado MMP/SDK.

Cuando no hay un ID determinista (privacidad de iOS) - use probabilística + reglas de servidor, y S2S sigue siendo la «verdad» para la facturación.

11) Monitoreo y SLA

Métricas:

Éxito/error postbeki (%/min), p95 latency, porcentaje de retraídas, porcentaje de duplicados.
Divergencia de eventos entre las partes (operador vs rastreador) por días.
Retraso en la entrega (ingestion lag) y «fallas» por hora.

SLA (ejemplo):

Disponibilidad de recepción postback ≥ 99. 5 %/mes.
Latencia media antes de escribir en DWH ≤ 60 segundos; p95 respuesta API ≤ 500 ms.
Rassinchron de datos> 3% → la conciliación obligatoria de registros crudos en el plazo de 5 días laborables.

12) Hojas de cheques

12. 1. T-Check antes de iniciar

Redirector con generación de click_id y guaridas.
Endpoint postback: TLS, HMAC, JWT, IP allow-list, idempotency.
Se han documentado los esquemas de payload y el orden canónico de los campos.
Colas + DLQ, retraídas, alertas por errores/retrasos.
Tiempo UTC, moneda ISO, reglas FTD/Refund/Chargeback.
Correcciones en sandbox con fijación de registros de referencia.

12. 2. Cheque operativo (cada semana)

Conciliar «operador ↔ rastreador» en términos de volumen de eventos y sumas.
Análisis de duplicados y eventos «perdidos»; Auditoría de retiros.
Verificación de claves/tokens, vida útil y rotación.
Ver incidentes y ajustar las reglas.

13) Errores frecuentes y cómo evitarlos

1. No idempotency → tomas de FTD en retrases. → Escriba 'event _ id' y el almacén 'seen'.

2. Diferentes zonas horarias → «navegaron» D0/D1. → Siempre UTC en el registro de eventos.

3. Sumas/comas de cadena → errores de parsing. → Pasar números con punto y moneda ISO.

4. La firma «cruda» JSON → se rompe del orden de las llaves. → Hacer canonización.

5. No hay DLQ/retraídos → pérdida de eventos en microbuses. → cola + backoff + alertas.

6. Autenticación débil → postbecs falsos. → HMAC + JWT + mTLS/hoja IP.

7. La ausencia de reglas de FTD → disputas de facturación → Fije las definiciones en el contrato.

14) Ejemplos de consultas y respuestas

14. 1. POST/postback (operador → rastreador)


POST /postback HTTP/1. 1
Content-Type: application/json
Authorization: Bearer eyJhbGciOi...
X-Signature: sha256=ab12...

{ "event":"deposit_success","event_id":"dep_9aa",  "click_id":"clk_123","account_id":"u_456",  "amount":100. 00,"currency":"USD","is_ftd":true,  "ts_event":"2025-10-21T15:12:31Z" }

Respuesta:


200 OK
{ "status":"ok", "idempotent": false }

Volver a enviar con el mismo 'event _ id':


200 OK
{ "status":"ok", "idempotent": true }

14. 2. Error de firma


403 Forbidden
{ "error":"signature_invalid", "hint":"check canonical order" }

15) Incidentes y desmontes

Síntoma: el operador tiene FTD = 120, usted tiene 117.

Plan:

1. Conciliación del intervalo de tiempo (UTC) y las monedas.

2. Descarga de registros crudos por 'event _ id '/' click _ id'.

3. Búsqueda de token/idempotencia rechazados debido a la firma/TTL.

4. Dopaje de eventos «atascados» del DLQ, actos de conciliación.

16) Plan 30-60-90 de aplicación

0-30 días - contorno MVP

Ejecute el redirector con 'click _ id' y logs.

Realizar la recepción de postbacks: HMAC, JWT, idempotency, colas, DLQ, alertas.

Elevar sandbox, alejar el script de extremo a extremo reg/FTD con sumas de prueba.

Documentar esquemas y canonización de campos.

31-60 días - Calidad y escala

Incluir eventos monetarios y contabilidad de doble cálculo (txn & report).

Configurar el monitoreo p95 latencia, discrepancias y retraídas.

Firmar SLA/procedimientos de incidentes; añadir chargeback/refund eventos.

En BI montar vitrinas: cohortes FTD, Payback, D7/D30 ARPU.

61-90 días - Sostenibilidad y auditoría

Introduzca la rotación de secretos/certificados, pruebas de tolerancia a fallas.

Realizar pruebas de carga y «simulacros de emergencia» (cola caída/DB).

Formalizar las conciliaciones de reproducción y la auditoría trimestral de esquemas/reglas de FTD.

17) Resultado

El seguimiento S2S es una «cresta» de atribución honesta y facturación: click_id como clave primaria, postbeki protegido, idempotencia, retraídas y estricta higiene de tiempo/moneda. Agregue reglas transparentes de validez de FTD, eventos de chargeback y monitoreo maduro, y obtendrá un sistema confiable donde cada conversión es confirmada por el servidor y converge en informes a un centavo.