合作夥伴 Postback 交付與上線
對象： 負責上線的人，需能存取設定 postback 的聯盟後台。
整合驗證證明你的 postback URL 是正確的。本頁要證明的是你的後台真的會在真實轉換時觸發它 — 這是另一回事，也往往是出問題的那一環。
交付之前
- 整合驗證中每一條必要規則都通過（
PB-R-01…PB-R-12） - 建議規則也通過，或已書面記下略過了哪些、原因是什麼
- postback 在聯盟平台中以伺服器端方式設定，而不是像素
- postback 規則已啟用，且作用範圍涵蓋 RevoSurge 流量到達的廣告系列或連結 — 沒有存為草稿，也沒有限定在另一個品牌上
- 你使用的每條事件路徑都已接好，並各自對應正確的 URL（只有傳送 App 啟動時才需要
/app-launch） - 已註冊的 URL 中已移除
dryrun（PB-R-10） k金鑰保存在平台的 postback 設定中，不出現在任何面向玩家的頁面上
四項 dry run 探測
請在真實測試之前先跑這幾項。在 URL 後附加 dryrun=1 — 不會記錄任何內容，回應會展示判定結果、去重鍵、解析出的身分識別以及解析後的取值。
dry run 回應是一份判定，而不是寫入回執：它帶有回應標頭 X-Ingest-Mode: dryrun，回傳的是 decision，而不是 {"status":"ok"}。
| # | 探測 | 預期判定 |
|---|---|---|
| 1 | 正常路徑，帶有效金鑰與身分識別 | 200，"decision": "accepted"，並回顯解析出的身分識別與取值 |
| 2 | 故意填錯 k | 403 |
| 3 | 既無 click_id 也無 user_id | 200，"decision": "ignored" |
| 4 | click_id 保持為字面宏，例如 {sub1} | 200，"decision": "ignored" |
請逐欄位閱讀探測 1 的回顯 — 只有在這裏，你才能確認 ts 是按毫秒解析的、event_id 確實送達而沒有退回到查詢字串雜湊，以及 amount 的正負號解析正確。
探測 3 和 4 比探測 1 更重要。上線後量不及預期時，你要看的正是它們；你需要在生產環境真正發生之前，就在自己的日誌裏見過「被靜默丟棄」是什麼樣子。
事後移除 dryrun
誤存進後台設定的探測 URL 就是 PB-R-10，而且它失敗時完全無聲無息。請在設定中搜尋 dryrun — dryrun、dryrun=1 和 dryrun=true 都會被接受。
dry run 會計入你的限流額度，所以請用腳本執行這些探測，而不要循環反覆發送。
要交給客戶經理什麼
| 交付物 | 為什麼需要 | 例外 |
|---|---|---|
| 五個端點中你接好了哪幾個 | 決定廣告系列可以按什麼優化。目標設為 FTD 卻沒有 /first-deposit postback 的廣告系列，由第一天起就會看起來是壞的。 | 無 |
| 你的聯盟平台名稱與版本 | 不同平台的宏語法與伺服器端 postback 行為各不相同；大多數平台的故障模式我們都見過。 | 無 |
已註冊的 postback URL，k 已遮蔽 | 讓我們在上線前、而不是上線後，發現錯誤的路徑或缺失的參數。請以文字形式發送。 | 無 |
一次成功測試轉換的真實 event_id 與 txid，並註明時間 — 在上線測試後補填 | 一個可追溯的樣例能在幾分鐘內解決一個歸因問題。 | 無 |
amount 是否以 USD 發送 | 我們不做任何幣別換算。如果你以其他幣別結算，我們需要在對帳前知道。 | 無 |
| 你的歸因模型（如果功勞是分攤的） | 否則我們會把每一次轉換都按全額功勞處理。 | 若採用最終點擊全額歸因，可省略 |
| 哪些事件你尚未發送 | 避免我們提出你無法支援的目標。 | 無 |
URL 請以文字發送，並遮蔽金鑰
後台設定的截圖無法逐字元核對，而錯誤的路徑或打錯的宏，肉眼是看不出來的。
上線測試
請在線上廣告上真實點擊一次，並走正常的玩家流程完成一次真實轉換。手動觸發 postback URL 測的是我們的端點，而不是你的平台。
- 點擊一條線上的 RevoSurge 廣告
- 到達你的網站
- 註冊一個新的測試帳戶
- 透過正常的收銀台完成一筆小額真實充值
| 步驟 | 預期結果 | 在哪裡查看 |
|---|---|---|
| 3. 註冊 | 後台觸發 /registration，回傳 200 {"status":"ok"} — 這是已確認的持久化寫入，而不只是收到 | 你平台的 postback 日誌 |
| 3. 註冊 | click_id 以真實值到達，而不是字面宏 | dry run 回顯，或已儲存的值 |
| 4. 充值 | 後台觸發 /first-deposit，回傳 200 {"status":"ok"} | 你平台的 postback 日誌 |
| 4. 充值 | amount 與實際充值金額一致，ts 為 13 位 | 你平台的 postback 日誌 |
| 4. 充值 | event_id 是真實的唯一 ID，而不是雜湊後備 | 對等負載的 dry run 回顯 |
| 兩者 | 兩次呼叫的 user_id 相同，且與你其他追蹤方式傳送的一致 | 比對兩條日誌中的 URL |
| 之後 | 測試玩家以一次註冊和一次 FTD 出現，並歸因到該廣告系列 | 後台報表 |
然後在同一帳戶上再做第二筆充值，確認它走到 /repeat-deposit，且不會增加 FTD。這一步能抓出 PB-R-05 — 否則它會在一週後，以一個誰也解釋不了的 FTD 數字冒出來。
如果你會傳送 App 啟動，還要在同一帳戶上把 App 關閉再開啟兩次。每次啟動都應觸發 /app-launch 並回傳 200 {"status":"ok"}，各自帶有獨立的 event_id，user_id 與註冊時相同 — 兩次啟動，兩條記錄。然後在全新安裝、尚未註冊時啟動一次，並對這條負載做 dry run：如果它既沒有 click_id 也沒有 user_id，就會被 ignored，請告知你的客戶經理。
測試失敗怎麼辦
| 症狀 | 檢查這些規則 |
|---|---|
403 | PB-R-01 — 金鑰錯誤，或來源 IP 不在白名單內 |
200 {"status":"ignored"} | PB-R-03、PB-R-04 — 沒有身分識別，或某個宏沒有被替換 |
503 | PB-R-09 — 請重試；寫入未被確認 |
| postback 根本沒有觸發 | 規則被停用、存為草稿，或作用範圍指向了錯誤的廣告系列 — 不是負載問題 |
| 充值被記成了註冊 | PB-R-02 — 端點路徑錯誤 |
| 多次 App 啟動被記成一條 | PB-R-08 — 每次啟動沒有唯一的 event_id |
| FTD 數偏高或偏低 | PB-R-05 — 首存與複存走了同一條路徑 |
| 同一次轉換被計了兩次 | PB-R-08 — 沒有穩定的 event_id，一次重試變成了一筆新記錄 |
| 轉換到了，但沒有歸因到廣告系列 | PB-R-11、PB-O-01 — 識別碼不匹配，或沒有 ctx 後備 |
| 收入數字差了幾個數量級 | PB-R-07 — 正負號問題，或金額不是 USD |
| 時間線看起來不對，但沒有任何報錯 | PB-R-06 — ts 用了秒 |
什麼都沒記錄，卻一律回傳 200 | PB-R-10 — 已註冊的 URL 上仍帶着 dryrun |
上線之後：哪些改動需要重新檢查
| 改動 | 影響 | 重新驗證 |
|---|---|---|
| 聯盟平台升級或遷移 | 宏語法與 postback 規則很少能完好保留下來 | PB-R-04、PB-R-02，並重跑探測 |
輪換 k 金鑰 | 由舊金鑰失效那一刻起，每條 postback 都回傳 403 | PB-R-01 |
| 新增品牌、皮膚或新網域 | postback 規則通常按品牌設定作用範圍，不會自動沿用 | PB-R-02，以及上文清單中關於作用範圍的那一項 |
| 改變玩家 ID 的產生方式 | 悄無聲息地把每一份用戶檔案拆開 | PB-R-11 |
| 更換支付服務商或收銀台 | 充值觸發點可能移位、重複或停止 | PB-R-05、PB-R-07 |
| 開始收入分成結算 | 多出一個新端點，負金額也開始真實出現 | PB-R-02、PB-R-07 |
| 開始傳送 App 啟動 postback | 多出一個新端點，且常在玩家還沒有 id 時觸發 | PB-R-02、PB-R-03、PB-R-08，並重跑探測 |
| 改變歸因或功勞分配模型 | 我們的報表與你的報表會在毫無預警的情況下出現分歧 | PB-O-07 |
| 對 postback URL 模板的任何改動 | 一個字元就能弄壞它，而故障的表現是 200 | 重跑全部四項探測 |
後台有任何改動後，重跑四項探測
只需兩分鐘，而且是發現靜默 ignored 唯一的低成本辦法。
代理商
- 營運方持有
k金鑰與後台設定。代理商如果沒有該平台的存取權限，就無法代營運方設定 postback。 - 如果由代理商投放廣告系列，請把已接好的端點清單發給他們 — 優化目標由他們選擇，他們需要知道可以設成什麼。
- 識別碼不匹配（
PB-R-11）無法從廣告系列一側修復，必須在產生這些 ID 的地方修復。
下一步
- 合作夥伴 Postback API — 完整參數列表與回應語義
- 整合驗證 — 完整規則列表
- 追蹤概述 — 合作夥伴 Postback 如何與其他三種方式配合