網店只記錄了一張訂單，Meta 資料卻似乎不一樣。是重複計算？傳送金額包括運費？還是你把實際訂單與歸因至廣告的銷售作比較？每個問題都需要不同檢查。
先從購買本身開始，再跟着資料走。Pixel 從瀏覽器傳送事件；Conversions API，簡稱 CAPI，也可能從伺服器傳送。同時使用兩條路徑，要檢查如何處理同一行動的副本，不能把每則訊息都當成新購買。Meta 資源涵蓋事件配對、質素、去重及資料時效。[1]
1. 先議定何時才算購買
與網店負責人和追蹤專員一起確認：事件在確認訂單時發送，還是付款後？金額只包括產品，還是連運費和稅項？看數字前先把定義寫下來。
廣告團隊和網店團隊可能用同一名稱描述不同階段。即使傳送功能正常，若不同報告期間改了定義，仍會令比較混亂。
2. 測試具體情況，不要一開始便全部重裝
在合適環境準備測試訂單，不使用真實付款或個人資料。記錄時間、金額、貨幣和預期結果，再利用該設定適用的工具檢查是否收到事件。
測試已完成訂單、未完成嘗試，以及重新開啟確認頁。如果 Pixel 和 CAPI 都有傳送，核對整合如何處理兩份資料。設定細節和去重識別方式須參照所用整合的文件，不能未經檢查便照搬其他項目。
示例：四個案例，幫你找出檢查方向
以下數字及識別碼純屬示例，並非真實網店成效。
| 測試案例 | 網店發生的行動 | 要核對的問題 |
|---|---|---|
| demo-001 | 120 USD 的購買 | 收到的金額及貨幣正確嗎？ |
| demo-002 | 同一購買從瀏覽器及伺服器發送 | 有按同一行動的重疊事件處理嗎？ |
| demo-003 | 重新開啟確認頁 | 有否誤發新的購買事件？ |
| demo-004 | 未完成購買 | 有否記錄實際不存在的完成行動？ |
另加實際結果和所需行動兩欄。只測一個案例，不宜便寫「追蹤正常」。
3. 分清收到事件與歸因至廣告
網店記錄、追蹤工具收到的事件，以及報告歸因至廣告系列的銷售，量度的是三種不同結果。要求逐項相等前，要先核對期間、時區、銷售定義及歸因方法，即如何把轉換連結至廣告。
如果銷售金額有變，訂單數卻沒有相近變化，就檢查金額定義、貨幣和傳送來源。這些是待驗證問題，不是差異的現成答案。
4. 修正問題後才增加對數字的依賴
發現錯誤金額或重複事件時，列明修正內容、執行人員和重測方式，並記錄日期，讓團隊理解下一期報告的變化。
不要只為隱藏問題而改廣告系列目標。也不要未覆核收集及分享權限，便為提高配對分數而增加資料。目的是讓數字可理解、可用於決策，而不是讓儀表板更好看。
官方參考資料
資料文件查閱日期：2026年10月16日。功能及資格要求可能改變，實施前請核對所連結的官方文件。
