Crypto Casino
Torrent Dişli
S2S izleme ve postbacks nasıl çalışır
1) S2S nedir ve neden gereklidir
S2S (sunucudan sunucuya) izleme, trafik kaynağının sunucuları (yönlendiriciniz/izleyiciniz/ağınız) ve operatörün sunucuları (casino) arasında, tarayıcı çerezlerine ve kilitlerine bağımlı olmadan olayların değişimidir.
Postback - gönderenin arka ucundan alıcının URL'sine bir olay (reg/KYC/FTD/2nd_dep/...) içeren giden bir HTTP isteği.
Avantajları:- Veriler adblock/ITP/private modları nedeniyle kaybolmaz.
- Daha yüksek ilişkilendirme doğruluğu ve faturalandırma kalitesi.
- Miktar/para birimi ve hizmet bayraklarını güvenli bir şekilde aktarabilirsiniz.
2) Temel zincir ve roller
1. Tıklayın: Kullanıcı reklamı tıklar - yönlendiriciniz bir 'click _ id' oluşturur ve parametreleri kaydeder (utm, geo, cihaz, sub_id).
2. Yönlendirme: kullanıcı operatörün inişine gider, 'click _ id' URL'ye itilir veya şifrelenir.
3. Kayıt/CCM/depozito operatörde gerçekleşir.
4. Postbacks: Operatörün sunucusu 'registration', 'kyc _ approved', 'deposit _ success' vb. olayları orijinal 'click _ id'ile bağlayarak izleyicinize gönderir.
5. BI/Raporlama: Etkinlikleri UTM/creative/geo/device bölümlerinde toplarsınız, CPA/ROAS/LTV'yi göz önünde bulundurun.
Metin şeması:
Reklam - Tıkla - [Yönlendiriciniz click_id oluşturur] - LP/App
↑ │
└──────── Postback (S2S) ─┘3) Olay tanımlayıcıları ve bağlantı
click_id (zorunlu) - ilk dokunuşun benzersiz kimliği; atıf anahtarı.
event_id (sarı) - her olayın benzersiz kimliği (idempotency için).
user_id/ account_id (toptan satış) - Operatör tarafındaki oyuncu kimliği (yalnızca S2S'ye iletilir).
session_id (toptan) - UX/hızı ayrıştırmak için.
aff_sub/campaign/ creative_id - analitik bölümleri.
Kural: click_id sizin tarafınızdan yaratılır; Yanındaki operatör 'click _ id ↔ user/account' eşlemesini saklar.
4) Olay alanları: minimum kompozisyon
4. 1. Kayıt
Json
{
"event": "registration", " :" "" : " " " :" geo ":" BR "," device ":" android "," "," "," ip ":" 203. 0. 113. 7", "ua": "Mozilla/5. 0", "imza": "hmac_sha256 (yük)"
}4. 2. KYC Onaylandı
Json
{
"event": " " " ": " " " :" "": " " "" "" "" "" "" "" "" "" "" "" "" "" " tam," "imza": ""..
}4. 3. Depozito (FTD/Tekrar)
Json
{
"event": " " " ": " " " ": " " ":" "": "amount": 100. 00, "para birimi": "USD", "is_ftd": true ", payment_method": "kart pix Kripto Cüzdan", " : " " "imza": ".."
}Gerekli alanlar 'event', 'event _ id', 'click _ id', 'ts _ event' (UTC), 'signature'dır.
Para birimi alanları her zaman 'para birimi' (ISO-4217) ile birlikte ve sayı olarak, dizeleri değil.
5) Güvenlik: İmzalar ve erişim
Подпись (HMAC-SHA256): 'imza = HMAC (gizli, canonical_payload)'; Kanonize alan düzeni - kararlı doğrulama.
Yetkilendirme düzeyinde kısa ömürlü jetonlar (JWT/opak): TTL 5-15 dakika.
Idempotence: POST'u aynı 'event _ id'ile tekrarlayın, çift olmadan' 200 OK 'vermelidir.
Prod üzerinde IP allow-list ve mTLS (mümkünse).
Hız sınırlaması: Uç noktayı "patlamalardan've botlardan koruyun.
Postbeck uç noktasından HTTP yönlendirmelerinin yasaklanması; Sadece doğrudan cevaplar.
6) Güvenilirlik: Retrays, kuyruklar ve sipariş
Olay alımı ve rapor işleme arasındaki kuyruk (Kafka/RabbitMQ/SQS) - tepe noktalarında veri kaybetmemek için.
Üstel duraklama ve geri çekilme jitter ile Retrai; Girişimlerin sınırı ve DLQ (dead-letter queue).
Sipariş isteğe bağlıdır, ancak BI'da sıralama için 'ts _ event' olması arzu edilir.
İstek/yanıt günlükleri (hassas veriler olmadan), 'event _ id'ile korelasyon.
7) Zaman dilimleri, para birimi ve tutarlılık
UTC'deki tüm zaman damgaları ('2025-10-21T15: 12: 31Z').
Raporlarda, proje saat dilimini belirtin, ancak olayları UTC'de saklayın.
Tutarları işlem para biriminde saklayın ve güvenilir bir oran (tarih-saat tabanlı FX) aracılığıyla rapor para biriminde çoğaltın.
8) Veri tekilleştirme ve iş kuralları
event_id idempotency: Tekrarla - "zaten işlenmiş".
Geri dönüşüm mekanizması olarak (click_id + olay türü + ts-window) tarafından veri tekilleştirme.
FTD geçerlilik kuralları: minimum depozito, bonus yok "sıfır" ikmal; Sözleşmeyi düzeltin.
Geri Ödeme/Geri Ödeme, dürüst bir NGR için ayrı "negatif gelir" olaylarıdır.
9) Gizlilik ve uyumluluk
PII'yi URL'ye ve öne geçirmeyin; Hassas alanlar için bir yer S2S.
Mağaza onayı (analitik/reklamlar) ve bunları sürüm.
Alanları en aza indirin: yalnızca ilişkilendirme ve faturalandırma için gerekli olanları.
Saklama günlüğü politikalarını düzenli olarak gözden geçirin.
10) Web2App ve mobil gerçeklikler
Uygulamalar için, MMP/SDK tarafında 'click _ id' ↔ 'install _ id' tuşlarını bağlayın.
Deterministik bir kimlik olmadığında (iOS gizliliği) - olasılıksal bir eşleşme + sunucu kuralları kullanın ve S2S faturalandırma için "gerçek'olarak kalır.
11) İzleme ve SLA'lar
Metrikler:- Başarılı/hatalı postbacks (%/min), p95 gecikme, retrays oranı, yinelenen oranı.
- Gün içinde taraflar arasındaki olay tutarsızlığı (operatör vs izleyici).
- Teslimat gecikmesi (yutma gecikmesi) ve saat başı "arızalar".
- Geri alım müsaitliği ≥ 99. %5/ay
- DWH'ye yazmadan önceki ortalama gecikme ≤ 60 saniye; 500ms ≤ p95 API yanıtı.
- Verilerin uyumsuzlaştırılması> %3 - 5 iş günü içinde ham günlüklerin zorunlu mutabakatı.
12) Kontrol listeleri
12. 1. Lansmandan önce teknik kontrol
- click_id nesil ve günlükleri ile yönlendirici.
- Postback uç noktası: TLS, HMAC, JWT, IP izin listesi, idempotency.
- Yük şemaları ve kanonik alan düzeni belgelenmiştir.
- Kuyruklar + DLQs, Retrays, Hata/Gecikme Uyarıları.
- UTC zamanı, ISO para birimi, FTD/Geri Ödeme/Ters ibraz kuralları.
- Referans günlükleri sabitleme ile sandbox çalışır.
12. 2. Çalışma kontrolü (her hafta)
- Olayların ve miktarların hacmi ile "operatör ↔ izleyici" mutabakatı.
- Yinelenen ve "kayıp" olayların analizi; Retrays denetimi.
- Anahtarları/belirteçleri, ömürleri ve rotasyonu kontrol eder.
- Olayları görüntüleyin ve kuralları ayarlayın.
13) Sık yapılan hatalar ve bunlardan nasıl kaçınılacağı
1. Hiçbir idempotency> FTD Retrays'de kopyalanır. - 'event _ id' girin ve "seen" depolayın.
2. Farklı zaman dilimleri - "yüzen" D0/D1. - Olay günlüğünde her zaman UTC.
3. Dize toplamları/virgül - ayrıştırma hataları. - Bir nokta ve ISO para birimi ile sayıları iletin.
4. "Ham" JSON üzerindeki imza, anahtarların sırasından kopar.
5. DLQ/Retrays yok - Mikrosoblardaki olayların kaybı. - Kuyruk + geri alma + Uyarılar.
6. Zayıf kimlik doğrulaması - sahte postbackler. - HMAC + JWT + mTLS/IP listesi.
7. FTD kurallarının eksikliği - faturalandırma anlaşmazlıkları. - Sözleşmedeki tanımları düzeltin.
14) Örnek istekler ve yanıtlar
14. 1. POST/postback (operatör - izleyici)
POST/postback HTTP/1. 1
İçerik Türü: uygulama/json
Yetkilendirme: Taşıyıcı eyJhbGciOi...
X-İmza: 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 TAMAM
{"durum":'tamam "," idempotent ": yanlış}
200 TAMAM
{"durum":'tamam "," idempotent ": doğru}14. 2. İmza hatası
403 Yasak
{"hata ": "signature _ invalid", "ipucu ":" kanonik düzeni kontrol et"}15) Olaylar ve ayrıştırma
Belirti: Operatör FTD = 120, 117 var.
Plan:1. Zaman aralığı (UTC) ve para birimlerinin uzlaştırılması.
2. Ham günlüklerin 'event _ id'/' click _ id'ile boşaltılması.
3. İmza/TTL nedeniyle reddedilen token/idempotency arayın.
4. DLQ'dan "sıkışmış" olayların ek teslimatı, uzlaşma eylemleri.
16) 30-60-90 uygulama planı
0-30 gün - Devre MVP
'Click _ id've günlükleri ile yönlendirme başlatın.
Postbacklerin alınmasını uygulayın: HMAC, JWT, idempotency, kuyruklar, DLQ, uyarılar.
Sanal alanı yükseltin, test miktarlarıyla uçtan uca reg/FTD komut dosyasını çalıştırın.
Belge alanı şemaları ve kanonizasyon.
31-60 gün - Kalite ve ölçek
Parasal olayları ve çift para birimi muhasebesini (txn & report) içerir.
P95 gecikme, tutarsızlıklar ve retrays izleme kurmak.
SLA'ları/olay prosedürlerini imzala; Ters ibraz/geri ödeme etkinlikleri ekleyin.
BI'da vitrinleri toplayın: FTD, Payback D7/D30 ARPU kohortları.
61-90 gün - Sürdürülebilirlik ve denetim
Sırların/sertifikaların rotasyonunu, hata tolerans testlerini girin.
Yük testleri ve "acil durum tatbikatları" (kuyruk düşürme/DB) gerçekleştirin.
Uzlaşma oyun kitaplarını ve FTD şemalarının/kurallarının üç aylık denetimini resmileştirin.
17) Alt satır
S2S izleme, dürüst atıf ve faturalandırmanın "omurgası'dır: Birincil anahtar olarak click_id, korumalı postbacks, idempotency, retrays ve sıkı zaman/para birimi hijyeni. Buna şeffaf FTD geçerlilik kuralları, ters ibraz olayları ve olgun izleme ekleyin - ve her dönüşümün sunucu tarafından onaylandığı ve raporlarda bir sente yakınsadığı güvenilir bir sistem elde edersiniz.