S2S-treking va postbeklar qanday ishlaydi

1) S2S nima va nima uchun kerak

S2S (server-to-server) treking - bu brauzer cookie va blokirovkalariga bog’liq bo’lmagan holda, trafik manbai serverlari (sizning direktoringiz/treker/tarmoq) va operator serverlari (kazino) o’rtasidagi voqealar almashinuvidir.

Postbek - joʻnatuvchining manzilidan oluvchining URL manziliga oʻtadigan hodisa (reg/KYC/FTD/2nd_dep/...) bilan chiqadigan HTTP soʻrovi.

Afzalliklari:

Adblock/ITP/shaxsiy rejimlar tufayli maʼlumotlar yoʻqolmaydi.
Atributning aniqligi va billing sifati oshmoqda.
Pul/valyuta va xizmat bayroqlarini xavfsiz topshirish mumkin.

2) Bazaviy zanjir va rollar

1. Klik: Foydalanuvchi reklamani bosadi → Sizning direktoringiz’click _ id’ni yaratadi va parametrlarni (utm, geo, device, sub_id).

2. Tahririyat: foydalanuvchi operator landingiga oʻtadi,’click _ id’URLga ulangan yoki shifrlangan.

3. Depozitlar operatorda ro’yxatdan o’tkaziladi.

4. Postbeklar: operator serveri sizning trekeringizga’registration’,’kyc _ approved’,’deposit _ success’va boshqalarni yuboradi va ularni asl’click _ id’ga bogʻlaydi.

5. BI/Hisobot: Siz hodisalarni UTM/kreativ/geo/device bo’yicha birlashtirasiz, CPA/ROAS/LTV deb hisoblaysiz.

Matn sxemasi:


Ad → Click → [Sizning direktoringiz: click_id yaratadi] → LP/App → (Reg/KYC/FTD operator tomonida)
↑             │
└──────── Postback (S2S) ─┘

3) Identifikatorlar va voqealar aloqasi

click_id (majburiyat) - birinchi teginishning noyob ID; atributiya kaliti.

event_id (jelat) - har bir hodisaning noyob ID-si (idempotentlik uchun).

user_id/ account_id (ops.) - operator tomonidagi o’yinchining ID-si (faqat S2S ga uzatiladi).

session_id (ops.) - UX/tezlikni tahlil qilish uchun.

aff_sub/campaign/ creative_id - tahlillar uchun kesmalar.

Qoida: click_id sizda yaratilmoqda; operator o’z tomonida mapping’click _ id user/account’ni saqlaydi.

4) Voqealar maydonlari: minimal tarkib

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

Majburiy maydonlar:’event’,’event _ id’,’click _ id’,’ts _ event’(UTC),’signature’.

Pul maydonlari doimo’currency’(ISO-4217) bilan birga va satr sifatida emas.

5) Xavfsizlik: imzolar va kirish

Подпись (HMAC-SHA256): `signature = HMAC(secret, canonical_payload)`; maydonlarning tartibini kanonizatsiya qiling → barqaror tekshirish.

Qisqa yashaydigan tokenlar (JWT/opaque) avtorizatsiya darajasida: TTL 5-15 daqiqa.

Idempotentlik: bir xil’event _ id’bilan takroriy POST’200 OK’ni dublsiz berishi kerak.

IP allow-list va mTLS (iloji boʻlsa) prodda.

Rate limiting: endpointni «burst» va botlardan himoya qiling.

Post-endpoint bilan HTTP-tahririyatlarni taqiqlash; faqat to’g «ridan to’g» ri javoblar.

6) Ishonchlilik: retralar, navbatlar va tartib

(Kafka/RabbitMQ/SQS) voqeani qabul qilish va hisobotlarni qayta ishlash o’rtasidagi navbat.

Eksponensial pauza va backoff-jitter bilan retralar; urinishlar limiti va DLQ (dead-letter queue).

Tartib majburiy emas, lekin BIda saralash uchun’ts _ event’ga ega bo’lish maqsadga muvofiqdir.

So’rov/javob (sezgir ma’lumotlarsiz),’event _ id’bo’yicha korrelyatsiya.

7) Vaqtinchalik zonalar, valyuta va konsistentlik

Barcha vaqt belgilari UTC’da (’2025-10-21T15: 12: 31Z’).

Hisobotlarda loyihaning timezone’ini koʻrsating, lekin voqealarni UTCda saqlang.

Summalarni tranzaksiya valyutasida saqlang va ishonchli kurs (data-time-based FX) orqali hisobot valyutasida takrorlang.

8) De-duplikatsiya va biznes-qoidalar

event_id boʻyicha idempotentlik: takrorlash → «allaqachon qayta ishlangan».

Zaxira mexanizmi sifatida (click_id + hodisa turi + ts-oyna).

FTD validlik qoidalari: minimal depozit, bonusli «nol» qo’shimchalarsiz; shartnomada qayd eting.

Chargeback/Refund - halol NGR uchun alohida «salbiy daromad» hodisalari.

9) Maxfiylik va komplayens

PIIni URL va frontga oʻtkazmang; S2S - sezgir maydonlar uchun joy.

consent/roziliklarni (analytics/ads) saqlang va ularni versiya qiling.

Maydonlarni minimallashtiring: faqat atributlash va billing uchun nima kerak.

Log retention-siyosatini muntazam tekshirib turing.

10) Web2App va mobayl-voqeliklar

Ilovalar uchun MMP/SDK tomonida’click _ id’ ’install _ id’bogʻlang.

Agar aniqlangan ID (iOS maxfiylik) boʻlmasa, ehtimollik + server qoidalaridan foydalaning va S2S billing uchun «haqiqat» boʻlib qoladi.

11) Monitoring va SLA

Metriklar:

Muvaffaqiyatli/xato postbeklar (%/min), p95 latency, retraylar ulushi, dublikatlar ulushi.
Kunlar bo’yicha tomonlar o’rtasidagi tafovut (operator vs treker).
Yetkazib berishning kechikishi (ingestion lag) va soatlar boʻyicha «muvaffaqiyatsizliklar».

SLA (misol):

Postbeklarni qabul qilish imkoniyati ≥ 99. 5 %/oy
DWHga yozilgunga qadar o’rtacha kechikish ≤ 60 sek; API javobining p95 ≤ 500 ms.
Ma’lumotlarni rassinxron qilish> 3% → 5 ish kuni mobaynida xom loglarni majburiy qiyoslash.

12) Chek-varaqlar

12. 1. Ishga tushirishdan oldin

Bosh direktor click_id va loglar ishlab chiqaradi.
Postbeklar endpoint: TLS, HMAC, JWT, IP allow-list, idempotency.
Payload sxemalari va dalalarning kanonik tartibi hujjatlashtirilgan.
Navbatlar + DLQ, retryalar, xato/kechikishlar bo’yicha alertlar.
UTC-vaqt, ISO-valyuta, FTD/Refund/Chargeback qoidalari.
Sandboxda etalon loglarini oʻrnatish.

12. 2. Operatsion chek (har hafta)

Hodisalar hajmi va summalari bo’yicha «operator treker» ni solishtirish.
Dublikatlar va «yo’qolgan» voqealarni tahlil qilish; retray auditi.
Kalitlar/tokenlarni, umr ko’rish va rotatsiya muddatlarini tekshirish.
Hodisalarni koʻrish va qoidalarni tuzatish.

13) Tez - tez xatolar va ulardan qanday qochish mumkin

1. Retrajda idempotency → FTD dubli yoʻq. →’event _ id’va’seen’saqlash joyini kiriting.

2. Turli vaqt mintaqalari suzib ketdi D0/D1.

3. Satr summalari/vergul → parsing xatolari. → Raqamlarni nuqta va ISO valyutasi bilan uzating.

4. «Xom» imzo JSON → kalitlar tartibidan buziladi. → Kanonizatsiya qiling.

5. Hech qanday DLQ/retraj yo’q → mikroskoblar paytida hodisalarni yo’qotish. → Navbat + backoff + alertlar.

6. Zaif autentifikatsiya → soxta postbeklar. → HMAC + JWT + mTLS/IP-varaq.

7. FTD qoidalarining yo’qligi → billing bo’yicha nizolar.

14) So’rovlar va javoblar namunalari

14. 1. POST/postback (operator → treker)


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

Javob:


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

Xuddi shu’event _ id’bilan qayta joʻnatish:


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

14. 2. Imzo xatosi


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

15) Hodisalar va muhokamalar

Simptom: FTD operatorida = 120, sizda - 117.

Reja:

1. Vaqt oralig’ini (UTC) va valyutalarni solishtirish.

2. ’event _ id ’/’ click _ id’ boʻyicha xom loglarni tushirish.

3. Imzo/TTL tufayli rad etilgan tokenni/idempotentlikni qidirish.

4. DLQdan «tiqilib qolgan» voqealarni qo’shimcha yetkazib berish, solishtirish dalolatnomalari.

16) joriy etishning 30-60-90 rejasi

0-30 kun - kontur MVP

Direktorni’click _ id’va log bilan ishga tushirish.

Postbeklarni qabul qilishni amalga oshirish: HMAC, JWT, idempotency, navbatlar, DLQ, alertlar.

Sandboxni yuqoriga ko’tarish, sinov summalari bilan reg/FTD’ni o’tkazib yuborish.

Dalalar sxemalari va kanonizatsiyasini hujjatlashtirish.

31-60 kun - Sifat va masshtab

Pul hodisalari va ikki valyutali hisobni (txn & report) yoqish.

p95 latency, tafovut va retraj monitoringini moslash.

SLA/hodisalar tartib-taomillarini imzolash; chargeback/refund hodisasini qoʻshish.

BIda vitrinalarni yig’ish: FTD kogortlari, Payback, ARPU D7/D30.

61-90 kun - Barqarorlik va audit

Sirlar/sertifikatlar rotatsiyasi, nosozlikka chidamlilik testlari joriy etilsin.

Yuklash testlari va «avariya mashqlari» o’tkazish (navbat/DBning yo’qolishi).

FTD sxemalari/qoidalarining solishtirma pleybuklari va har choraklik auditini rasmiylashtirish.

17) Jami

S2S-treking - bu halol atributlar va billingning «tizmasi»: birlamchi kalit, himoyalangan postbeklar, idempotentlik, retraj va qat’iy vaqt/valyuta gigiyenasi kabi click_id. Bunga shaffof FTD validlik qoidalarini, chargeback tadbirlarini va yetuk monitoringni qo’shing - va siz ishonchli tizimni olasiz, u erda har bir konvertatsiya server tomonidan tasdiqlanadi va hisobotlarda bir sentgacha yig’iladi.