【Safari 27 上線後，轉換追蹤先審計五處：點擊碼、指紋名單與伺服器端】
Safari 27.0 在 9 月 17 日正式推出。WebKit 官方文章列出的新功能，由 6 月測試版的 58 項增至 83 項。對網店和行銷團隊來說，更需要留意的不在功能清單，而在追蹤保護的改動。
Safari 27.0 在 9 月 17 日正式推出。WebKit 官方文章列出的新功能，由 6 月測試版的 58 項增至 83 項。對網店和行銷團隊來說，更需要留意的不在功能清單，而在追蹤保護的改動。
這些改動並沒有寫在 Apple 的發布說明內。多間追蹤服務商和行業媒體分析 Safari 27 測試版的原始碼後，分析指出三類變化：點擊碼移除範圍擴大、部分追蹤標籤被列入指紋名單，以及個別廣告平台的端點在網絡層被封鎖。
Safari 27 把瀏覽器端可取得的訊號再收窄了一點。廣告平台的 AI 出價和自動優化，依靠的正是配對得上的轉換訊號。訊號少了，優化的依據也會變弱。
實際要弄清楚的，是數據在哪幾處開始流失、流失了多少。本文按次序審計五處，每一處都附上檢查方法、示範例子和取捨。
一、Safari 27 改了甚麼（以第三方分析為準）
綜合 PPC Land、Littledata、Stape 和 TAGGRS 的分析，改動可以分成三類。
1. 點擊碼移除（Link Tracking Protection）
分析指出，Safari 27 新增移除 Threads 的 xmt、YouTube 的 si，以及 X 的 twclid、cn、cxt。Google 的 gclid、Meta 的 fbclid 和 Microsoft 的 msclkid，在較早版本已經受到限制。UTM 參數不受影響。
2. 進階指紋保護（Advanced Fingerprinting Protection）
分析指出，LinkedIn Insight Tag、Tealium 和 Segment 新列入名單，存取 URL 參數、點擊碼、referrer 和瀏覽器儲存空間的能力受到限制。
3. 網絡層封鎖
分析指出，部分封鎖改為按目的地 IP 執行，涉及 Bing 和 LinkedIn 的端點。這類封鎖發生在腳本之外，單看標籤管理工具未必發現。
影響範圍要看清楚
點擊碼移除主要在兩種情況生效：無痕瀏覽（Private Browsing），以及從 Mail、Messages 開啟連結的時候。用戶自行開啟進階追蹤及指紋保護，也會觸發。指紋限制的適用範圍則較廣。
換言之，並非所有 Safari 用戶都會失去 fbclid。把全部數據落差歸咎 Safari 27，和完全忽視它一樣不準確。
來源說明： 以上細節來自第三方對測試版原始碼的分析，並非 Apple 公布的內容。正式版的實際行為，應以自己網站的實測為準。
二、第一處：點擊碼仍有多少到達網站
要回答的問題： 廣告點擊帶着的 gclid、fbclid、twclid，有多少成功到達網站，並寫入第一方 cookie？
檢查方法：
- 在 GA4 用「瀏覽器」和「作業系統」維度，把 Safari 與其他瀏覽器分開。Safari 在你的客群中佔多少，先看自己的數據，不要套用市場平均。
- 若網站、標籤管理工具或 CDP 有記錄完整落地 URL，可以統計各瀏覽器「帶點擊碼的廣告落地工作階段」比例。
- 同時檢查 UTM 是否完整。UTM 不受 Safari 27 影響，若 UTM 也斷了，問題多數出在轉址、短網址或網站本身。
- 把 9 月 17 日前後分開比較，看的是趨勢變化，而非單一時間點。
示範例子（示範數據，不代表任何品牌）：
| 瀏覽器 | 9 月 1 日至 16 日 帶 fbclid 比例 |
9 月 17 日至 30 日 帶 fbclid 比例 |
|---|---|---|
| Chrome | 91% | 90% |
| Safari | 74% | 63% |
Chrome 大致持平，Safari 明顯下跌，這才是值得深入追查的訊號。若兩者同步下跌，應先檢查廣告連結和網站轉址。
取捨： UTM 可以保留來源和活動層級的歸因，GA4 報表仍然可用；但 UTM 不能取代點擊碼，廣告平台配對個別轉換時仍需要點擊碼或其他配對鍵。
三、第二處：你的標籤或 CDP 是否在指紋名單上
如果網站使用 LinkedIn Insight Tag、Tealium 或 Segment，這一處要優先檢查。
檢查方法：
- 列出網站上所有第三方腳本，標出分析指出已列入名單的幾項。
- 逐一寫下它們依賴甚麼：讀 URL 參數？讀 referrer？寫 localStorage 或 cookie？這些正是分析指出受限的存取。
- 用 Safari 實測：一般模式和無痕模式各走一次「廣告落地 → 瀏覽產品 → 加入購物車 → 結帳」，記錄每一步的事件和參數是否齊全。
- 同一流程用 Chrome 再走一次作對照。
為甚麼 CDP 特別要留意
Segment 或 Tealium 若是全站數據的入口，影響不只廣告歸因。用戶識別、受眾建立、下游的電郵和 CRM 同步，以及報表數據，都可能同時缺漏。只檢查廣告轉換，容易低估影響範圍。
取捨： 把數據收集改到第一方網域或伺服器端，可以減少對瀏覽器的依賴。代價是要重新檢視同意設定、數據用途說明和維護成本，並非單純換一個網址就完成。
四、第三處：伺服器端是否帶齊第一方配對鍵
瀏覽器訊號收窄後，伺服器端事件的重要性上升。但伺服器端事件送得出，不等於配對得上。
Meta Conversions API（CAPI）要檢查的欄位
– 經 SHA-256 雜湊的電郵和電話。雜湊前先標準化，例如電郵去除前後空格並轉為小寫，電話加上國碼。 – fbc：必須是 _fbc cookie 的格式，即 fb.{subdomain}.{毫秒時間戳}.{fbclid}。 – fbp、用戶端 IP 和 user agent。
fbc 格式是常見漏洞
開發者社群的分析指出，把原始 fbclid 直接放進 fbc，CAPI 請求仍可能回傳 200，但這並非 Meta 文件要求的格式。回傳 200 只代表請求被接收，不代表配對成功。
示範（示範內容）：
錯誤：fbc = "IwAR1AbCdEf..."
正確：fbc = "fb.1.1727740800000.IwAR1AbCdEf..."Google 強化轉換（Enhanced Conversions）
由 2026 年 4 月起，Google Ads 把網站和潛在客戶的強化轉換合併為同一設定，可以接收代碼、Data Manager 和 API 傳入的數據。若網站早前只設定了其中一種，值得重新確認目前的數據來源是否完整。
取捨： 帶上越多第一方配對鍵，配對機會通常越高。但每一項都要有同意基礎，私隱政策亦要說明用途。配對率和合規要一起考慮。
五、第四處：瀏覽器與伺服器事件有否重複計算
同時使用 Pixel 和 CAPI，就要處理去重。Meta 的規則是：同一事件的 event_name 和 event_id 相同，而且兩邊在 48 小時內到達，才會被視為同一次轉換。
常見問題是瀏覽器和伺服器各自產生 event_id，結果兩邊對不上，同一張訂單被計算兩次。Safari 27 之後若加強伺服器端，更要確認這一步沒有出錯。
去重的完整檢查方法，可以參考早前的文章：Meta 數字高過 Shopify：用 event_id 去重。
六、第五處：三方對帳，Safari 獨立一欄
最後一處，是把真實訂單、GA4 和廣告平台放在同一張表比較，並把 Safari 獨立成一欄。
對帳次序：
- 真實訂單（網店後台）：唯一的基準。
- GA4 購買事件：看涵蓋率，即 GA4 購買 ÷ 後台訂單。
- 廣告平台回報（Meta、Google）：看趨勢，不要求與後台一致。
示範對帳表（示範數據，不代表任何品牌）：
| 週 | 後台訂單 | GA4 購買 | GA4 涵蓋率 | GA4 購買中 Safari 佔比 | Meta 回報購買 |
|---|---|---|---|---|---|
| 9 月 8 日至 14 日 | 400 | 352 | 88% | 41% | 210 |
| 9 月 15 日至 21 日 | 410 | 349 | 85% | 37% | 198 |
| 9 月 22 日至 28 日 | 405 | 336 | 83% | 34% | 186 |
這張示範表的讀法：後台訂單穩定，GA4 涵蓋率和 Safari 佔比同步下跌，指向 Safari 端的數據流失。若 Safari 佔比不變而涵蓋率下跌，就要先查其他原因，例如結帳頁腳本或付款跳轉。
要點： 看連續幾週的差距趨勢，不要被單日波動牽着走。
七、限制與不要做的事
不要追求三方數字完全一致。 不同系統的計算方式、歸因窗口和時區本來就不同。目標是差距穩定、可以解釋。
不要用指紋式補救。 例如用瀏覽器特徵識別用戶，或把點擊碼改名繞過移除。這與瀏覽器的私隱方向相反，也可能在下一個版本被封鎖。
伺服器端不等於免同意。 改由伺服器傳送數據，用戶同意和私隱政策的要求仍然適用。
不要把所有落差歸咎 Safari 27。 點擊碼移除主要在無痕瀏覽和 Mail、Messages 開啟的連結生效，其餘落差可能來自其他原因。
分析基於測試版原始碼。 正式版行為可能有出入，以自己網站的實測為準。
八、檢查清單與下一步
五處審計清單：
- GA4 已按瀏覽器分開，並比較 9 月 17 日前後的趨勢
- 統計各瀏覽器帶點擊碼的落地比例；UTM 完整
- 列出網站第三方腳本，標出 LinkedIn Insight Tag、Tealium、Segment
- 用 Safari 一般模式和無痕模式各走一次完整購買流程
- CAPI 帶上經標準化和雜湊的電郵、電話
fbc使用_fbc格式，而非原始fbclid- Google 強化轉換的數據來源已確認
- Pixel 與 CAPI 使用相同的
event_name和event_id - 每週對帳表：後台訂單、GA4、廣告平台，Safari 獨立一欄
- 同意設定和私隱政策涵蓋伺服器端數據
常見問題
Safari 27 之後，Meta 廣告還能追蹤轉換嗎？
可以。分析指出受影響的主要是部分情況下的點擊碼和指定的追蹤標籤。帶齊配對鍵的 CAPI，可以補回部分訊號。
UTM 會被移除嗎？
根據目前的分析，UTM 參數不受影響，GA4 的來源和活動報表仍然可用。
所有 Safari 用戶都會失去 fbclid 嗎？
不會。點擊碼移除主要在無痕瀏覽，以及從 Mail、Messages 開啟的連結時生效，或用戶自行開啟進階保護。
小型網店一定要做伺服器端追蹤嗎？
不一定。先用 GA4 看 Safari 佔比和涵蓋率變化。若影響不大，先確保 UTM 和現有設定正確；若落差明顯，再評估伺服器端的成本和效益。
CAPI 回傳 200，是否代表設定正確？
不代表。200 只表示請求被接收。配對鍵格式是否正確，例如 fbc，要另外核對。
一句總結
按點擊碼、指紋名單、配對鍵、去重和對帳五處逐一審計，就能知道數據在哪裡流失，再決定先補哪一處。