實務解說 / 轉換追蹤
為什麼 iGaming 轉換報表對不起來？
先確認各系統比較的是相同事件、統計期間與審核狀態，再沿 postback 流程排查，區分報表口徑差異與傳送問題。
正在評估 James 是否適合 Media Buyer 職務？
與 James 討論職務本指南展示我如何檢視轉換定義、postback 路徑與報表差異。若要討論招聘，請分享您希望評估的職務、投放渠道與追蹤職責。
工作溝通使用英文。
想先自行檢查？可繼續閱讀下方指南。
S2S Postback 檢查：轉換缺漏或數據不一致
後台有事件，Tracker 沒有
先查事件是否送出、Tracker 的 click ID 是否保留，以及接收端的回應。缺少共同識別碼或傳送紀錄時，先標示為尚未釐清。
Tracker 有事件，廣告平台沒有
先確認該事件是否設定為回傳給廣告平台，再獨立檢查這一段 postback：流量來源 click ID、事件對應、傳送回應與報表篩選。第一段成功不代表第二段也成功。
兩邊都有事件，每日總數卻不同
對齊時區、日期邊界、造訪或 postback 接收時間口徑、審核狀態與歸因規則。等已知的報表延遲過後重新匯出，再決定是否需要改追蹤設定。
1. 比較 CPA 前，先定義轉換
註冊、聯盟平台核准的轉換，以及首次入金（FTD），代表不同結果。事件最初被記錄後，核准狀態也可能再變動。先寫清楚每份報表的事件與認定條件，才能判斷總數是否能直接比較。
- 列出事件名稱、觸發條件與核准要求。
- 確認計算的是事件次數、不重複使用者，還是已核准行為。
- 以相同範圍的花費除以約定的轉換數計算 CPA；註冊 CPA 不等於 FTD 成本。
2. 對齊日期、時區與歸因規則
點擊日期、轉換發生日期與回傳抵達時間，可能不同。例如 Voluum 支援依造訪時間或 postback 時間呈現報表，因此較晚回報的轉換可能出現在不同日期，並非漏記。
- 各份匯出資料使用相同時區與起訖時間。
- 記錄每個系統採用的時間基準、歸因模型與歸因期間。
- 留下各份報表的匯出時間；再次比對前，納入已知的審核或報表延遲。
3. 沿著回傳路徑核對事件
伺服器對伺服器（S2S）postback 會在系統間傳送轉換資訊。分別檢查後台或聯盟平台到追蹤工具，以及追蹤工具到廣告平台的相關環節；前一段成功，不代表下一段也成功。
- 在授權範圍內，使用對應的 click ID 與事件或交易識別碼追查樣本。
- 比對送出的事件類型、接收端的對應設定，以及可取得的回應或錯誤紀錄。
- 依該整合方式的文件確認重複事件處理、狀態更新與傳送延遲；同一次點擊產生的不同事件，不一定屬於重複。
參考文件：Voluum: Parameters in postback URLs · Voluum: Custom conversions
4. 核對實際取得的資料
先限定一個活動與明確期間。有共同識別碼時，逐筆核對；只有彙總數字時，先對齊事件、篩選條件與時間設定。聯盟行銷團隊可能只能取得核准轉換報表，無法取得營運商的入金資料；應記錄這項限制，不推算成入金成果。
- 已核對：兩個系統都能識別同一事件。
- 差異已解釋：可由時間、狀態、篩選條件或定義說明。
- 待釐清：證據不足，或有特定傳送與事件對應問題需要追查。
5. 把發現轉成明確的下一步
有效的檢查應列出發現、支持證據、負責人與後續驗證方式。修正已確認的事件對應問題，或統一報表檢視方式後，再次比較。避免一次更動多項追蹤設定，否則難以辨識是哪一項調整產生影響。
不要把每筆未對上的紀錄都視為營收流失，也不要只因某個儀表板的 CPA 較低就放大預算。原因尚未確認時，應說明還需要什麼資料才能判斷。
追蹤修正後 CPA 下降，成效真的改善了嗎？
追蹤修正後，報表 CPA 下降，可能只是先前未記錄的轉換開始被計入。把它當成加碼理由前，先做以下檢查：
- 記錄衡量方式的改變。 記下修正內容、變更時間與受影響事件。比較前後時，清楚列出事件定義、時間口徑與核准狀態；計數方式改變，會限制這項比較能證明的事情。
- 核對廣告主端結果。 能取得廣告主端報表時，使用完整、等長的統計窗口，保持相同活動範圍、事件與核准規則。比較支出及已確認轉換，並考量已知的報表或核准延遲。追蹤到更多註冊，不代表已確認的首次入金增加。
- 有資料時，往首次轉換之後看。 能取得報表時，檢查獲取使用者的營收或留存。若無法取得，就記錄這項限制，不單憑 CPA 推定客戶品質改善。
- 根據證據決定下一步。 若廣告主端證據不支持改善，就不要把報表 CPA 下降當成擴量訊號。若證據支持測試，先約定有限的預算增幅並觀察相同結果；將測試成果與計數方式的改變分開評估。
James 的 LinkedIn 原文：追蹤改變與報表 CPA
報表具可比性後，再將獲客成本與客戶價值一起評估。 獲客成本與客戶價值
可直接使用的對帳檢查表
先選一個活動與明確期間，在內部檢視紀錄中為每個抽樣事件保留一列，包含以下欄位：
- 活動與報表來源、匯出時間及時區。
- 事件定義、計數單位與審核狀態。
- 可取得的 Tracker click ID、流量來源 click ID，以及事件或交易 ID。
- 可取得的點擊時間、轉換時間與 postback 接收時間。
- 比對結果：已配對、差異已解釋，或尚未釐清。
- 證據、負責團隊、建議動作與下次驗證日期。
假設示例，並非客戶實績：點擊發生在午夜前，轉換於隔天早上抵達。依造訪日期與 postback 日期分組的報表，可能把同一事件放在不同天。先比對事件與時間口徑，不要直接判定轉換遺失。
Postback 成功，為何轉換報表的數字仍不同？
請求顯示成功，本身不能證明正確事件已記到正確點擊，也不能證明它已納入你正在看的報表。需分別核對兩段回傳、事件對應，以及報表的日期口徑、篩選條件與更新延遲。
完整填寫範例：對帳 10／9／10 筆轉換
以下是教學用假設範例。所有數量、識別碼、時間與證據編號均為虛構，並非客戶實績或平台預設。欄位名稱使用英文，方便對照下載的工作表。
1. 在 Review 填好檢查範圍
本次只查一個活動、一種註冊事件。假設十筆註冊都來自指定流量來源，符合相同驗證條件與歸因期間。其中九筆已逐筆對上，第十筆待查。
展開完整範圍填寫內容
| 工作表欄位 | 範例填寫值 |
|---|---|
| Campaign / market | DEMO-01 / hypothetical market |
| Conversion event / trigger | registration / backend validates a completed registration |
| Counting unit | One unique event ID per validated registration |
| Period start (inclusive) | 2026-10-11 00:00:00 |
| Period end (exclusive) | 2026-10-12 00:00:00 |
| Time zone | UTC for all fields |
| Owner | Media buyer (hypothetical role) |
| Review date | 2026-10-13 |
| Currency | N/A: event-count reconciliation; no spend comparison |
| Approval / rejection rules | Include validated registrations only |
| Attribution model / window | Scenario assumption: last eligible click / 7 days |
| Expected reporting delay | Scenario assumption: up to 24 hours; verify actual integration |
| Reference system | Backend export B01 |
| Exclusions (QA, duplicates) | Exclude test events and repeated event IDs |
| Maturity cutoff / rationale | Export 2026-10-13 09:00 UTC, more than 24 hours after period end |
| Access / evidence gaps | Scenario assumes permitted access to all event logs and exports |
2. 先確認口徑，再計算報表差額
三份原始報表均於 10 月 13 日 09:00 UTC 匯出。Tracker 最初依點擊日期分組，另外兩份依轉換日期分組。因此 Tracker 的 Comparable? 填 No，差額保持空白。看到 9 與 10，代表需要查原因，不能直接認定少了一筆轉換。
| 來源 | 原始日期口徑 | 原始筆數 | 可比較？ | 對齊後筆數／差額 |
|---|---|---|---|---|
| 廣告平台 (N01) | 轉換日期 | 10 | Yes | 10 / 0 |
| Tracker (T01 → T02) | 點擊日期 | 9 | No → Yes | 10 / 0 |
| 後台／參考來源 (B01) | 轉換日期 | 10 | Yes | 10 / — |
本例以後台匯出作為約定參考。比對 ID，再將 Tracker 匯出事件依轉換時間重新分組後，三份資料包含相同的十個事件 ID。Tracker 對齊後為 10 筆，差額為 0。若工具無法提供所需逐筆資料，就保留為待釐清。
3. 在 Event log 填入跨午夜的那筆事件
點擊發生於 10 月 10 日 23:58 UTC，註冊於 10 月 11 日 00:06 UTC。依點擊日期查看 11 日報表會排除這筆，即使轉換與兩段回傳都在 11 日發生。本例還有接收端紀錄確認事件及點擊對應；只有成功訊息仍不足以結案。
展開完整事件列
| 工作表欄位 | 範例填寫值 |
|---|---|
| Sample ID | S01 |
| Event / approval status | registration / validated |
| Tracker click ID | T001 |
| Source click ID | N001 |
| Event / transaction ID | E001 |
| Click time | 2026-10-10 23:58:00 |
| Conversion time | 2026-10-11 00:06:00 |
| Tracker receipt time | 2026-10-11 00:06:02 |
| Network receipt time | 2026-10-11 00:06:04 |
| Time zone | UTC |
| Match status | Explained difference |
| Evidence reference | DEMO B01 / T01 / N01: E001 mapped to T001 and N001; both receivers recorded registration |
| Finding | Click-date report excludes E001 from 11 October; conversion-date report includes it |
| Next action | Regroup tracker export by conversion time and compare the full event-ID set |
| Owner | Tracking analyst (hypothetical role) |
| Next check | 2026-10-13 10:00:00 UTC |
4. 記錄發現，驗證後才結案
展開完整待辦列
| 工作表欄位 | 範例填寫值 |
|---|---|
| Issue ID | D01 |
| Finding / evidence | Date-basis mismatch for E001; see DEMO B01 / T01 / N01 |
| Status | Closed |
| Next action | Use conversion-time grouping for this review; preserve original exports |
| Owner | Tracking analyst (hypothetical role) |
| Due date | 2026-10-13 |
| Verification evidence | DEMO T02 at 10:00 UTC: 10 event IDs match B01 and N01. All Comparable? = Yes. Network and tracker deltas = 0. |
| Closed date | 2026-10-13 |
本例解釋的是報表日期口徑差異，不能據此宣稱投放改善、找回營收或應該加預算。總數差額為 0 只是起點；這次能結案的證據是十個事件 ID 都已核對一致。
對齊後仍有差異時
先確認兩段 postback 都接受了預期事件、保留正確 ID，再核對事件映射、審核狀態、重複處理、篩選與報表是否已更新完成。證據缺漏就保留待釐清，並交由能取得資料的團隊續查。
例如 PropellerAds 的文件分別說明不同轉換目標，並提醒轉換可能需最多 24 小時才顯示於統計。這是該平台的說明，不是所有工具通用的等待時間。 官方 S2S 文件（2026 年 10 月 13 日核對）
FTD 有回傳，活動就真的在優化 FTD 嗎？
不一定。商業目標、Tracker 送出的事件、廣告網路記錄的目標，以及平台用來優化投放的訊號，是需要分開核對的設定。報表出現 FTD 欄位，還不能證明投放以 FTD 優化，也不代表活動已經獲利。
假設排查範例。以下 ID、數字與設定均為教學用途，不是客戶實績或平台預設值。
某營運商希望增加符合約定條件的首次入金客戶。假設團隊已核對一個 PropellerAds CPA Goal 活動，得到下列設定：註冊與 FTD 都有回傳，但扮演不同角色。
手機可左右捲動表格。
| 核對項目 | 本例已核對的設定 | 代表什麼 |
|---|---|---|
| 商業目標 | 已接受的 FTD | 營運商希望取得的結果 |
| Tracker → 主要 postback | registration | 送給廣告網路的主要事件 |
| Tracker → 次要目標 | first_deposit → goal=2 | 另外記錄的後續事件 |
| 投放優化訊號 | 主要 postback | 在這組設定下是註冊 |
PropellerAds 文件指出，CPA Goal 活動的投放表現只受主要 postback 事件影響；次要目標可記錄後續事件。這是該平台與活動類型的規則。 平台依據，查核日期：2026-10-14。PropellerAds: S2S / CPA Goal.
接下來怎麼查
- 一起核對 Tracker 的送出對照與目前活動設定。只看到 Tracker 的事件名稱還不夠；保留能確認接收目標、且帶日期的設定證據。
- 以同齡 cohort 比較註冊與已接受的 FTD。若 FTD 尚未完整回報或無法取得，先記錄缺口，再判斷便宜註冊是否支持增加花費。
- 如果優化訊號與商業目標不同，與帳戶負責人約定下一步測試。修改前先確認平台支援、事件品質及可用轉換量。
目前能做什麼判斷
這份對照能說明活動收到什麼訊號，還不能解釋入金偏弱的原因，更不能直接認定支付、KYC 或流量品質出問題。決策紀錄應留下目前設定、擬議變更、核准者與複查條件；不是看到差異就把 FTD 改成主要目標。
James 可以協助什麼
James 可檢視事件對照與可取得的來源、版位報表，整理有依據的測試方向及尚缺資料。設定存取權限與實際調整，另依合作範圍約定。
Tracker 有轉換、廣告網路沒有：到底少了哪一個 ID？
Tracker click ID 與廣告網路的 source click ID 用途不同：前者把事件連回 Tracker 的造訪，後者可能是回傳給流量來源時必需的識別值。兩者都叫 click ID，也不能直接互相代換。
假設排查範例。以下 ID、數字與設定均為教學用途，不是客戶實績或平台預設值。
後台和 Tracker 都有註冊事件 E204，Tracker 也能對到 T204，但可取得的匯出表沒有顯示 source click ID；廣告網路報表則找不到對應事件。此時原因仍是待查。
手機可左右捲動表格。
| 證據位置 | 假設觀察 | 下一個問題 |
|---|---|---|
| 後台事件 | E204／registration／accepted | 是否連到正確的 Tracker 造訪？ |
| Tracker 紀錄 | E204 對到 T204 | 流量進站時有保存來源 ID 嗎？ |
| Source click ID | 匯出表中看不到 | 是真的缺失，還是該報表沒顯示？ |
| 送往廣告網路的請求 | 尚未檢查 | 實際送出哪個 ID 與事件？ |
Voluum 文件將 cid 列為必要的 Tracker click-ID 參數；PropellerAds 另有自己的來源 ID token。實際欄位與傳值方式須依整合文件確認。 平台依據，查核日期：2026-10-14。Voluum: postback parameters · PropellerAds: S2S tokens.
接下來怎麼查
- 檢查可授權使用的進站紀錄與 token 對照。空值或沒有展開的佔位符值得排查；只有匯出表少一欄，還不能證明流程故障。
- 沿同一事件查看送出請求與接收結果，核對目的地、來源 ID、事件與時間。回應成功的證據，和報表納入的證據要分開保存。
- 如果 ID 當時沒有保存，請負責團隊確認是否仍有可信的對照紀錄。不能自行補造 ID，也不能把事件接到另一個點擊；資料不足就保留未解。
目前能做什麼判斷
確認傳值錯誤後，可以安排限定範圍的修正與授權測試，但不能保證歷史轉換能補回。若考慮重新回傳，須先由平台或整合負責人確認支援的程序與去重規則；測試紀錄要排除於成效統計。
James 可以協助什麼
James 可整理每一段資料交接的證據，列出需要 Tracker、廣告網路或營運商團隊回覆的問題。無法存取的後台資料與平台內部故障，由具備權限的團隊追查。
四次 postback，是四個轉換、兩個事件，還是一位客戶？
應計算事先定義的商業事件，而不是通知次數。重送、新事件與狀態更新需要不同處理；只用 click ID 一律去重，也可能刪掉有效的後續事件。
假設排查範例。以下 ID、數字與設定均為教學用途，不是客戶實績或平台預設值。
以下四次通知都屬於同一個已核對的測試流程 T031。第二次沿用相同事件 ID 與內容，第四次則更新原註冊的狀態，不是新增註冊。本例假設 ID 與事件關係均已確認。
手機可左右捲動表格。
| 通知 | 事件 ID／類型 | 如何理解 |
|---|---|---|
| 1 | E101／registration／pending | 第一次回報註冊 |
| 2 | E101／相同註冊及狀態 | 第一次通知的重送 |
| 3 | D201／first_deposit／accepted | 另一個後續事件 |
| 4 | E101／registration／approved | 更新原註冊的狀態 |
RedTrack 提供新增、忽略或更新轉換等不同的重複回傳處理模式。須確認實際設定與事件識別方式；本例不指定通用的去重選項。 平台依據，查核日期：2026-10-14。RedTrack: conversion types and duplicates.
接下來怎麼查
- 把每次傳送嘗試連到所屬事件。本例有四次通知、兩個不同商業事件、一個註冊及一個 FTD，不是四位新客戶。
- 確認整合如何識別重送與狀態更新。不能預設 pending 變 approved 就新增一筆，也不能把每次重複 click ID 都視為重複事件。
- 同時核對 Tracker 與下游報表。某一邊更正成功，不代表另一邊的次數或金額已更新；先記錄預期結果，再依文件中的延遲檢查。
目前能做什麼判斷
如果統計指標是已核准註冊，本例為一筆；如果是已接受 FTD，也是一筆。兩種事件不能相加後稱為兩位新客戶。若沒有 ID 或狀態歷程，真正的不重複事件數仍是未知。
James 可以協助什麼
James 可把通知、事件與狀態分開整理成差異紀錄，檢視目前計數規則。工作表每個不同事件用一列，重送與狀態更新的紀錄放在證據備註；不要為了對齊總數而直接刪掉資料。
下載 Tracking 排查工作表
用這份工作表對照同一活動、同一轉換事件的報表，集中記錄證據與下一步。
Report downloads are not shared through this portfolio.
英文版 · XLSX · 9 KB · 免費下載，免註冊
- 先在 Review 定義事件、報表期間與比較規則；確認口徑一致，再填入三個來源的數據。
- 在 Event log 記錄抽樣事件、時間與證據，並為未解決的差異指定負責人及下次檢查時間。
差額空白代表資料不完整或無法比較；0 只表示總數相同，不代表逐筆吻合。表內附有明確標示的假設範例。
調整活動前的追蹤常見問題
Postback 成功，為何轉換報表的數字仍不同？
請求顯示成功，本身不能證明正確事件已記到正確點擊，也不能證明它已納入你正在看的報表。需分別核對兩段回傳、事件對應，以及報表的日期口徑、篩選條件與更新延遲。 查看 10／9／10 筆的完整填寫範例
註冊 CPA 可以直接與首次入金 CPA 比較嗎？
兩者衡量不同結果。必須對齊事件、計數單位與統計範圍再比較成本。註冊 CPA 降低，本身不代表首次入金成本降低或獲利提升。
討論追蹤職責時，提供哪些背景有幫助？
請說明職務、市場、工具與涉及的追蹤職責。初步討論提供概括且匿名的例子即可；請勿傳送密碼、玩家資料或機密報表。
這套方法與我的工作有什麼關聯
我的實務經驗包括 APAC 付費流量與 RedTrack S2S 追蹤。本指南說明我會如何界定報表差異、找出尚未解決的問題，並選擇下一步檢查。招聘團隊可以用它討論我的衡量與活動營運方法。
本頁是排查方法解說，不是客戶案例，也不承諾所有系統的數字都能完全一致。
討論 Media Buyer 職務
請分享公司、職務、工作安排，以及您希望討論的活動或追蹤職責。
工作溝通使用英文。
For job opportunities, use the current contact page.
Discuss a role with James (English)