加密赌场

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事件和成熟的监控-并且您将获得一个可靠的系统，其中每个转换均由服务器确认，并在报告中收敛至分。