Blog · 2026-08-30

先追蹤，後放量：Pixel 與 CAPI 同 event_id 雙送去重實作

瀏覽器端像素在 iOS 隱私時代會漏事件，我們用同一組 event_id 雙送去重加上乾淨的比對鍵，把站上事件的配對品質實測做到 6–7。

廣告有在花錢，後台轉換數卻和實際訂單兜不攏。客人明明有買，像素卻沒回報——因為成交發生在站外的第三方接單頁，瀏覽器端追蹤碼看不到那一步；就算成交在站內，iOS 用戶那份也會缺一角。演算法拿殘缺訊號去找受眾，預算放得越大，學得越歪。

為什麼只靠 Pixel 一定漏

瀏覽器端追蹤這幾年被連環削弱：iOS 的 ATT 讓用戶一鍵拒絕追蹤；Safari 與 Firefox 的追蹤防護大幅縮短 cookie 存活期；廣告阻擋外掛直接把像素請求整包擋掉。業界普遍估計，這些因素加起來會讓純瀏覽器端追蹤漏報約 20–30% 的事件。

漏掉的不只是報表數字。Meta 的投放演算法靠轉換事件學習「誰會買」，教材缺了兩三成，出來的受眾就是歪的。解法方向很明確：加開一條伺服器端通道（Conversions API），請求從伺服器直接送 Meta，瀏覽器外掛碰不到它。但兩條通道同時送，同一筆轉換會被算兩次——去重就成了這套架構的第一個工程問題。

雙送去重：event_id 是唯一的橋

我們的做法：前端 Pixel 照常送事件；同一時間，把同一筆事件從伺服器端再送一次 CAPI。CAPI 端點自架在 Cloudflare Pages Function 上，前端打的是自家端點，由它帶上憑證轉送 Meta——金鑰不落前端，之後要加驗證、加過濾也都在自己手上。

去重靠 Meta 的配對規則：事件名稱相同、event_id 相同，就視為同一筆、只計一次。所以 event_id 必須由前端產生一次、同時交給 Pixel 和後端；不要兩邊各自產生，也不要拿固定字串充數，它得是每筆事件都不重複的值。去重失敗的代價不只是報表難看：同一筆成交被計兩次，成效看起來直接翻倍，你會在錯的數字上做加預算的決定。

驗證不能省。我們上線前實測兩邊 event_id 完全一致，CAPI 端拿到 Meta 回應 events_received:1，測試事件工具裡兩邊事件成對出現並標示已去重——都過了才放行。

比對鍵：先正規化、再雜湊，垃圾訊號直接剔除

Meta 靠比對鍵把事件對回真實用戶，事件配對品質（EMQ）評的就是這件事。我們帶六個鍵：email、電話、姓、名、城市、國家，全部在伺服器端正規化之後才做 SHA256 雜湊送出。正規化照官方規格走：email 轉小寫、去頭尾空白，電話去掉符號與前導零、補上國碼——規則對齊，兩端算出來的雜湊才會是同一個值。

正規化放伺服器端是刻意的：規則只有一份，前端改版不會讓同一個人的雜湊值飄掉。剔除規則也一樣硬：格式壞掉的 email、位數不足的電話、空值，一律不送。原則是正確第一——錯的資料雜湊完送上去配不到人，只會拉低整體配對品質，等於花力氣送雜訊。

這套做完，站上意圖事件的 EMQ 實測落在 6–7（Meta 十分制）。沒有玄學，就是鍵給得齊、給得乾淨。

離線回灌不附 IP/UA，是刻意的

成交發生在站外那段，我們用 CAPI 回灌 Purchase 事件，action_source 標 system_generated，而且不附 IP 和 UA。

理由很簡單：那筆成交不是發生在用戶的瀏覽器裡，你手上根本沒有他當下真實的 IP 和 UA。拿伺服器自己的 IP 充數是在餵假訊號——配不到人，還會汙染配對品質，得不償失。寧可少給，不能給錯。也因為離線事件少了瀏覽器端的環境訊號，配對全壓在比對鍵上，前一節的正規化與剔除在這裡直接決定事件配不配得到人。這一批離線事件實測成功回灌 7 筆，演算法第一次拿到站外真實成交的名單，而不是只看得到進站不知道結局。

結語：追蹤沒驗過，預算不要放

整套架構就三件事：同 event_id 雙送去重、比對鍵正規化加雜湊、離線回灌不造假訊號。做完之後，演算法拿到的才是完整又乾淨的買家訊號，放量才放得有依據；反過來，追蹤還沒驗證就加預算，是花錢讓演算法學錯東西。放量前至少驗三件事：兩邊 event_id 一致、測試事件標示已去重、EMQ 落在健康區間。

如果你的廣告後台轉換數和實際訂單老是對不起來，或成交根本發生在站外系統，這套從端點自架、比對鍵清洗到驗證放行的流程我們完整走過一輪，可以找我們聊聊。