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的不一致。