S2S 交付与上线
受众： 负责上线的人——通常是广告主的 UA 经理，测试时需要开发人员在场。
集成校验证明你的 payload 是正确的。本页证明你的产品确实在发送它们，并把集成交付给客户经理，让广告系列可以基于它开始优化。
交付之前
- 集成校验中每一条必需规则都通过（
S2S-R-01…S2S-R-17） - 建议规则也通过，或者你已书面记下跳过了哪些、以及为什么
- 你的产品已开通 iGaming 预设（
S2S-R-14）——请在测试之前与客户经理确认，而不是在测试过程中 register与deposit由生产环境代码触发，而不是测试环境- 事件由你真实的处理逻辑触发——充值事件来自支付确认回调，而不是玩家之后看到的那个页面
- 你的
client_user_id与同一站点上 Web 追踪器发送的user_id一致（S2S-R-08） - API key 存放在密钥管理服务中，测试环境使用单独的 key，或发送时带
X-Test-Mode: true（S2S-O-06） - 生产代码既不带
?dryrun=1，也不带X-Test-Mode（S2S-R-12）
要交给客户经理什么
| 交付物 | 为什么需要它 | 例外情况 |
|---|---|---|
| 你实现的是哪个档位——Basic 还是 Full | 决定你的广告系列可以使用哪些优化目标。把广告系列设成一个你并没有提供数据的目标，是第一周效果差最常见的原因。 | 无 |
| 你发送的事件名的准确清单 | 我们会在上线前而不是上线后把它们与目录比对。请以文本形式发送，不要截图——事件名需要逐字符比对。 | 无 |
| 你的产品名称与域名 | 确认事件落到了正确的产品上。 | 无 |
| 确认你的产品已开通 iGaming 预设 | deposit 是 iGaming 事件。没有订阅，每一次充值都会返回 422 EVENT_DISABLED，无论你的代码怎么写。 | 无 |
| 该产品是否有存量玩家，以及你的回填或截断方案 | FTD 按我们见到的最早一笔充值推导。没有方案的话，第一周的 FTD 会被存量玩家抬高，出价也会去追逐它。 | 仅当确实是全新品牌时可省略 |
一个来自真实 202 响应的 eventId，以及你发送它的时间——在上线测试之后填写 | 让我们端到端追踪一条已知正常的事件，而不是盲目搜索。 | 批量请求返回的是 requestId 与 count 而不是 eventId——改为发送这两项 |
| 哪些事件尚未实现，以及预计何时实现 | 避免我们提出你无法支持的目标，也让我们知道何时回头再看。 | 无 |
请以文本形式发送事件清单
直接从代码里复制事件名。配置页面的截图无法与目录做 diff，而一个字符的错误肉眼看不出来，却足以让整个集成失效。
上线测试
请用一次真实的线上广告点击和一笔真实充值来做。从终端发出的合成 payload 测不到通常会出问题的那部分——你自己的代码路径。
- 点击一条线上的 RevoSurge 广告
- 进入你的站点，让 Web 追踪器触发（点击就是靠它捕获的）
- 注册一个新的测试账户
- 登录
- 通过正常的收银台完成一笔小额真实充值
| 步骤 | 预期结果 | 在哪里查看 |
|---|---|---|
| 2. 落地 | Web 追踪器触发，点击 ID 被捕获并与会话关联存储 | 你自己的日志；后台中的 Web 追踪器事件计数 |
| 3. 注册 | 你的后端 POST register，收到带 eventId 的 202 | 你的请求日志 |
| 4. 登录 | login 已发送并被接受，client_user_id 相同 | 你的请求日志 |
| 5. 充值 | deposit 由支付确认处理逻辑发送，返回 202 | 你的请求日志 |
| 5. 充值 | context.transaction_id、context.amount 与 context.currency 全部存在，且与真实充值一致——三者均为必填 | dry run 回显，或你记录的 payload |
| 全部 | 每个事件都携带相同的 client_user_id，并且与 Web 追踪器的 user_id 一致 | 把各 payload 并排比对 |
| 之后 | 测试用户出现，其注册与充值归因到该广告系列 | 后台报表 |
测试失败怎么办
| 症状 | 检查这些规则 |
|---|---|
没有 202——请求被直接拒绝 | S2S-R-01、S2S-R-02、S2S-R-03 |
返回 200 而不是 202 | S2S-R-12——你仍处于 dry run 或测试模式。响应头 X-Ingest-Mode 会告诉你是哪一种 |
deposit 或任何 iGaming 事件返回 422 EVENT_DISABLED | S2S-R-14——你的产品未开通该预设。请最先检查这一项 |
422 UNKNOWN_EVENT_TYPE | S2S-R-04——该事件名不在目录中 |
400 并带有 violations | S2S-R-05、S2S-R-06、S2S-R-07、S2S-R-13、S2S-R-15——查看响应中的 field 与 rule |
全部返回 202，但下游缺少某个可选字段 | S2S-R-11——一个拼写相近的字段名被静默丢弃 |
| 事件到达了，但充值没有归因到广告系列 | S2S-R-08、S2S-R-16——用户 ID 不一致，或没有传入点击 ID |
| 注册被计了两次 | S2S-R-08——同一个人存在两个档案 |
| 第一周 FTD 数量远高于预期 | S2S-R-17——存量玩家的充值被当成了首充 |
| 事件来自测试环境 | S2S-O-06——同一个 key 在同时服务两个环境 |
如果每条规则都通过了、数字仍然不对，请停下来，把某个行为异常的具体事件的 eventId 和时间戳发给客户经理。一个可追踪的实例，比对症状的描述解决得更快。
上线之后：哪些改动需要重新检查
| 改动 | 影响 | 重新校验 |
|---|---|---|
| 轮换 API key | 旧 key 一停用，所有请求立即失败 | S2S-R-01、S2S-R-03 |
| 新增事件以从 Basic 升到 Full | 新事件名可能与目录不匹配、可能受订阅限制，而且每个都有各自的必填字段 | S2S-R-04、S2S-R-11、S2S-R-14、S2S-R-15 |
| 改变账户 ID 的生成方式 | 静默地拆分每一个用户档案 | S2S-R-08 |
| 新增域名或产品 | 事件可能落到错误的产品上，而且新产品没有充值历史 | S2S-R-01、S2S-R-10、S2S-R-17 |
| 更换支付服务商或收银台流程 | 充值事件可能移位、重复或停止，context.transaction_id 的配对也可能失效 | S2S-R-10、S2S-R-15、S2S-O-02 |
| 服务器迁移或新增区域 | 时钟偏差与转发 IP 的处理都会变化 | S2S-R-06、S2S-R-09 |
| 新增接入 MMP 的移动 App | 第三个 ID 必须与另外两个对得上 | S2S-R-08 |
| 升级到新的 API 版本 | 端点路径会变化 | S2S-R-02 |
把其中两项自动化
一个断言你的充值处理逻辑返回 202 的测试，加上一个断言你发送的 ID 与 Web 追踪器发送的 ID 一致的测试，就能在进入生产环境之前拦下本页中代价最高的两类故障。
代理商
- API key 由广告主生成并持有。代理商不应持有它，因为它用于对写入广告主数据的请求进行鉴权。
- 如果由代理商投放广告系列，请把事件清单和档位也发给代理商——优化目标由他们选择，他们需要知道可以设成什么。
- 集成仍由广告主的开发人员负责。代理商无法从广告系列一侧修复
S2S-R-08的不一致。