測試工具顯示成功，銷售報告卻不太合理。應從哪裏開始？事件可能帶着錯誤金額送達、重複發送，或延遲收到。成功傳送只是其中一個檢查點，並非整段流程已通過驗證。
Pixel 是透過瀏覽器傳送網站事件的程式碼；CAPI 即 Conversions API，是從伺服器傳送轉換資料的途徑。要分別核對實際業務行動、送出的資料，以及報告如何呈現。Meta 資源涵蓋事件質素、配對、去重和資料時效；TikTok 則說明 Pixel 與 Events API 的重疊事件。細節會因平台和整合方式而異。[1] [2]
1. 追蹤流程前，先定義事件
在你的業務中，何時才算購買：提交表格、確認付款，還是其他階段？先與業務負責人議定，再記錄對應的平台事件名稱，並說明金額、貨幣，以及折扣和取消訂單的處理。
選定訂單系統或 CRM 作為測試對照。目的是理解差異，而不是強迫每一份廣告報告都與業務紀錄相等。事件有否送達，以及是否歸因至廣告，是兩個不同問題。
2. 分開購買時間與接收時間
記錄行動發生、發送及接收時間，連同時區。系統在故障後重試時，檢查它仍在描述同一筆交易，而非錯誤建立另一筆記錄。
Server-side tracking，即伺服器端追蹤，只描述資料傳送路徑，本身不會授權收集更多資料。改動欄位前，覆核同意安排、政策和資料處理約定，並使用測試資料及合適環境。
實務練習：測試五種明確情況
以下是假設事件的建議清單，不代表所有平台都使用相同去重時間範圍。
| 情況 | 測試行動 | 檢查重點 |
|---|---|---|
| 正常事件 | 金額及貨幣已知的測試購買 | 名稱、金額、貨幣及時間 |
| 同一行動有兩個來源 | 發送設計中的瀏覽器及伺服器副本 | 按平台機制配對，不重複計算結果 |
| 重試 | 模擬故障後再次傳送 | 不產生新的業務訂單 |
| 無效資料 | 在測試副本刪除或改動貨幣 | 能否發現錯誤及記錄處理方式 |
| 未完成行動 | 在議定階段前離開 | 不誤記為已完成購買 |
每個案例先寫預期，再記錄觀察及證據。若未能追完整段路徑，就標示「尚未釐清」，比一個掩蓋未測部分的成功標記更實用。
3. 改設定前先解釋差異
先核對期間、貨幣和收入定義，再檢查遺漏、重複或延遲事件，最後才看相關歸因及模型估算規則。
同一購買分別從瀏覽器和伺服器送達時，檢查整合如何配對。事件延遲時，先查看時間資料，不要因尚未完整的報告而立即改預算。未經測試，不應把每項差異歸咎於某一傳送途徑。
4. 交付一份可重新驗證的修正清單
每個問題列出負責人、改動內容及重測案例。保留舊設定，並盡量把傳送方式調整與購買定義變更分開，方便解釋結果。
更換主題、網店應用程式或標記工具後，重測受影響案例。今天的測試只說明已測情況，不會自動涵蓋所有訪客。依賴數字作預算決策前，讓團隊清楚知道哪些已核對、哪些仍待處理。
官方參考資料
資料文件查閱日期：2026年10月16日。功能及資格要求可能改變，實施前請核對所連結的官方文件。
