S2S-трекинг және постбектер қалай жұмыс істейді

1) S2S дегеніміз не және ол не үшін қажет

S2S (server-to-server) трекинг - бұл браузерлік куки мен бұғаттауларға қарамастан, трафик көзінің серверлері (сіздің директорыңыз/трекер/желі) мен оператор серверлері (казино) арасындағы оқиғалармен алмасу.

Постбек - алушының URL мекенжайына жіберушінің бэкендінен оқиғасы (reg/KYC/FTD/2nd_dep/...) бар шығыс HTTP сұрауы.

Артықшылықтары:

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/Есеп: CPA/ROAS/LTV санайтын UTM/creative/geo/device бөлімдері бойынша оқиғаларды біріктіресіз.

Мәтін схемасы:


Ad → Click → [Сіздің директорыңыз: click_id генерациялайды] → LP/App → (Reg/KYC/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 минут.

Ұқсастығы: 'event _ id' бірдей қайталанған POST '200 OK' беруі тиіс.

IP allow-list және mTLS (мүмкіндігінше) сынамада.

Rate limiting: endpoint-ті «бурсттар» мен боттардан қорғаңыз.

Постбэк-эндпойнттан HTTP-редакторларға тыйым салу; тек тікелей жауаптар.

6) Сенімділік: ретра, кезек және тәртіп

Оқиғаны қабылдау мен есепті өңдеу арасындағы кезек (Kafka/RabbitMQ/SQS) - шыңдалған кезде деректерді жоғалтпау үшін.

Экспоненциалды үзілісі және backoff-джиттері бар ретраилер; әрекеттер лимиті және DLQ (dead-letter queue).

Тәртіп міндетті емес, бірақ BI-ге сұрыптау үшін 'ts _ event' болғаны дұрыс.

Сұрау/жауап логтары (сезімтал деректерсіз), 'event _ id' бойынша корреляция.

7) Уақытша аймақтар, валюта және консистенттілік

UTC барлық уақыт белгілері ('2025-10-21T15: 12: 31Z').

Есептерде жобаның timezone бағдарламасын көрсетіңіз, бірақ оқиғаларды UTC бағдарламасында сақтаңыз.

Сомаларды транзакция валютасында сақтаңыз және сенімді бағам (date-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 трекер) тәулік бойынша.
Жеткiзудiң кiдiртiлуi (ingestion lag) және сағаттар бойынша «сәтсiздiктер».

SLA (мысал):

Постбектерді қабылдау қолжетімділігі ≥ 99. 5 %/ай
DWH жазуға дейінгі орташа кідіріс ≤ 60 сек; API жауабының p95 ≤ 500 мс.
Деректердің рассинхроны> 3% → 5 жұмыс күні ішінде шикі логтарды міндетті түрде салыстыру.

12) Чек парақтары

12. 1. Іске қосар алдында техникалық чек

Генерацияланған click_id мен логтары бар бас директор.
Постбектердің эндпойнты: TLS, HMAC, JWT, IP allow-list, idempotency.
Payload's схемалары және өрістердің канондық тәртібі құжатталған.
Кезектер + 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 оқиғаларын және жетілген мониторингін қосыңыз - сонда сіз сенімді жүйені аласыз, онда әрбір конверсия сервермен расталады және бір центке дейінгі есептерде қосылады.