快速結論：你的 Pixel 沒壞，更不是要被淘汰（Meta 官方從沒宣布過這件事）——它是瀏覽器端的眼睛，iOS 之後它走的那條路開始漏水了。CAPI（轉換 API）是另開一條伺服器端的路，把漏掉的轉換訊號補回去。兩條路並行、Meta 靠同一組事件 ID 去重，所以不會重複計算。這篇教你看懂：為什麼要補、補得回多少、又補不回什麼。
這篇寫給投了廣告、卻發現後台轉換數字越報越少，開始懷疑是不是自己哪裡設定錯的你。
先講個我親身繳的學費。iOS 14 那波隱私更新之後，我眼睜睜看著同一組廣告回報的轉換數一路往下掉。第一反應是「是不是我素材做爛了」，改了兩個禮拜的素材、換了受眾、調了出價，數字還是不動。後來才發現，問題出在 Pixel 那頭：它能看到的東西，被 iOS 砍掉了一角（懷疑人生整整兩週，結論是我冤枉了工具，工具從頭到尾沒背叛我…）。那陣子群組裡最流行的一句話就是「Pixel 要死了」。但我翻完 Meta 官方文件才搞懂（它到底看得到什麼、看不到什麼，〈Meta Pixel 是什麼〉那篇講過）：Pixel 沒有要死。它只是從「一個人包辦所有事」，變成「需要一個伺服器端的隊友」。那個隊友，就是 CAPI。
先搞懂：Pixel 為什麼會失準——瀏覽器路的三個漏水點
目的：Pixel 存在，是為了記錄使用者在你網站上的行為（看了商品、加了購物車、買了單），再回報給 Meta 去優化廣告、做再行銷。它走的是一條「瀏覽器路」：使用者的動作 → 瀏覽器裡的 Pixel 程式碼 → 送回 Meta。Pixel 在整套〈數據追蹤基礎建設全圖〉裡，就是廣告平台那隻站在瀏覽器裡的眼睛。
問題就出在這條路，iOS 之後有三個漏水點：
- 同意這一關：iOS 14.5 之後，App 要追蹤你得先跳出視窗問「要不要允許」。很多人手一滑就按了不允許，這群人的行為，Pixel 就報不完整。
- 瀏覽器擋這一關：Safari 這類瀏覽器對第三方 cookie 和追蹤 script 的限制越收越緊，有些訊號在送出 Meta 之前，就先在瀏覽器裡被攔下來了。
- 斷點這一關：手機看、電腦才下單，或網路一卡、頁面還沒跑完 script 人就關掉了——這一筆也跟著漏掉。
效果：這三個漏水加起來，你在 Meta 後台看到的轉換數，會比真實發生的少。這件事最陰險的地方是：它讓你低估廣告成效，然後你可能一氣之下把其實有效的廣告關掉（我當年差點就這樣幹，還好手賤先去查了文件…）。
極限：這是隱私架構造成的結構性缺損，你設定得再認真也補不滿。我實測過，瀏覽器路的 Pixel 再怎麼調，天花板就在那——因為它天生只能站在瀏覽器裡，瀏覽器擋什麼、使用者不同意什麼，它就是看不到。想補，只能另外開一條路。
CAPI 補的是什麼——那條不走瀏覽器的伺服器路
目的：CAPI（Conversions API，轉換 API）存在，是為了開第二條路——不從瀏覽器送，而是由你的伺服器直接把轉換事件送給 Meta。
用個生活比喻你就懂了：瀏覽器路，像你請上門的客人離開時「幫你帶個口信回去」（客人可能中途落跑、可能懶得帶、可能根本拒絕）；伺服器路，是你自己打電話給 Meta——線在你手上，不受瀏覽器攔阻，也不看使用者心情。
效果：那些在瀏覽器路漏掉的轉換，特別是實際發生在你後端的（付款成功、後台成立訂單），可以由伺服器補送回去。訊號一完整，Meta 的 AI 拿到的資料就更全，幫你找會買的人、回報成效都更準。
那 Pixel 和 CAPI 都送同一筆，不會重複算嗎？這就是去重要做的事。Meta 的做法是：同一筆轉換，你在 Pixel 和 CAPI 兩邊都帶上同一組事件 ID（event_id），Meta 收到就認得出「這兩筆其實是同一件事」，只算一次（依 Meta 官方轉換 API 文件，這是官方建議的並行去重機制）。所以兩條路並行，不是灌水，是互補。
極限：CAPI 不是萬靈丹，有三件事得老實跟你說：
- 它要有伺服器能送。CAPI 得靠串接才動得起來——要嘛工程協助、要嘛用電商平台內建的接口。不是後台打個勾就自動有的（雖然很多平台已經簡化到接近打勾了，這點下面 FAQ 講）。
- 送得對不對，看你的事件設計。伺服器送了一堆沒對到商業問題的資料，一樣是垃圾進、垃圾出。說到底，送給 CAPI 的每一筆，本質上還是你預先設計好的一個事件——這件事重要到值得單獨講一整篇，在〈事件設計學〉。
- 它補的是「回報完整度」，補不回「使用者根本沒同意被追蹤」這件事。隱私是回不去的大方向，CAPI 只是讓你在合規範圍內盡量看清楚；把它當成繞過同意的後門來用，遲早出事。
兩條路怎麼並行：一張圖看懂，順便學會驗收
把兩條路串起來看：一筆轉換發生 → 瀏覽器路（Pixel）送一次、伺服器路（CAPI）送一次，兩邊都帶同一組 event_id → Meta 認出是同一筆、去重 → 你得到一個比單靠 Pixel 完整得多的回報。一件事、兩條路、一次計算。
看懂這張圖，你就會問出對的驗收問題：
- 我們的網站，CAPI 接了沒？還是只靠 Pixel 單腳跳？
- Pixel 和 CAPI 有沒有帶同一組 event_id？（沒帶，去重就失效，數字反而會虛胖——從一個極端掉到另一個極端）
- 最關鍵的轉換（例如付款成功），是從伺服器端送的嗎？（這種本來就發生在後端，最該走 CAPI，也最補得回來）
老闆／廠商遲早會問你的三題
一、我們現在是 Pixel＋CAPI 雙軌，還是只有 Pixel 一條腿？（只有 Pixel，代表你的成效數字大概率一直被低估）
二、兩邊有沒有做 event_id 去重？（有雙軌沒去重，等於把低估救成高估，一樣不準）
三、補上 CAPI 之後，我們的成效基準是不是該重新校準一次？（回報變完整了，之前那條「歷史成效線」的基準就不能直接沿用——這一步最多人忘）
三題答得清楚，你的轉換追蹤就從「瞎一隻眼」升級成「兩隻眼睛還會對焦」了。想幫接手的舊網站做全面體檢，清單在〈追蹤健檢：接手一個網站，先看這 7 件事〉。
常見問題（FAQ）
所以我該把 Pixel 拆掉、改用 CAPI 嗎？
別。Meta 官方立場是兩者並行互補，去重之後一起用最完整。把 Pixel 拆了，你反而少一條路、少一份交叉驗證。CAPI 的定位就是隊友，接班從來不在 Meta 的規劃裡。
接 CAPI 一定要工程師嗎？
看你的平台。很多電商與建站平台已經內建 CAPI 串接，簡化到「開啟＋填一組 token」的層級，這種不太需要工程；完全自建的網站才需要工程協助。這篇不教安裝步驟（網路上教學很多，也會隨介面改版），重點是你要知道「這件事做得到、而且該做」。
補了 CAPI，我的 ROAS 會變好看嗎？
會變準，不保證變好看。有時候補回漏掉的轉換，ROAS 會上修（本來被低估）；但如果你之前是靠重複計算在灌水，去重之後反而可能下修。準比好看重要——後台數字為什麼常常騙人，〈為什麼你的 ROAS 可能是假的〉那篇會拆給你看。
Pixel 到底會不會被淘汰？
截至本文，Meta 官方沒有任何淘汰 Pixel 的公告，官方文件講的一直是 Pixel 與 CAPI 並行。「Pixel 要死了」是產業焦慮的口耳相傳，不是 Meta 給的時程。真有那天，官方會白紙黑字公告，到時我第一時間回來改這篇。
「瀏覽器路 vs 伺服器路」的兩條回報路徑，是本站「數位行銷素養」體系的一部分，將隨各家隱私政策與 Meta 產品更新持續迭代（建議每半年回訪本文）。想知道你的轉換追蹤少接了哪條路？幫你準備：數位廣告健檢表單傳送門。