轉換追蹤怎麼重建：第三方 Cookie 留下來了，瀏覽器端的官方衡量方案卻收了
很多品牌在等 Chrome 淘汰第三方 Cookie，等到的卻是 Google 把 Attribution Reporting API 一起退役。瀏覽器不會再代勞衡量，廣告轉換要被算得回來，得自己把事件定義、採集、送達、身分匹配、去重五個環節逐項驗收。這篇拆開每個環節各補哪一段流失、裝錯會看到什麼症狀，以及怎麼驗。
等了六年的瀏覽器端衡量方案，在 2025 年 10 月被取消了
2025 年 10 月 17 日，Google Privacy Sandbox 副總裁 Anthony Chavez 發了一篇公告。這篇文章有兩個訊息，台灣的行銷團隊多半只收到前面那個。
前面那個訊息是：Chrome 維持現行的第三方 Cookie 處理方式。這件事在同年 4 月 22 日其實已經定調，當時 Google 說不會再推出新的獨立第三方 Cookie 提示。很多人讀到這裡就關掉頁面了，結論是「Cookie 留下來了，危機解除」。
後面那個訊息影響更大。同一篇公告裡，Google 以採用率過低為由，宣布退役多項 Privacy Sandbox 技術，名單包括 Attribution Reporting API、Topics、Protected Audience、Private Aggregation、IP Protection、On-Device Personalization、Related Website Sets、SelectURL、SDK Runtime 與 Protected App Signals。保留下來的是 CHIPS、FedCM 與 Private State Tokens，全部偏基礎設施，沒有一項是拿來算廣告成效的。
Attribution Reporting API 是這份名單裡對衡量影響最大的一個。它本來的角色，是讓瀏覽器在不揭露個人身分的前提下，回報「這次點擊後來有沒有成交」。過去六年，整個產業被告知的劇本是：Cookie 會被拿走，但瀏覽器會用新機制替你把帳算出來。
公告裡 Google 也說明，會繼續透過網頁標準流程參與可互通的歸因標準討論。所以事情不是「以後都沒有官方方案」，而是那條「瀏覽器內建替你算帳」的路線，在可預見的期間內不會有成品。Cookie 的命運沒有改變，改變的是算帳這件事的責任歸屬，它從瀏覽器移回了品牌自己的系統。
我們最常聽到的那個問題
有個場景我們反覆遇到。
行銷窗口把 Google Ads 的轉換數、Meta 的轉換數、自家後台的訂單數三個欄位並排放在同一張試算表裡，三個數字沒有一個對得上。老闆問了三次「到底哪個是真的」，窗口每次都只能回「平台算法不一樣」。這個答案老闆聽第一次還接受，聽第三次臉就沉下來了。
真正該先問的是另一個更前面的問題：這三個數字裡，有哪一個你說得清楚它是怎麼被記下來的。多數團隊會愣住，因為追蹤碼常常是前一任同事裝的，接手的人只知道「有裝」。
那幾秒的沉默，比三個對不上的數字更值得擔心。歸因怎麼算是平台的規則，讀懂就好；事件怎麼被記下來，是品牌自己的工程，沒人會替你檢查。
轉換追蹤是一條產線，每個環節壞掉的症狀不一樣
轉換追蹤常被講成一件事，實際上它是一條產線，中間有幾個可以分開檢查的環節。每個環節出問題，後台會顯示的症狀長得不一樣，而這正是排查的著力點。
| 環節 | 這裡有問題時，可能看到的症狀 |
|---|---|
| 事件定義 | 後台有數字，但那個數字不是你要的生意 |
| 採集 | Safari 與 Firefox 的轉換明顯偏低，Chrome 正常 |
| 送達 | 整體轉換數比訂單數少一截，跨裝置的訂單容易漏掉 |
| 身分匹配 | 事件有送到，但匹配品質分數偏低，受眾圈不到人 |
| 去重 | 轉換數比訂單數還多，尤其結帳完成頁被重整時 |
這張表是「可能症狀與待查方向」，不是一對一的故障對照表。同一個症狀可能有多個來源，例如 Safari 轉換偏低也可能來自流量組成或同意率差異，跨裝置漏單也可能卡在身分連結。表格的用途是把「數字不對」這句話拆成幾種可以分工處理的毛病，讓你知道先往哪個方向查。
另外有兩件事貫穿所有環節。一是同意管理，使用者拒絕某項用途時，對應的資料處理必須停止，可用的觀測範圍因此縮小。二是持續驗收，設定一次不等於永遠正確，平台改版、網站改版、金流改版都可能讓某個環節悄悄失效。
如果你對轉換的基本定義、Google Ads 後台怎麼開一個轉換動作這些入門步驟還不熟，可以先看〈Google Ads 轉換追蹤全解讀：從定義到實戰〉補齊基礎。那篇談的是單一平台的設定入門，這篇接的是它後面那一段，也就是同時在跑 Google 與 Meta 兩邊、而且瀏覽器不會再代勞的時候，整條產線要怎麼逐項驗收。
瀏覽器端的收緊，比 Chrome 的新聞早了六年
把時間軸拉開會發現，台灣品牌盯著 Chrome 看的這幾年，改變遊戲規則的是另外兩個瀏覽器。
Safari 在 2019 年就開始收，2020 年封鎖跨站 Cookie
Apple 的 Intelligent Tracking Prevention 是一版一版收緊的。ITP 2.1 在 2019 年 2 月做了一件影響極大的事：透過 JavaScript 的 document.cookie 寫入的持久性 Cookie，保存期限一律被壓到七天。這一刀砍到的是第一方 Cookie。很多品牌以為自己用的是第一方追蹤所以安全，實際上只要那個 Cookie 是靠前端腳本寫進去的，Safari 就當它是七天的短期身分。
假設一個品牌的回購週期是六十天，而它只靠這個前端 Cookie 認人，沒有登入或其他可連結的識別，那麼使用者第二次回來時就可能被記成新訪客。有登入機制的品牌則不受這一條限制，這也是為什麼會員登入率會直接影響追蹤品質。
到了 2020 年 3 月 24 日，WebKit 宣布 Safari 13.1 與 iOS 13.4 起全面封鎖跨站 Cookie，官方說法是「跨站資源的 Cookie 現在一律預設封鎖」。
Firefox 在 2022 年就對全球桌面使用者預設隔離
Mozilla 的 Total Cookie Protection 走的是分區隔離路線，替每個網站開一個獨立的 Cookie 罐子，讓同一個追蹤網域在 A 站與 B 站拿到的 Cookie 互相認不得。這個機制在 2022 年 6 月對全球桌面使用者預設開啟。
Google 在 2025 年連做兩個決定
Chrome 這邊的兩次公告前面已經提過。放在這條時間軸上看，Chrome 未全面淘汰第三方 Cookie 的這段期間，Safari 和 Firefox 已經把瀏覽器端追蹤的可靠度削掉一大塊。只盯著 Chrome 的品牌，等於用最慢的那個時鐘在校時。
現在 Chrome 確定維持現狀，而原本要在瀏覽器端補上衡量缺口的那套 API 被取消。接下來能做的，是把產線上每個環節逐項驗收與補強。
補送達、補匹配、補重複，是三件不同的工程
這一節是整篇最容易被跳過、卻最常導致投錯藥的地方。市面上談轉換追蹤的解法，各自補的是不同環節。把補送達的工具拿去解歸因問題，裝了也不會好。
伺服器端回傳補的是送達
以 Meta 的 Conversions API 為例，它讓資料不經過瀏覽器，直接從你的伺服器送到平台，減少對前端送出的依賴，也就降低了追蹤防護、廣告攔截器與網路中斷造成的流失。它補的不是歸因，是送達。訊號送到之後怎麼被算進哪一檔廣告，那還是平台歸因規則的事。
要留意的是，伺服器端回傳不會自動把已經失去的點擊識別或跨站身分變回來。後端本來就知道的資訊（例如訂單成立後才確認的實收金額）它送得很好，但前端沒抓到的點擊參數，伺服器也變不出來。同意狀態同樣要從前端傳到後端，使用者撤回時對應的用途必須停止。
雜湊比對補的是身分匹配
Google Ads 的增強型轉換把結帳流程取得的 Email、電話、姓名地址做 SHA256 單向雜湊，再把雜湊值送給 Google，與已登入 Google 帳號的雜湊值比對。比對上了，這筆訂單才接得回當初那次點擊。實作方式不只一種，可以用網站代碼、代碼管理工具，也可以走 API，後者允許在轉換發生後一段時間內從資料庫或 CRM 補送，所以「雜湊在哪裡做」要看你選的串接方式。
需要雜湊的是個人識別資料。Google 的規範細到 Gmail 位址要先把使用者名稱裡的句點與加號後綴清掉再雜湊，少做這一步，算出來的雜湊值就跟 Google 手上那份對不起來，比對直接落空。國家、州別、城市、郵遞區號則不雜湊。很多品牌的增強型轉換「有裝但沒效」，卡的就是這種層級的細節。
Meta 那邊對應的指標是事件匹配品質分數，滿分十分。官方說明講得很直白：這個分數看的是你從伺服器送了哪些顧客資訊參數、資訊品質如何，以及有多少比例的事件成功對應到 Meta 帳號。這個分數衡量的是匹配，不等於歸因成功率，兩者別混為一談。
去重補的是重複計算
當你同時裝了瀏覽器端像素與伺服器端回傳，同一筆訂單會被送兩次。Meta 的去重機制用 event_id 加 event_name 這組配對當比對鍵，收到相同配對時保留先到的那一筆、丟掉後到的。
這裡有個很容易踩的坑：瀏覽器端的像素傳這個參數時用的是駝峰式的 eventID，伺服器端 CAPI 的酬載用的是底線式的 event_id。參數名稱拼對只是第一步，更關鍵的是兩端必須共用同一個穩定的識別值。如果使用者重新整理結帳完成頁時系統給出新的識別值，去重一樣會失效，因為平台會把它當成另一筆事件。實際影響幅度取決於兩端的覆蓋範圍，要靠測試情境驗證，不能用推算的。
同意管理決定可觀測的範圍
使用者拒絕追蹤時，Google 的同意模式有兩種實作。基礎版在使用者按下同意之前完全不載入 Google 代碼，拒絕就什麼都不送；進階版在被拒絕的狀態下仍送出不含 Cookie 的 ping，讓 Google 有材料建模。差別在於基礎版只能吃通用模型，進階版能拿到以你自己網站資料訓練出來的廣告主專屬模型。
建模本身有資格門檻。Google Ads 官方說明文件（查核於 2026 年 9 月）寫的是七天期間內每天達到 700 次廣告點擊，並且依國家與網域分組計算。台灣中型電商常常卡在這個量級，這是進階版裝了卻看不到建模效果的常見原因。未達門檻不代表同意管理不用做，法遵與使用者選擇的落實跟建模是兩回事，只是別把廣告主專屬建模當成短期就會看到的成效。
事件定義出錯，前面四件事全部白做
上面四類機制都是技術補救。最前面的事件定義反而最常被跳過，而它出錯的代價最高，因為技術再完美也只是把錯的東西準確地送出去。
事件定義要回答的是：對這門生意而言，什麼叫做一次值得記錄的轉換。常見的三種錯誤是這樣：
- 把所有動作都當成出價目標。加入購物車、加入收藏、填表單全部掛上去，出價系統就會朝著最容易發生的那個動作最佳化，跑出一堆加車卻不結帳的流量。要注意「主要與次要」是 Google Ads 的特定設定，Meta 那邊對應的是廣告組合的最佳化事件，兩邊要分開檢查。次要行為該不該追蹤，答案是該追，它們的用途是診斷漏斗破口。這個分界我們在〈廣告微轉換：電商老闆真正該看的數字〉裡談過完整的分類方式。
- 轉換值的口徑沒定義清楚。回傳訂單金額時，有的團隊送未扣折扣的原價，有的送含運費的實收，有的品牌退貨率高卻從不回傳退貨調整。平台拿到被灌水的價值，算出來的 ROAS 自然漂亮，實際毛利卻在往下掉。要先講定的是觸發點（訂單成立、付款成功還是出貨完成）以及折扣、稅、運費、部分退款各自怎麼算。
- 事件與會員身分沒有綁定。事件送出去了卻沒帶會員 ID，同一個人在手機瀏覽、桌機下單，在平台眼裡就可能是兩個人。這裡要說清楚的是，帶了會員 ID 也不保證匿名瀏覽能自動歸戶，兩端都要有可連結的識別資訊才接得起來。這件事的修法不在廣告後台，在你的會員系統。
事件定義做對了，後面幾個環節的投資才有意義。一個把加車當出價目標的帳戶，就算 CAPI 裝得完美、匹配品質分數很高，也只是把錯誤的訊號更高效地送給演算法。
至於平台後台的數字和自家訂單數為什麼永遠對不上，那屬於歸因口徑，是另一套問題。我們在〈GA4 顯示 140 筆，Meta 後台說 320 筆？三本帳對帳法〉裡完整拆過，這篇不重複。要先講清楚的是先後順序：追蹤設定沒驗過之前去吵歸因口徑沒有意義，因為你不知道自己在比的兩個數字裡，有沒有一個本來就漏了一大截事件。
第一方資料的真相在訂單系統，廣告後台看不到
講到這裡，有一個結論已經浮出來了：產線上有好幾個環節的答案，都不在廣告平台手上。
身分匹配要餵的顧客資訊、事件要綁的會員 ID、轉換值要用的實收金額與退貨調整，全部來自品牌自己的會員與訂單系統。廣告平台能做的是接收與比對，它沒辦法替你定義誰是同一個人，也沒辦法替你判斷這筆訂單最後有沒有退掉。
這是 91APP CDMP 在這件事上的位置。它累積的是品牌自己的成交紀錄與會員歸戶結果，OMO 情境下線上線下的消費被歸到同一個會員 ID，所以它能提供廣告後台拿不到的三種輸入：這筆訂單的實收金額、這個人在其他通路的購買紀錄、以及品牌自己認定的同一個會員身分。至於這些輸入送到平台後能不能提高匹配率，取決於兩端是否有可連結的識別資訊，要靠匹配品質分數實測，不是裝了就一定會好。
實務上的接法，是讓訂單系統成為事件定義與轉換值的來源，把追蹤碼當成其中一個資料出口而已。事件從伺服器端送出時帶上歸戶後的會員識別，轉換值取實收金額，退貨在各平台允許的調整機制內回補。Google Ads 有轉換調整的機制可以重述或撤回，Meta 那邊的處理方式不同，不能假設兩邊做法一樣，不支援的部分就回到品牌自己的淨營收帳上處理。
同一份歸戶資料也是再行銷名單的來源。這裡要分清楚兩種資料：購買紀錄本來就在訂單系統裡，拿得到；瀏覽紀錄仍然要靠前端採集，一樣受同意狀態與識別條件影響。把兩者混為一談會高估自己手上的資料完整度。實際的分群與投放路徑，我們在〈Meta 再行銷成本越來越高？用購買意圖標籤把池子縮到對的人〉裡有完整說明。
先用訂單逐筆驗收，再回頭比較報表
下面的順序是刻意排的。由前往後驗，因為後面每個環節的結果都被前面汙染；跳著驗只會得到互相矛盾的結論。
- 盤一次事件定義。把出價目標收斂到真正代表生意的動作，Google 與 Meta 兩邊分別確認。同時把轉換值口徑寫下來：觸發點是哪一個、折扣稅費運費怎麼算、部分退款怎麼處理。這一步的重點是先盤清楚口徑，改串接是後面的事，兩者工作量不同，要分開估。
- 逐筆核對，不要只比總量。先框出一個應該回傳的訂單集合，條件是同一期間、同一訂單狀態、同意條件一致，再用訂單編號或事件識別碼逐筆對照哪些沒被觀測到。直接拿兩端的事件總數相減不能當作漏失比例，因為重送、觸發時點、事件範圍與付款狀態都會影響總數。分母驗過了，比例才有意義。
- 檢查去重是否真的在運作。到事件管理工具看有沒有重複事件的警示，比對兩端用的是不是同一個穩定的識別值，並且實際測試重新整理結帳頁與重送這兩個情境。
- 看匹配品質分數，往回追是哪些顧客資訊參數沒送或送得不完整。Meta 的網站事件需要帶
client_user_agent、action_source與event_source_url這幾個欄位，它們關係到事件來源的有效性；能不能匹配到帳號，則主要看你送了哪些可用的顧客識別資訊。先確認事件被有效接收，再看匹配。 - 確認同意模式是哪一種實作，以及流量量級離建模門檻有多遠。離 700 次廣告點擊還很遠的品牌，不必把廣告主專屬建模當成近期會兌現的成效，該做的合規與事件驗收照做。
- 最後才把三個後台的數字放在一起比，而且比之前要先固定條件：時區、日期基準、訂單狀態、各活動實際採用的歸因窗設定都要記錄下來。歸因窗的預設值各平台改過多次，以你帳戶當下的設定為準，不要引用網路上的通用說法。還要記得同一筆訂單可能被不同平台各自歸因，兩邊的轉換數不能相加當成總訂單。
前面五步沒做完就開始對帳，得到的落差裡混著設定錯誤與口徑差異，分不開，也就修不了。
那個窗口該怎麼回答老闆
回到開頭那張三個欄位對不上的試算表。
「平台算法不一樣」這句話是對的，但它把一個可以修的工程問題，講成一個只能接受的天氣現象，難怪聽第三次會讓人臉沉下來。
比較誠實也比較有用的答案是這樣：三個數字本來就在回答三個不同的問題，這部分沒得改；但在這之外，我們的事件有多少沒送到、送到的有多少匹配不上人、匹配上的有多少被重複算了兩次，這三件事全部查得出來，而且查出來的部分是可以動手修的。
第三方 Cookie 留不留得下來，從來不是品牌能決定的事。瀏覽器要不要替你把帳算好，也不是。能決定的只有一件：當瀏覽器確定不再代勞的時候，你有沒有把自己這條產線的每個環節，一格一格地驗過一次。
被收走的不是 Cookie，是那個會替你補齊答案的人。
品牌最常問的轉換追蹤問題
Q1：第三方 Cookie 消失之後，廣告轉換還追得到嗎？
A1：追得到，但機制換了。現況是 Chrome 維持第三方 Cookie，Safari 自 2020 年 3 月起全面封鎖跨站 Cookie，Firefox 自 2022 年 6 月起對全球桌面使用者預設隔離 Cookie。所以你的流量裡有一部分的跨站辨識早就受限了，站內的交易事件仍然記錄得到。補救方式是把事件回傳從瀏覽器端移到伺服器端，並且用雜湊過的第一方顧客資訊做身分比對。這兩件事分別補的是送達與匹配，要一起做才完整。
Q2：CAPI 跟像素差在哪？要不要兩個都裝？
A2：像素在使用者瀏覽器裡跑，會被追蹤防護、廣告攔截器與網路中斷影響；CAPI 從你的伺服器直接把資料送到平台，減少對前端的依賴。兩者看得到的東西不完全重疊，像素抓得到瀏覽器端的行為細節，CAPI 抓得到伺服器才知道的資訊，例如訂單成立後才確認的實收金額。所以標準做法是兩個都裝，並且設好去重。Meta 的去重用 event_id 加 event_name 這組配對，重複時保留先收到的那一筆。要檢查的是像素端參數叫 eventID、伺服器端叫 event_id，而且兩端必須送同一個穩定的識別值，重新整理頁面時若產生新值，去重一樣會失效。
Q3：廣告後台的轉換數跟自己後台的訂單數對不起來，是什麼原因？
A3：要先分成兩類，處理方式完全不同。一類是追蹤設定造成的，包括事件沒送到、送到了匹配不上人、或是重複送了兩次；這一類可以修。另一類是歸因口徑造成的，包括各平台歸因模型不同、歸因窗設定不同、回報日期基準不同，例如 Google Ads 以點擊發生日回報轉換，而 Google Analytics 以轉換發生日回報，同一筆訂單會落在不同天。第二類沒辦法讓數字完全一致，只能固定比較條件並監控落差比率是否穩定。建議先查第一類，查完再談第二類。
Q4：轉換追蹤要怎麼設定才準？
A4：按順序做這幾件事：先把出價目標收斂到真正代表生意的動作，Google 與 Meta 兩邊分別確認；接著定義轉換值口徑，包括觸發點、折扣稅費運費算法與部分退款處理；然後接上伺服器端事件回傳；再把雜湊過的顧客資訊與會員識別一起帶上；最後設好去重，並且實際測試重整與重送情境確認它有生效。同意管理則貫穿全場，要先確認採用的是哪一種實作。順序不能顛倒，因為事件定義錯了的話，後面幾步只會把錯誤的訊號送得更有效率。
Q5：沒有第三方 Cookie，再行銷名單還能怎麼建？
A5：改用品牌自己的第一方資料回推。這裡要分兩種：購買紀錄、會員等級、最近一次購買日這類資料本來就在訂單系統裡，拿得到也不依賴跨站追蹤；瀏覽與互動紀錄則仍需前端採集，一樣受同意狀態影響。做法是把歸戶後的會員名單依購買意圖分群，再以雜湊後的形式上傳到廣告平台比對。這樣建出來的名單通常比靠跨站追蹤圈出來的池子小，實際效果要用投放測試驗證，不能預設一定更好。
Q6：小品牌流量不大，這些要全部做嗎？
A6：不用全部做，但順序要對。事件定義與轉換值口徑校正是盤點工作，任何規模都該先做完。伺服器端回傳與雜湊比對需要開發投入，中小品牌可以先確認自己的電商平台是否已內建。至於同意模式的進階建模，Google Ads 官方說明文件（查核於 2026 年 9 月）列出的資格條件是七天期間內每天 700 次廣告點擊，並依國家與網域分組計算；流量離這個量級還遠的品牌，不必把它當成近期會兌現的成效，但合規與事件驗收照樣要做。