先把四個名詞放在同一張圖上
混淆多半來自一個錯誤前提：以為它們是四個可以互相替代的選項。 實際上它們分屬兩種東西——容器（東西裝在哪）和 回傳管道（資料怎麼送出去）。
一句話記法：GTM 和 sGTM 是「裝在哪」，gtag、Pixel、CAPI 是「怎麼送」。
問「我要用 sGTM 還是 CAPI」就像問「我要用倉庫還是貨運」。
四種「裝了但沒在運作」
下面四種我在每一個經手過的帳戶裡至少遇過一種。它們的共同點是 後台看起來是綠的。
一、sGTM 裝了，但只轉發瀏覽事件
- 症狀
- 伺服器容器有在跑、有流量、後台不報錯，但轉換數跟裝之前一模一樣。
- 為什麼
-
sGTM 預設只把
page_view轉過去。轉換事件要另外設定對應， 而那一步常常被當成「之後再說」，然後就沒有之後了。 - 代價
- 你付了伺服器端的主機費和建置費，換到的只有瀏覽事件。歸因一點都沒改善。
- 怎麼確認
- 在 sGTM 的預覽模式走一次結帳，看伺服器容器收到並轉出了哪些事件——不是看它有沒有在跑。
二、以為裝了 CAPI 就等於有伺服器端追蹤
- 症狀
- 「我們有做伺服器端」——實際上只是在 Meta 後台勾了轉換 API，事件仍從瀏覽器發出。
- 為什麼
- 很多電商平台的「一鍵開啟 CAPI」是由平台代送，你沒有自己的伺服器容器。 那不是壞事，但它只解決 Meta 這一邊，Google 那邊完全沒動。
- 代價
- 以為整套追蹤已經升級，實際上只升級了一半，而另一半的數字還在持續失真。
- 怎麼確認
- Meta 事件管理工具看事件的「來源」欄位有沒有伺服器；然後回頭看 Google 那邊有沒有對應的東西。多數情況是沒有。
三、CAPI 回傳的是表單提交，不是成交價值
- 症狀
- 名單量很漂亮，但成交數沒有跟著上來。而且越投越多同一類「愛填表但不買」的人。
- 為什麼
- 回傳最容易接的是表單事件。真正的成交發生在幾天甚至幾週後，要接訂單系統才送得出去。
- 代價
- 出價系統學到的是「誰會填表」，不是「誰會買」。 它會非常有效率地幫你找到更多不會買的人——而且報表上看起來成效很好。
- 怎麼確認
- 看回傳的事件裡有沒有帶實際成交金額。只有事件名沒有金額，就是這一種。
四、CAPI 和 Pixel 都在送，但沒做去重
- 症狀
- 裝了 CAPI 之後轉換數突然變好看很多，而營收沒有變。
- 為什麼
-
同一筆成交，瀏覽器送一次、伺服器送一次。去重要靠兩邊帶同一個
event_id，漏掉就會被算成兩筆。 - 代價
- ROAS 直接虛高，而所有「這檔有效，加碼」的決定都建立在那個數字上。
- 怎麼確認
- Meta 事件管理工具會顯示去重比率。或者最直接的：拿平台回報的轉換數去對你後台的訂單數。
為什麼這幾種特別難自己發現
一般的設定錯誤會有徵兆——數字歸零、報表空白、後台跳警告。 這四種都不會。它們產生的是看起來合理的數字， 而且方向通常是「變好看」，所以沒有人會去質疑。
共同結構
每一種都是「有裝」和「有在運作」之間的落差，而後台只能告訴你前者。
這也是為什麼健檢的第一步永遠是對帳，不是看儀表板： 只有拿平台數字去比你自己認列的成交，這四種才會同時現形。
如果你只想確認一件事，就確認那一件： 上個月平台回報的轉換數，跟你後台的訂單數差幾 %。 這個數字說不出來，上面四種你都可能有。