Meta 高過 Shopify 訂單 — 先查 event_id 去重
Meta Purchase 長期高過 Shopify 訂單？先查 Pixel 與 Conversions API 的 event_id 是否對齊，不要急著加預算。
老闆把 Meta Ads Manager 截圖傳來，畫面裡的 Purchase 數量、廣告投資回報率（ROAS）都比 Shopify 訂單漂亮。他問我，是否可以加預算。我沒有先回答加多少，而是先問：這些 Purchase，是否同一張訂單被算了兩次？
公司增收降本，先建基於量度可信。若廣告報表比真實訂單高，預算決策就像看著放大的數字。放大不等於生意變大。對老闆而言，最危險的不是報表難看，而是報表太好，好到讓人急著加碼。
如果 Meta 的購買數長期高過 Shopify 訂單，第一步不是加預算，而是查清楚有否重複事件。增收降本的前提，是數字能代表著真實生意，而不是代表著系統收到了更多事件。
痛點：同一張單，兩條路，兩個 event_id
在 Shopify 加 Meta Pixel 與 Conversions API 的帳戶，常見問題不是沒有事件，而是事件太多。同一張訂單，瀏覽器 Meta Pixel 送一次 Purchase，Conversions API 又送一次 Purchase。若兩邊 event_id 不同，Meta 不一定把它們當成同一件事。
根據 Meta 官方文件〈Handling Duplicate Pixel and Conversions API Events〉，去重需要同一 event_name，以及相同 event_id。瀏覽器 Pixel 的 eventID 與 Conversions API 的 event_id 對得上，才有機會被視為同一事件；若不同，同一張訂單可能被計兩次。以官方 Handling Duplicate Pixel and Conversions API Events 說明為準。
這會讓報表出現一種漂亮：購買數上升，ROAS 上升，單次購買成本看似下降。但 Shopify 訂單沒有同步增加。落差不是平台故意灌水，而是事件設定把同一筆交易拆成兩份紀錄。報表像神蹟，生意卻沒有跟著神蹟。
對公司增收降本而言，這種落差會誤導資源分配。廣告團隊以為投放效率提升，老闆以為需求增加，財務卻只看到訂單沒有同步上升。問題不在於投放一定差，而在於量度先失真。
錯在邊：把重複當成成交
第一個錯，是把雙計當真實成交。Ads Manager 顯示的 Purchase 是事件報表，不是銀行入帳。它代表著系統收到事件，不代表每一筆都對應一張獨立訂單。若沒有對回 Shopify，數字很容易變成決策依據。
第二個錯，是沒有在 Events Manager 的 Test Events 查重。很多人只看總量，不看單張訂單是否重複。Test Events 的價值，在於可以即時看到事件名稱、參數、時間，以及同一訂單是否出現兩次。若同一訂單編號在短時間內出現兩次 Purchase，就要懷疑 event_id 沒有對齊。
第三個錯，是只修表面。有人會把 CAPI 關掉，或把 Pixel 關掉。這可能減少重複，但也可能減少應有覆蓋。較穩妥的做法不是盲目關掉其中一條路，而是讓兩條路送同一張單時，使用同一個事件識別。
換句話說，問題不是「要不要用 Conversions API」，而是「同一張訂單是否被系統認出為同一件事」。若事件識別不一致，關閉其中一條路只是把問題藏起來；若事件識別一致，兩條路才可以互相補位，而不是互相重複。
我怎麼做：先固定識別，再測試，再對數
我的做法分四步。
第一步，固定同一 event_id。瀏覽器 Pixel 的 eventID 與 Conversions API 的 event_id，應使用同一個值。對 Shopify 商店而言，最自然的值是訂單編號。訂單編號本身代表著交易，適合用作去重識別。若每次發送都隨機產生 event_id，瀏覽器一次、伺服器一次，兩者永遠對不上，重複就會持續。
訂單編號的好處是簡單而穩定。它在商店端有明確意義，也能讓廣告端把兩條事件路徑指向同一筆交易。它不需要依賴額外客戶資料，也能減少不同系統各自產生識別碼所造成的錯配。
第二步，在 Events Manager 的 Test Events 查重。我會用一張測試訂單完成購買流程，然後觀察 Purchase 事件。正常情況下，同一張訂單不應在短時間內出現兩筆獨立 Purchase。若出現兩筆，我會檢查兩筆的 event_id、event_name、訂單編號、時間戳，以及觸發來源。若事件名稱相同但 event_id 不同，問題就相當明確。
測試時，我會保留可追蹤的訂單編號與時間記錄。這樣做不是為了追求完美，而是為了讓問題可以被重現。若同一訂單編號出現兩次，而兩次的 event_id 不同，修正方向就會清晰得多。
第三步，對回 Shopify 訂單數。我會選一段固定時間，例如七天或十四天，比較 Meta 去重後的 Purchase 數、Shopify 實際訂單數，以及廣告花費。我不追求兩者完全相等，因為廣告平台與商店後台仍有記錄口徑、時間差、瀏覽器限制等差異。但方向要合理：Meta 的 Purchase 不應長期大幅高過 Shopify 訂單，而沒有可解釋原因。
單日比較容易被時區、訂單成立時間、付款狀態等因素干擾，所以我通常看連續區間。重點不是某一天完全吻合，而是整體趨勢是否可解釋。若 Meta 持續高出一大截，而 Shopify 沒有相應訂單，那就不能只用「平台比較樂觀」帶過。
第四步，才談預算。量度可信之前加預算，是在放大誤差；量度可信之後加預算，才是公司增收降本的計算。若去重後 ROAS 仍然合理，加碼才有意義。若去重後 ROAS 大幅下降，那代表先前數字有水分，及早修正比繼續花錢重要。
檢查時，我會把幾個位置放在一起看：
- 瀏覽器 Pixel 發送的 eventID
- Conversions API 發送的 event_id
- Shopify 訂單編號
- Events Manager 內是否出現重複 Purchase
- Ads Manager 與 Shopify 訂單數的差距
這幾項不是技術裝飾，而是讓報表回到可討論狀態。若老闆問「為何 Meta 比 Shopify 高」，我要能回答哪一段是真實成交，哪一段是重複事件。若回答不了，任何加預算決定都只是押注。
限制：數字變差，可能是回歸真實
修好之後，報表可能變差。Purchase 數下降，ROAS 下降，單次購買成本上升。這不代表生意忽然變差，而是數字回歸真實。先前的高報表，是同一張單被算了兩次；現在只是不再把重複當成額外成交。
這一步需要心理準備。若團隊習慣用高 ROAS 證明投放有效，去重後的數字會讓會議變得不舒服。但我寧可在加預算前面對真實，也不願用放大後的數字說服自己。
也不要指望一鍵修好。不同商店的實作方式不同，有些事件由主題檔發送，有些由應用程式發送，有些經中間層轉發。修好 event_id 後，仍要持續觀察。Meta 官方文件說的是去重條件，不是保證所有帳戶會自動變回正確。實際結果仍取決於事件名稱、參數、發送順序與測試驗證。
另外，Shopify 訂單數也不是唯一真理。不同訂單狀態、付款狀態、出貨狀態，都會影響「真實成交」的定義。我的做法是先用同一口徑比較，至少讓廣告報表不要憑空多出一截。若要把財務口徑也納入，需要另一層對帳。
這也代表著，去重不是令生意立即變多的魔法。它的作用是讓報表回到可比較、可判斷、可決策的狀態。公司增收降本需要的不是更漂亮的數字，而是更可信的數字。
結尾：先去重，再加碼
Meta 高過 Shopify，不一定是好消息。它可能代表著報表重複，而不是市場需求增加。公司增收降本的第一步，不是急著加預算，而是先查 event_id 去重。
先去重，再加碼。若你的商店同時使用 Meta Pixel 與 Conversions API，而 Ads Manager 的 Purchase 長期高過 Shopify 訂單，我會先把 event_id 對齊列為第一項檢查。
老闆 FAQ
Meta 的 Purchase 比 Shopify 訂單多，是不是可以加預算？
先別急著加。痛點是報表比真實訂單好看。判斷：同一張單可能被 Meta Pixel 與 Conversions API（CAPI）各送一次 Purchase，兩邊 event_id 不同就被當成兩筆。下一步：在 Events Manager 的 Test Events 查重，把瀏覽器 eventID 與伺服器 event_id 對齊（常用訂單編號），再對回 Shopify 訂單數，量度可信才談加碼。
為什麼修好 event_id 之後，ROAS 反而變差？
痛點是數字忽然「難看」。判斷：先前的高報表，往往是同一張單被算了兩次；去重後數字回歸真實，不是生意忽然變差。下一步：用同一段時間比較去重後的 Purchase、Shopify 訂單與花費；方向合理再決定預算，不要為了報表好看而保留雙計。
可不可以關掉 Pixel 或關掉 CAPI，就解決重複？
痛點是想用「關掉其中一條路」快速止血。判斷：關閉可能減少重複，也可能減少應有覆蓋；問題核心是同一張訂單有否被認出為同一件事。下一步：先固定同一 event_id，再用 Test Events 驗證，而不是先砍掉其中一條發送路徑。
訂閱後可解鎖 GA 量度自查清單，從 GA 一邊核對成交訊號與訂單對帳。
若你想把目前的 Meta 與 Shopify 數字落差整理成可檢查的個案，可經聯絡表單留下商店類型、事件發送方式與截圖範圍。我會以可驗證的步驟回覆，不談空泛口號。