Как работает 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. Регистрация/KYC/депозиты происходят у оператора.

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-события и зрелый мониторинг — и вы получите надёжную систему, где каждая конверсия подтверждается сервером и сходится в отчётах до цента.