Як працює S2S-трекінг і постбеки

1) Що таке S2S і навіщо він потрібен

S2S (server-to-server) трекінг - це обмін подіями між серверами джерела трафіку (ваш редиректор/трекер/мережа) і серверами оператора (казино), без залежності від браузерних куки і блокувань.

Постбек - вихідний HTTP-запит з подією (reg/KYC/FTD/2nd_dep/...) з бекенду відправника на URL одержувача.

Переваги:

Дані не втрачаються через adblock/ITP/приватних режимів.
Підвищується точність атрибуції і якість білінгу.
Можна безпечно передавати суму/валюту і службові прапори.

2) Базовий ланцюжок і ролі

1. Клік: користувач натискає на рекламу → ваш редиректор створює'click _ id'і логує параметри (utm, geo, device, sub_id).

2. Редирект: користувач йде на лендінг оператора,'click _ id'прокинутий в URL або зашифрований.

3. Реєстрація/КУС/депозити відбуваються у оператора.

4. Постбеки: сервер оператора відправляє у ваш трекер події'registration','kyc _ approved','deposit _ success'тощо, прив'язуючи їх до вихідного'click _ id'.

5. BI/Звітність: ви агрегуєте події за розрізами UTM/креатив/geo/device, вважаєте CPA/ROAS/LTV.

Текстова схема:


Ad → Click → [Ваш редиректор: генерує click_id] → LP/App → (Рег/КYC/FTD на стороні оператора)
↑             │
└──────── Postback (S2S) ─┘

3) Ідентифікатори та зв'язок подій

click_id (обяз.) - унікальний ID першого дотику; ключ атрибуції.

event_id (желат.) - унікальний ID кожної події (для ідемпотентності).

user_id/ account_id (опц.) - ID гравця на стороні оператора (передається тільки в S2S).

session_id (опц.) - для розборів UX/швидкості.

aff_sub/campaign/ creative_id - розрізи для аналітики.

Правило: click_id створюється у вас; оператор на своїй стороні зберігає мапінг'click _ id ↔ user/account'.

4) Поля подій: Мінімальний склад

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": "..."
}

Обов'язкові поля: `event`, `event_id`, `click_id`, `ts_event` (UTC), `signature`.

Грошові поля завжди разом з'currency'( ISO-4217) і як числа, не рядки.

5) Безпека: підписи та доступ

Підпис (HMAC-SHA256): `signature = HMAC(secret, canonical_payload)`; канонізуйте порядок полів → стабільна перевірка.

Короткоживучі токени (JWT/opaque) на рівні авторизації: TTL 5-15 хвилин.

Ідемпотентність: повторний POST з однаковим'event _ id'повинен давати'200 OK'без дубля.

IP allow-list і mTLS (по можливості) на проді.

Rate limiting: захистіть endpoint від «бурстів» і ботів.

Заборона HTTP-редиректів з постбек-ендпойнту; тільки прямі відповіді.

6) Надійність: ретраї, черги і порядок

Черга (Kafka/RabbitMQ/SQS) між прийомом події і обробкою звітів - щоб не втрачати дані при піках.

Ретраї з експоненціальною паузою і backoff-джиттером; ліміт спроб і DLQ (dead-letter queue).

Порядок не обов'язковий, але бажано мати'ts _ event'для сортування в BI.

Логи запит/відповідь (без чутливих даних), кореляція по'event _ id'.

7) Тимчасові зони, валюта і консистентність

Всі позначки часу в UTC ('2025-10-21T15:12:31Z`).

У звітах вказуйте timezone проекту, але зберігайте події в UTC.

Суми зберігайте у валюті транзакції і дублюйте у валюті звіту через надійний курс (дата-time-based FX).

8) Дедуплікація та бізнес-правила

Ідемпотентність за event_id: повтор → «вже оброблено».

Дедуплікація за (click_id + тип події + ts-вікно) як запасний механізм.

Правила валідності FTD: мінімальний депозит, без бонусних «нульових» поповнень; Фіксуйте в договорі.

Chargeback/Refund - окремі події «негативного доходу» для чесного NGR.

9) Конфіденційність і комплаєнс

Не передавайте PII в URL і фронт; S2S - місце для чутливих полів.

Зберігайте consent/згоди (analytics/ads) і версіонуйте їх.

Мінімізуйте поля: тільки те, що потрібно для атрибуції і білінгу.

Регулярно ревізуйте retention-політики логів.

10) Web2App та мобайл-реалії

Для додатків зв'язуйте'click _ id'↔'install _ id'на стороні MMP/SDK.

Коли немає детермінованого ID (iOS приватність) - використовуйте ймовірнісний матч + серверні правила, а S2S залишається «істиною» для білінгу.

11) Моніторинг та SLA

Метрики:

Успішні/помилкові постбеки (%/хв), p95 latency, частка ретраїв, частка дублікатів.
Розбіжність подій між сторонами (оператор vs трекер) по добі.
Затримка доставки (ingestion lag) і «провали» по годинах.

SLA (приклад):

Доступність прийому постбеків ≥ 99. 5 %/міс.
Середня затримка до запису в DWH ≤ 60 сек; p95 відповіді API ≤ 500 мс.
Розсинхрон даних> 3% → обов'язкова звірка сирих логів протягом 5 робочих днів.

12) Чек-листи

12. 1. Тех-чек перед запуском

Редиректор з генерацією click_id і логами.
Ендпойнт постбеків: TLS, HMAC, JWT, IP allow-list, idempotency.
Схеми payload'ів і канонічний порядок полів задокументовані.
Черги + DLQ, ретраї, алерти помилково/затримки.
UTC-час, ISO-валюта, правила FTD/Refund/Chargeback.
Прогони в sandbox з фіксацією еталонних логів.

12. 2. Операційний чек (щотижня)

Звірка «оператор ↔ трекер» за обсягом подій і сумами.
Аналіз дублікатів і «втрачених» подій; аудит ретраїв.
Перевірка ключів/токенів, термінів життя і ротації.
Перегляд інцидентів і коригування правил.

13) Часті помилки і як їх уникнути

1. Немає idempotency → дублі FTD при ретраях. → Вводьте'event _ id'і сховище «seen».

2. Різні часові пояси → «попливли» D0/D1. → Завжди UTC в журналі подій.

3. Строкові суми/кома → помилки парсингу. → Передавайте числа з точкою і ISO-валюту.

4. Підпис по «сирому» JSON → ламається від порядку ключів. → Робіть канонізацію.

5. Немає DLQ/ретраїв → втрата подій при мікросбоях. → Черга + backoff + алерти.

6. Слабка автентифікація → фальшиві постбеки. → HMAC + JWT + mTLS/IP-лист.

7. Відсутність правил FTD → суперечки щодо білінгу. → Закріпіть визначення в договорі.

14) Приклади запитів і відповідей

14. 1. POST/postback (оператор → трекер)


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

Відповідь:


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

Повторна відправка з тим же'event _ id':


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

14. 2. Помилка підпису


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

15) Інциденти і розбори

Симптом: у оператора FTD = 120, у вас - 117.

План:

1. Звірка діапазону часу (UTC) і валют.

2. Вивантаження сирих логів по'event _ id '/' click _ id'.

3. Пошук відхилених через підпис/TTL токена/ідемпотентності.

4. Допоставка «застряглих» подій з DLQ, акти-звірки.

16) 30-60-90 план впровадження

0-30 днів - MVP контуру

Запустити редиректор з'click _ id'і логами.

Реалізувати прийом постбеків: HMAC, JWT, idempotency, черги, DLQ, алерти.

Підняти sandbox, прогнати наскрізний сценарій reg/FTD з тестовими сумами.

Задокументувати схеми і канонізацію полів.

31-60 днів - Якість і масштаб

Включити грошові події і двовалютний облік (txn & report).

Налаштувати моніторинг p95 latency, розбіжностей і ретраїв.

Підписати SLA/процедури інцидентів; додати chargeback/refund події.

У BI зібрати вітрини: когорти FTD, Payback, D7/D30 ARPU.

61-90 днів - Стійкість і аудит

Ввести ротацію секретів/сертифікатів, тести відмовостійкості.

Провести навантажувальні тести та «аварійні навчання» (випадання черги/БД).

Формалізувати плейбуки звірки і щоквартальний аудит схем/правил FTD.

17) Підсумок

S2S-трекінг - це «хребет» чесної атрибуції та білінгу: click_id як первинний ключ, захищені постбеки, ідемпотентність, ретраї і сувора гігієна часу/валют. Додайте до цього прозорі правила валідності FTD, chargeback-події і зрілий моніторинг - і ви отримаєте надійну систему, де кожна конверсія підтверджується сервером і сходиться в звітах до цента.