加密賭場

Torrent Gear

S2S跟蹤和後背如何工作

1）什麼是S2S，為什麼需要它

S2S（服務器到服務器）跟蹤是指流量源服務器（您的編輯器/跟蹤器/網絡）與運營商（賭場）服務器之間的事件交換,不依賴於瀏覽器cookie和鎖定。

Postback是從發件人後端到收件人URL的事件（reg/KYC/FTD/2nd_dep/...）的傳出HTTP請求。

優點

數據不會因adblock/ITP/私有模式而丟失。

提高了歸因的準確性和計費質量。

可以安全地傳輸金額/貨幣和服務標誌。

2）基本鏈和角色

1.點擊：用戶點擊廣告→您的編輯器創建「click_id」並編寫參數（utm, geo, device, sub_id)。

2.Redirect：用戶離開操作員的landing，「click_id」被丟棄URL或加密。

3.註冊/KUS/存款來自運營商。

4.後備箱：操作員服務器將事件跟蹤器「註冊」，「kyc_approved」，「deposit_success」等，將其綁定到原始「click_id」。

5.BI/報告：根據CPA/ROAS/LTV，您匯總了UTM/創意/geo/device的事件。

文本方案：


Ad → Click →［您的編輯：生成click_id］ → LP/App →（操作員側面的Reg/KYC/FTD）
↑             │
└──────── Postback (S2S) ─┘

3）事件ID和關系

click_id（*）-第一次接觸的唯一ID；歸因鑰匙。

event_id（希望）是每個事件的唯一ID（用於冪等）。

user_id/ account_id （opz.）-操作員側面的玩家ID（僅傳遞給S2S）。

session_id （opz.）-用於UX/速度解析。

aff_sub/campaign/ creative_id是分析師的切口。

規則：click_id是在你身上創造的；其側面的操作員存儲映射「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」的重復開機自檢必須產生「200 OK」而無需雙打。

銷售中的IP allow-list和mTLS（如果可能）。

Rate limiting：保護endpoint免受「burst」和bots的侵害。

禁止從後後端進行HTTP重定向；只有直接的答案。

6）可靠性： retrai、隊列和順序

在事件接收和報告處理之間排隊（Kafka/RabbitMQ/SQS），以免在峰值時丟失數據。

具有指數級停頓和反向噴射的復古；嘗試限制和DLQ（死信量表）。

該順序不是必需的，但是最好有「ts_event」對BI進行排序。

查詢/響應邏輯（無敏感數據），通過「event_id」進行相關性。

7）臨時區域，貨幣和一致性

UTC中的所有時間標簽（'2025-10-21T15：12：31Z'）。

在報告中,指定項目的時間區,但將事件存儲在UTC中。

以交易貨幣存儲金額,並通過可靠匯率（基於數據的FX）以報告貨幣復制金額。

8）重復數據消除和業務規則

event_id相等性：重復→「已經處理」。

重復數據消除（click_id+事件類型+ts窗口）作為備用機制。

FTD有效性規則：最低存款，無獎金「零」充值；記錄在合同中。

Chargeback/Refund是誠實NGR的單獨的「負收益」事件。

9）隱私和合規性

不要將PII傳輸到URL和正面；S2S是敏感領域的地方。

保存consent/同意（analytics/ads）並進行驗證。

將字段最小化：只需要歸因和計費即可。

定期審核日誌的保留策略。

10）Web2App和移動現實

對於應用程序,在MMP/SDK側鏈接到「click_id」 ↔ 「install_id」。

當沒有確定性ID（iOS隱私）時-使用概率匹配+服務器規則，並且S2S仍然是計費的「真相」。

11）監控和SLA

度量標準：

成功的/有缺陷的後備箱（%/min）, p95 latency, retrais分數,重復分數。
雙方之間的事件差異（操作員vs跟蹤器）每日。
按小時遞送延誤（擠壓lag）和「失敗」。

SLA（示例）：

後衛接待的可用性≥ 99。5%/月。
在DWH中記錄的平均延遲≤ 60秒；API的p95響應≤ 500毫秒。
Rassinchron> 3% →在5個工作日內強制對原始日誌進行核對。

12）支票單

12.1.發射前的電子支票

具有click_id生成和日誌的副主任。
後衛結束點：TLS，HMAC，JWT，IP allow-list，idempotency。
payload's模式和規範字段順序已記錄下來。
隊列+DLQ、轉發、錯誤/延遲差異。
UTC時間、ISO貨幣、FTD/Refund/Chargeback規則。
帶有參考日誌固定的sandbox運行。

12.2.營業支票（每周）

按事件量和金額核對「運營商↔跟蹤器」。
重復和「丟失」事件分析；retrais審核。
驗證密鑰/令牌，壽命和輪換。
查看事件和規則調整。

13）頻繁的錯誤以及如何避免錯誤

1.在撤退時→ FTD雙打不是idempotency。→輸入「event_id」和「seen」存儲。

2.不同的時區→「漂浮」D0/D1。→總是UTC在事件日誌中。

3.字符串和/逗號→解析錯誤。→以點和ISO貨幣傳輸數字。

4.JSON的「原始」簽名→打破鑰匙的順序。→進行規範化。

5.沒有DLQ/轉發 →微戰鬥事件丟失。→隊列+backoff+Alerta。

6.弱身份驗證→偽造的後備箱。→ HMAC+JWT+mTLS/IP表格。

7.缺乏FTD規則→計費爭議。→將定義納入合同。

14）查詢和回復示例

14.1.POST/後退（操作員→跟蹤器）


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，Alertes。

提高sandbox，用測試金額趕走端到端reg/FTD腳本。

記錄場地的方案和規範化。

31-60天-質量和規模

包括現金事件和雙軌計算（txn&report）。

定制p95 latency、差異和回程監控。

簽署SLA/事件程序；添加chargeback/refund事件。

在BI收集店面：FTD、Payback、ARPU D7/D30隊列。

61-90天-可持續性和審計

引入秘密/證書輪換，容錯測試。

進行負載測試和「緊急演習」（隊列掉落/DB）。

正式化花花公子對賬和季度審計FTD計劃/規則。

17）結果

S2S跟蹤是誠實歸屬和計費的「山脊」：click_id作為主鍵，受保護的後備箱，等效性，中繼和嚴格的時間/貨幣衛生。除此之外，還要添加透明的FTD有效性規則，chargeback事件和成熟的監控-並且您將獲得一個可靠的系統，其中每個轉換均由服務器確認，並在報告中收斂至分。