S2S-трекинг жана пост-бекеттер кантип иштейт

1) Бул эмне S2S жана эмне үчүн керек

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

Postbek - алуучунун URL жөнөтүүчүнүн бэкендинен окуя (reg/KYC/FTD/2nd_dep/...) менен чыккан HTTP-суроо.

Артыкчылыктары:

Маалыматтар улам adblock/ITP/жеке режимде жоголгон эмес.
Атрибуциянын тактыгы жана биллингдин сапаты жогорулайт.
Сиз сумманы/валютаны жана кызматтык желектерди коопсуз өткөрүп бере аласыз.

2) Негизги чынжыр жана ролдору

1. Click: колдонуучу жарнаманы басат → Сиздин редакторуңуз '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/чыгармачылык/geo/device кесүү боюнча окуяларды бириктирип.

Текст схемасы:


Ad → Click → [Сиздин редактору: click_id жаратат] → LP/App → (Reg/CYC/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 сизде түзүлөт; оператор өз тарабында mapping '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-jitter менен Retray; аракет жана DLQ чеги (dead-letter queue).

Тартип милдеттүү эмес, бирок BI сорттоо үчүн 'ts _ event' болушу абзел.

Логи суроо/жооп (сезимтал маалыматтар жок), 'event _ id' боюнча корреляция.

7) Убактылуу зоналар, валюта жана консистенттүүлүк

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

Отчеттордо долбоордун timezone көрсөтүңүз, бирок окуяларды UTCде сактаңыз.

Суммаларды транзакция валютасында сактаңыз жана ишенимдүү курс (data-time-based FX) аркылуу отчет валютасында кайталаңыз.

8) Дедупликация жана бизнес эрежелери

event_id боюнча окшоштук: кайталоо → "буга чейин иштелип чыккан".

(click_id + окуя түрү + ts-терезе) боюнча Дедупликация запастык механизм катары.

FTD валиддүүлүк эрежелери: минималдуу депозит, бонустук "нөл" толуктоолорсуз; келишимде белгиленген.

Chargeback/Refund - чынчыл NGR үчүн "терс киреше" өзүнчө окуялар.

9) Купуялык жана комплаенс

PIIди URL жана фронтко өткөрбөө; S2S - сезимтал талаалар үчүн жер.

consent/макулдуктарды (analytics/ads) сактоо жана аларды чыгаруу.

Талааларды минималдаштыруу: атрибуция жана биллинг үчүн гана керек.

Логдордун retention-саясатын такай текшерип туруңуз.

10) Web2App жана мобайл-реалдуулуктар

Тиркемелер үчүн MMP/SDK тарабында 'click _ id' 'install _ id' байланышыңыз.

Детерминацияланган ID (iOS купуялыгы) жок болгондо - ыктымалдык матчын + сервердик эрежелерди колдонуңуз, ал эми S2S биллинг үчүн "чындык" бойдон калууда.

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

Метрикасы:

Ийгиликтүү/ката пост бекеттери (%/мин), p95 latency, ретрациялардын үлүшү, дубликаттардын үлүшү.
Тараптардын ортосундагы окуялардын айырмачылыгы (оператор vs трекер) күн сайын.
Жеткирүү кечигүү (ingestion lag) жана "ийгиликсиздик" саат.

SLA (мисал):

Постбектерди кабыл алуу мүмкүнчүлүгү ≥ 99. 5 %/ай.
DWH жазууга орточо кечигүү ≤ 60 сек; p95 жооп API ≤ 500 ms.
Data Rassinchron> 3% → 5 жумушчу күндүн ичинде чийки блогдорду милдеттүү текшерүү.

12) Чек-баракчалар

12. 1. Техникалык чек башталганга чейин

Генерация жана click_id менен директору.
Postbekov Endpoint: TLS, HMAC, JWT, IP allow-list, idempotency.
Схемалар жана канондук талаа тартиби документтештирилген.
кезек + DLQ, retrailer, каталар/кечигүүлөр боюнча алерттерди.
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/retrains → микросхемалардын учурунда окуяларды жоготуу. → Кезек + backoff + алерт.

6. алсыз аутентификация → жасалма postbekov. → 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 мониторинг орнотуу, айырмачылыктар жана retrains.

SLA/инцидент жол-жоболоруна кол коюу; chargeback/refund окуялар кошуу.

BI дүкөндөрүндө чогултуу: FTD, Payback, D7/D30 ARPU.

61-90 күн - Туруктуулук жана аудит

Сырлардын/сертификаттардын ротациясын, ийгиликсиздикке туруктуулук тесттерин киргизүү.

Жүктөө тесттерин жана "авариялык машыгууларды" өткөрүү (кезек күтүүлөр/DD).

FTD схемаларынын/эрежелеринин плейбуктарын жана чейректик аудитин формалдаштыруу.

17) Жыйынтык

S2S-трекинг чынчыл атрибуциянын жана биллингдин "кыры" болуп саналат: click_id негизги ачкыч катары, корголгон постбектер, демпотенттик, ретра жана катуу убакыт/валюта гигиенасы. Бул FTD, chargeback-окуялар жана жетилген мониторинг боюнча ачык-айкын эрежелерди кошуу - Сиз ар бир которуу Server тарабынан тастыкталган жана бир центке чейин отчетторду бириктирип турган ишенимдүү системаны аласыз.