Crypto Casino
Bieg torrent
Jak działa śledzenie S2S i plecy pocztowe
1) Co jest S2S i dlaczego jest potrzebne
S2S (serwer-serwer) śledzenie jest wymianą zdarzeń między serwerami źródła ruchu (Twój przekierownik/tracker/sieć) a serwerami operatora (kasyno), bez zależności od plików cookie i blokad przeglądarki.
Postback - wychodzące żądanie HTTP z zdarzeniem (reg/KYC/FTD/2nd_dep/...) z backendu nadawcy do adresu URL odbiorcy.
Zalety:- Dane nie są tracone ze względu na tryby adblock/ITP/prywatne.
- Wyższa dokładność przypisywania i jakość rozliczeń.
- Możesz bezpiecznie przelać kwotę/walutę i flagi serwisowe.
2) Podstawowy łańcuch i role
1. Kliknij: użytkownik klika na reklamę → przekierowanie tworzy 'click _ id' i rejestruje parametry (utm, geo, urządzenie, sub_id).
2. Przekierowanie: użytkownik przechodzi do lądowania operatora, 'click _ id' jest pchany do adresu URL lub szyfrowany.
3. Rejestracja/CCM/depozyty występują w operatorze.
4. Postbacks: serwer operatora wysyła 'rejestrację', 'kyc _ approved', 'deposit _ success' itp. zdarzenia do Twojego trackera, wiążąc je z oryginalnym 'click _ id'.
5. BI/Reporting: można agregować wydarzenia w sekcji UTM/creative/geo/device, rozważyć CPA/ROAS/LTV.
Program tekstowy:
Ad → Kliknij → [Przekierowanie generuje click_id] → LP/App →
↑ │
└──────── Postback (S2S) ─┘3) Identyfikatory zdarzeń i powiązania
click_id (obowiązkowe) - niepowtarzalny identyfikator pierwszego dotyku; klucz przypisania.
event_id (żółty) - niepowtarzalny identyfikator każdego zdarzenia (dla idempotencji).
user_id/ account_id (hurtownia) - identyfikator gracza po stronie operatora (przesyłany tylko do systemu S2S).
session_id (hurtownia) - do parsowania UX/prędkość.
aff_sub/campaign/ creative_id - sekcje analityczne.
Zasada: click_id jest przez Ciebie stworzony; operator po swojej stronie przechowuje mapowanie 'click _ id na użytkowniku/koncie'.
4) Pola wydarzeń: minimalny skład
4. 1. Rejestracja
json
{
"wydarzenie": "rejestracja", " " " " " " "geo": "BR", "urządzenie": "android", " " "ip": "203. 0. 113. 7”, „ua”: „Mozilla/5. 0", "podpis": "hmac_sha256 (ładunek użytkowy)"
}4. 2. Zatwierdzony przez KYC
json
{
„event”: „ ” : „ ” : „ ” : „ ”: „ :” pełny", "podpis": ".."
}4. 3. Depozyt (FTD/powtórzyć)
json
{
"wydarzenie": " " : " " : " " "" kwota ": 100. 00, "waluta": "USD", "is_ftd": true ", payment_method": "karta Pix krypta portfel”, „ts_event": „2025-10-21T15:12:31Z,” „podpis”: „..”
}Wymagane pola to 'event', 'event _ id',' click _ id', 'ts _ event' (UTC), 'signature'.
Pola walutowe są zawsze razem z 'currency' (ISO-4217) i jako liczby, a nie łańcuchy.
5) Bezpieczeństwo: podpisy i dostęp
Бодбиса (HMAC-SHA256): „podpis = HMAC (secret, canonical_payload)”; kanonizacja zamówienia pola → stabilna walidacja.
Żetony krótkotrwałe (JWT/nieprzezroczyste) na poziomie autoryzacji: TTL 5-15 minut.
Idempotence: Powtórz POST z tym samym 'event _ id', który powinien uzyskać' 200 OK 'bez podwójnego.
IP permit-list i mTLS (jeśli to możliwe) na prod.
Ograniczenie stawki: Chroń punkt końcowy przed „wybuchami” i botami.
Zakaz przekierowywania HTTP z punktu końcowego punktu pocztowego; Tylko bezpośrednie odpowiedzi.
6) Niezawodność: Przekłady, kolejki i porządek
Kolejka (Kafka/RabbitMQ/SQS) między odbiorem zdarzeń a przetwarzaniem raportów - aby nie tracić danych w szczytach.
Retrai z wykładniczą przerwą i backoff jitter; limit prób i DLQ (kolejka martwych liter).
Zamówienie jest opcjonalne, ale pożądane jest posiadanie 'ts _ event' do sortowania w BI.
Dzienniki żądania/odpowiedzi (bez danych wrażliwych), korelacja przez 'event _ id'.
7) Strefy czasowe, waluta i spójność
Wszystkie znaczki czasowe w UTC ('2025-10-21T15: 12: 31Z').
W raportach należy określić harmonogram projektu, ale przechowywać zdarzenia w UTC.
Zapisz kwoty w walucie transakcji i duplikuj je w walucie raportu za pomocą wiarygodnego kursu (data-time-based FX).
8) Zasady deduplikowania i prowadzenia działalności gospodarczej
event_id idempotencja: Powtórz → „już przetworzone”.
Deduplikacja przez (typ zdarzenia click_id + + okno ts) jako mechanizm awaryjny.
Zasady ważności FTD: minimalny depozyt, bez bonusu „zero” uzupełnienie; Napraw kontrakt.
Obciążenie zwrotne/zwrot to odrębne zdarzenia „ujemne” dla uczciwego NGR.
9) Poufność i zgodność
Nie należy przekazywać PII do adresu URL i z przodu; S2S to miejsce dla wrażliwych pól.
Przechowywać zgodę (analityka/reklamy) i ich wersję.
Zminimalizuj pola: tylko to, co jest potrzebne do przypisania i rozliczeń.
Regularne przeglądanie polityki dziennika zatrzymywania.
10) realia Web2App i ruchome
W przypadku aplikacji po stronie MMP/SDK należy powiązać 'click _ id' z' install _ id'.
Gdy nie ma deterministycznego identyfikatora (prywatność iOS) - użyj probabilistycznego dopasowania + reguły serwera, a S2S pozostaje „prawdą” dla rozliczeń.
11) Monitorowanie i SLA
Metryka:- Udane/błędne postbaki (%/min), opóźnienie p95, odsetek przekładni, odsetek duplikatów.
- Rozbieżność zdarzeń między stronami (operator vs tracker) w ciągu dnia.
- Opóźnienie dostawy (połknięcie opóźnione) i „awarie” o godzinę.
- Dostępność recepcji po powrocie ≥ 99. 5 %/miesiąc
- średnie opóźnienie przed zapisem do DWH ≤ 60 sekund; Odpowiedź p95 API ≤ 500 ms.
- Desynchronizacja danych> 3% → obowiązkowe uzgodnienie dzienników surowych w ciągu 5 dni roboczych.
12) Listy kontrolne
12. 1. Kontrola techniczna przed uruchomieniem
- Przekierowywanie z generacją click_id i dziennikami.
- Punkt końcowy postback: TLS, HMAC, JWT, IP permit-list, idempotence.
- Systemy ładunku i kanoniczne porządki w terenie są udokumentowane.
- Kolejki + DLQ, Przekaźniki, Błędy/Opóźnienia Alerty.
- Czas UTC, waluta ISO, zasady FTD/zwrot/obciążenie zwrotne.
- Działa w piaskownicy z mocowaniem dzienników referencyjnych.
12. 2. Kontrola operacyjna (co tydzień)
- Uzgodnienie „trackera operatora” z wolumenem zdarzeń i kwot.
- Analiza duplikatów i „straconych” zdarzeń; audyt przekładni.
- Sprawdza klucze/żetony, żywotność i rotację.
- Zobacz incydenty i dostosuj zasady.
13) Częste błędy i jak ich uniknąć
1. Brak idempotencji → duplikaty FTD w Retrays. → Wprowadź 'event _ id' i przechowuj „widziane”.
2. Różne strefy czasowe → „pływały” D0/D1. → Zawsze UTC w dzienniku zdarzeń.
3. Sumy smyczkowe/przecinek → błędy parsingowe. → Podaj numery z okresem i walutą ISO.
4. Podpis na „surowy” JSON → łamie się z kolejności kluczy. → Zrobić kanonizację.
5. Brak DLQ/Retrays → Utrata zdarzeń na mikrosobach. → Kolejka + backoff + Alerts.
6. Słabe uwierzytelnianie → fałszywe postbacks. → Lista HMAC + JWT + mTLS/IP.
7. Brak zasad FTD → spory rozliczeniowe. → Ustalić definicje w umowie.
14) Przykładowe wnioski i odpowiedzi
14. 1. POST/postback (operator → tracker)
HTTP/1 POST/postback. 1
Typ treści: aplikacja/json
Autoryzacja: Bearer eyJhbGciOi...
Podpis X: sha256 = ab12...
{"event": "deposit _ success", "event _ id':" dep _ 9aa "," click_id":"clk_123,""account_id":"u_456, "" kwota ": 100. 00, „waluta „: „USD”,” is _ ftd”: true, „ts_event":"2025-10-21T15:12:31Z”}
200 OK
{„status”:” ok”, „idempotent”: false}
200 OK
{„status”:” ok”, „idempotent”: true}14. 2. Błąd w podpisie
403 Zakazane
{„błąd „: „signature _ invalid”, „hint „:” check canonical order”}15) Incydenty i sparaliżowanie
Objaw: operator ma FTD = 120, masz 117.
Plan:1. Uzgodnienie zakresu czasu (UTC) i walut.
2. Rozładunek dzienników surowych przez 'event _ id'/' click _ id'.
3. Wyszukiwanie odrzuconego tokena/idempotencji ze względu na podpis/TTL.
4. Dodatkowe dostawy „utknął” wydarzenia z DLQ, akty pojednania.
16) 30-60-90 plan realizacji
0-30 dni - obwód MVP
Uruchom przekierowanie za pomocą 'click _ id' i dzienników.
Wdrożyć odbiór postbacks: HMAC, JWT, idempotencja, kolejki, DLQ, alerty.
Podnieś piaskownicę, uruchom skryptu end-to-end reg/FTD z ilościami testowymi.
Schematy i kanonizacja pól dokumentów.
31-60 dni - Jakość i skala
Uwzględnij zdarzenia pieniężne i rachunkowość w walucie podwójnej (txn & report).
Ustawić monitorowanie opóźnień, rozbieżności i przekładni p95.
Podpisać SLA/procedury incydentów; dodać zdarzenia związane z obciążeniem zwrotnym/zwrotem.
W BI zbieraj prezentacje: FTD, Payback, D7/D30 kohorty ARPU.
61-90 dni - Zrównoważony rozwój i audyt
Wprowadź rotację tajemnic/certyfikatów, testy tolerancji błędów.
Wykonaj badania obciążenia i „wiertła awaryjne” (drop/DB kolejki).
Sformalizować playbooks pojednania i kwartalny audyt systemów/zasad FTD.
17) Sedno sprawy
Śledzenie S2S jest „kręgosłupem” uczciwego przypisywania i rozliczania: click_id jako klucz podstawowy, chronione postbaki, idempotencja, przekaźniki i ścisła higiena czasu/waluty. Dodaj do tego przejrzystych zasad ważności FTD, zdarzeń obciążeń zwrotnych i dojrzałego monitorowania - i otrzymasz niezawodny system, w którym każda konwersja jest potwierdzona przez serwer i zbiega się w raportach do centa.