S2S Tracking və PostBooks necə işləyir

1) Nə S2S və nə üçün lazımdır

S2S (server-to-server) tracking - browser cookies və kilidlərdən asılı olmayaraq, trafik mənbəyi serverləri (redaktor/tracker/şəbəkə) və operator serverləri (casino) arasında hadisə mübadiləsidir.

Postbek - alıcının URL-sinə göndəricinin arxasından hadisə (reg/KYC/FTD/2nd_dep/...) ilə gedən HTTP sorğusu.

Üstünlüklər:

Adblock/ITP/private rejimlərinə görə məlumatlar itirilmir.
Atributun dəqiqliyi və billinqin keyfiyyəti artır.
Məbləği/valyutanı və xidmət bayraqlarını təhlükəsiz şəkildə ötürə bilərsiniz.

2) Əsas zəncir və rollar

1. Klik: istifadəçi reklamı basır → Sizin baş direktorunuz 'click _ id' yaradır və parametrləri (utm, geo, device, sub_id).

2. Redirect: istifadəçi operatorun açılış səhifəsinə gedir, 'click _ id' URL-ə daxil edilmiş və ya şifrələnmişdir.

3. Qeydiyyat/KOS/depozitlər operator tərəfindən həyata keçirilir.

4. Postbeklər: Operator serveri hadisə trekerinizə 'registration', 'kyc _ approved', 'deposit _ success' və s. göndərir, onları orijinal 'click _ id' ilə əlaqələndirir.

5. BI/Hesabat: Siz CPA/ROAS/LTV sayaraq UTM/yaradıcı/geo/cihaz kəsikləri üzrə hadisələri toplayırsınız.

Mətn sxemi:


Ad → Click → [Direktorunuz: click_id yaradır] → LP/App → (Req/KYC/FTD operator tərəfində)
↑             │
└──────── Postback (S2S) ─┘

3) Hadisə identifikatorları və əlaqəsi

click_id (yük) - unikal birinci toxunuş ID; atributun açarı.

event_id (jelat.) - hər bir hadisənin unikal ID-si (idempotentlik üçün).

user_id/ account_id (ops.) - operator tərəfində oyunçu ID (yalnız S2S-də ötürülür).

session_id (ops.) - UX/sürət təhlili üçün.

aff_sub/campaign/ creative_id - analitika üçün kəsiklər.

Qayda: click_id sizdə yaradılır; operator öz tərəfində mapping 'click _ id user/account' saxlayır.

4) Hadisə sahələri: minimum tərkibi

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

Məcburi sahələr: 'event', 'event _ id', 'click _ id', 'ts _ event' (UTC), 'signature'.

Pul sahələri həmişə 'currency' ilə birlikdə (ISO-4217) və ədədlər kimi, sətir deyil.

5) Təhlükəsizlik: imzalar və giriş

Подпись (HMAC-SHA256): `signature = HMAC(secret, canonical_payload)`; sahələrin qaydasını kanonlaşdırın → sabit yoxlama.

Avtorizasiya səviyyəsində qısa ömürlü tokenlər (JWT/opaque): TTL 5-15 dəqiqə.

İdempotentlik: eyni 'event _ id' ilə təkrar POST dublsuz '200 OK' verməlidir.

IP allow-list və mTLS (mümkünsə) prodda.

Rate limiting: endpoint 'i «burst» və botlardan qoruyun.

Post-end-point ilə HTTP redaktorlarının qadağan edilməsi; yalnız birbaşa cavablar.

6) Etibarlılıq: retralar, növbələr və nizam

Hadisənin qəbulu və hesabatların işlənməsi arasında növbə (Kafka/RabbitMQ/SQS) - zirvələrdə məlumatları itirməmək üçün.

Eksponent fasilə və backoff jitter ilə retrailer; cəhd limiti və DLQ (dead-letter queue).

Sifariş tələb olunmur, lakin BI-də çeşidləmək üçün 'ts _ event' olması məsləhətdir.

Sorğu/cavab qeydləri (həssas məlumatlar olmadan), 'event _ id' ilə korrelyasiya.

7) Müvəqqəti zonalar, valyuta və sabitlik

UTC bütün vaxt işarələri ('2025-10-21T15: 12: 31Z').

Hesabatlarda layihənin timezone göstərin, lakin hadisələri UTC-də saxlayın.

Məbləğləri əməliyyat valyutasında saxlayın və etibarlı məzənnə (data-time-based FX) vasitəsilə hesabat valyutasında təkrarlayın.

8) Dekuplikasiya və biznes qaydaları

event_id idempotentliyi: təkrarlama → «artıq işlənmişdir».

Ehtiyat mexanizmi kimi (click_id + hadisə + ts-pəncərə).

FTD etibarlılıq qaydaları: minimum depozit, bonus «sıfır» doldurma olmadan; müqavilədə qeyd edin.

Chargeback/Refund - dürüst NGR üçün ayrı-ayrı «mənfi gəlir» hadisələri.

9) Məxfilik və uyğunluq

PII-ni URL və cəbhəyə ötürməyin; S2S həssas sahələr üçün bir yerdir.

consent/razılığı (analytics/ads) saxlayın və onları versiya edin.

Sahələri minimuma endirin: yalnız atributlar və billing üçün nə lazımdır.

Mütəmadi olaraq giriş retention siyasətlərini yoxlayın.

10) Web2App və mobil reallıqlar

Tətbiqlər üçün 'click _ id', 'install _ id' MMP/SDK tərəfinə bağlayın.

Müəyyən edilmiş ID (iOS privacy) olmadıqda - ehtimal matçı + server qaydalarından istifadə edin və S2S billing üçün «həqiqət» olaraq qalır.

11) Monitorinq və SLA

Metriklər:

Uğurlu/səhv postbeklər (%/dəq), p95 latency, retrajların payı, dublikatların payı.
Tərəflər arasında hadisələr arasındakı uyğunsuzluq (operator vs tracker) gün ərzində.
Çatdırılma gecikməsi (ingestion lag) və saat üzrə «uğursuzluqlar».

SLA (nümunə):

Postbeklərin qəbulunun mövcudluğu ≥ 99. 5 %/ay.
DWH qeydiyyatına orta gecikmə ≤ 60 san; p95 cavab API ≤ 500 ms.
Data Rascinchron> 3% → 5 iş günü ərzində xam logların məcburi yoxlanılması.

12) Çek vərəqləri

12. 1. Başlamazdan əvvəl tex-check

click_id və log generasiyası ilə baş direktor.
Post-point: TLS, HMAC, JWT, IP allow-list, idempotency.
Payload sxemləri və sahələrin kanonik qaydası sənədləşdirilmişdir.
Növbələr + DLQ, retrajlar, səhvlər/gecikmələr.
UTC-vaxt, ISO-valyuta, FTD/Refund/Chargeback qaydaları.
Referans log fiksasiya ilə sandbox purs.

12. 2. Əməliyyat çeki (hər həftə)

Hadisələrin həcminə və məbləğinə görə «operator tracker» müqayisəsi.
Dublikatların və «itirilmiş» hadisələrin təhlili; retras audit.
Açarların/tokenlərin yoxlanılması, ömrü və rotasiyası.
Hadisə və düzəliş qaydalarına baxın.

13) Tez-tez səhvlər və onlardan necə qaçmaq olar

1. Retralarda idempotency → FTD dublikatı yoxdur. → 'event _ id' daxil edin və «seen» saxlayın.

2. Müxtəlif saat kəmərləri → «üzdü» D0/D1. → Həmişə hadisə jurnalında UTC.

3. Satır məbləğləri/vergül → parsinq səhvləri. → Rəqəmləri nöqtə və ISO valyutası ilə ötürün.

4. «Xam» JSON → imzası açar sırasından qırılır. → Kanonizasiya edin.

5. No DLQ/retrains → mikroskoplar zamanı hadisə itkisi. → Növbə + backoff + alert.

6. Zəif autentifikasiya → saxta postbeklər. → HMAC + JWT + mTLS/IP siyahısı.

7. FTD qaydalarının olmaması → billing mübahisələri. → Müqavilədə tərifləri təsdiqləyin.

14) Sorğu və cavab nümunələri

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


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

Cavab:


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

Eyni 'event _ id' ilə yenidən göndərilir:


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

14. 2. İmza xətası


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

15) Hadisələr və təhlil

Simptom: FTD operatorunda = 120, sizdə - 117.

Plan:

1. Zaman diapazonunun (UTC) və valyutaların müqayisəsi.

2. 'event _ id '/' click _ id' ilə xam logları yükləyin.

3. İmza/TTL token/idempotentlik səbəbiylə rədd edilən axtarış.

4. DLQ-dən «ilişib qalmış» hadisələrin əlavə çatdırılması, yoxlama aktları.

16) 30-60-90 tətbiq planı

0-30 gün - MVP kontur

click _ id 'və log ilə redaktoru işə salın.

Postbeklərin qəbulunu həyata keçirmək: HMAC, JWT, idempotency, növbələr, DLQ, alertlər.

Sandbox qaldırmaq, test məbləğləri ilə reg/FTD uçan script sürmək.

Sxemləri və sahələrin kanonizasiyasını sənədləşdirin.

31-60 gün - Keyfiyyət və miqyas

Pul hadisələrini və iki valyutalı uçotu (txn & report) daxil edin.

p95 latency, uyğunsuzluq və retras monitorinqini konfiqurasiya edin.

SLA/hadisə prosedurları imzalayın; chargeback/refund hadisə əlavə edin.

BI vitrinləri toplamaq üçün: FTD kohorts, Payback, D7/D30 ARPU.

61-90 gün - Dayanıqlılıq və audit

Sirlərin/sertifikatların rotasiyasını, uğursuzluq testlərini daxil edin.

Yükləmə testləri və «təcili təlimlər» (növbə düşməsi/DB).

FTD sxemlərinin/qaydalarının yoxlanılması və rüblük auditini rəsmiləşdirin.

17) Yekun

S2S-trekinq dürüst atributun və billinqin «silsiləsidir»: click_id əsas açar, qorunan postbeklər, idempotentlik, retraj və ciddi vaxt/valyuta gigiyenası kimi. Buna şəffaf FTD etibarlılıq qaydaları, chargeback hadisələri və yetkin monitorinq əlavə edin - və siz etibarlı bir sistem əldə edəcəksiniz, burada hər bir dönüşüm server tərəfindən təsdiqlənir və hesabatlarda bir sentə qədər birləşir.