Safari 封鎖身份域名之後：marketing services 要點揀

截至 2026 年 11 月，香港企業買 marketing services，已經不能假設「身份解析供應商會搞掂瀏覽器」呢件事會一直成立。Apple 在 iOS 27 的 Safari 開始封鎖與身份解析供應商相連的域名，The Trade Desk 同 ID5 都係被點名的例子。廣告技術業界嘅反應係把廣告請求搬離瀏覽器，走伺服器端。問題係，呢條路對投放預算嘅企業嚟講，係一個可以依賴嘅答案，定係另一場要跟住追嘅遷徙。

文章重點

• Safari 封鎖嘅係身份解析供應商嘅域名，唔係所有跨站追蹤；影響範圍同企業實際購買嘅受眾方式直接相關。
• 伺服器端遷移（包括 IAB Tech Lab 的 Trusted Server）可以換來一定自主權，但無改變 Google 同 Apple 掌握瀏覽器、作業系統同廣告技術平台嘅事實。
• Google 廣告技術反壟斷案嘅補救裁決，令 Prebid 有機會改變程式化拍賣嘅結算方式，但 Google 對失去 GAM 業務似乎唔太在意。
• 香港企業可以控制嘅，係自己網站上嘅標籤、自己嘅客戶數據同由自己 CRM 發出嘅轉化事件。
• 揀 marketing services 時，先問對方能唔能講清楚受眾嘅識別碼由邊度嚟、成交事件由邊個系統送出。

目錄

• Safari 今次封鎖咗啲咩
• 伺服器端遷移可以解決幾多
• Google 讓路之後，拍賣會變成點
• 市場推廣的工作內容是什麼？伺服器端轉移之後的三個變化
• Topkee 的觀點：把身份放回自家數據層
• 香港企業今季可以先做嘅三件事
• 常見問題

Safari 今次封鎖咗啲咩

Digiday 在 2026 年 11 月 3 日的報道指出，Apple 的 Safari 瀏覽器隨 iOS 27 開始封鎖與身份解析供應商相連的域名，而被點名的例子係 The Trade Desk 同 ID5。呢類供應商做嘅事，係把人嘅瀏覽行為同電郵地址連埋一齊，等廣告可以認得返同一個人。呢個做法支撐咗大部分以第三方名單為基礎嘅 marketing services 採購。

封鎖嘅對象係域名，唔係整套追蹤技術。企業如果仍然買以電郵為基礎、經第三方身份圖譜配對嘅受眾，嗰批受眾嘅覆蓋率就會隨住 Safari 用戶比例而縮。Safari 用戶多嘅市場，跌幅會更早見到。

Digiday Podcast 嗰集，新聞編輯 Seb Joseph 同資深廣告技術記者 Ronan Shields 傾嘅就係呢件事。Joseph 嘅判斷係，Apple 唔會只停在已經針對嘅公司同機制，會用各種方法抵銷呢類做法。企業聽到呢句，應該問嘅唔係「邊間供應商仲未被封」，而係「我嘅受眾定義有幾依賴嗰個機制」。

伺服器端遷移可以解決幾多

廣告技術公司同 IAB Tech Lab 推動把廣告請求搬到伺服器端，其中一個途徑係 IAB Tech Lab 嘅 Trusted Server 技術。原理係將原本由瀏覽器執行嘅廣告呼叫，移到一個受信任嘅伺服器上執行，令瀏覽器對廣告技術公司嘅行為少啲控制權。

Joseph 對 Trusted Server 嘅評價相當直接。佢話行業把它當成萬靈丹，但呢個用法係用錯了 Trusted Server 原本設計嘅目的，任何真係靠它繞過 Apple 嘅做法都捉錯用神。

Ronan Shields 就從權力結構講。佢認為廣告技術無法從 Apple 同 Google 手上奪回控制權，因為 Google 同 Apple 掌握瀏覽器，Google 另外仲掌握行動作業系統、廣告技術平台同雲端基礎設施。用 Trusted Server，廣告技術公司可以獲得一定程度嘅自主，但要守規矩先保得住。

對企業嚟講，呢兩句合埋一齊嘅意思係：伺服器端唔係一條通往「永久唔使理瀏覽器政策」嘅路。揀 marketing services 供應商時，如果對方把伺服器端講成可以永久解決身份問題，就要問佢具體靠邊個機制、嗰個機制受邊個管。Joseph 亦都提出，行業應該做得比監管者設下嘅底線更多，否則瀏覽器同平台總有辦法插手。

Google 讓路之後，拍賣會變成點

另一邊嘅變化來自 Google 廣告技術反壟斷案嘅補救裁決。裁決令 Prebid 有機會翻轉程式化拍賣：在新結構下，Google 嘅廣告交易平台要向 Prebid 嘅伺服器出價，而唔係由 Google 嘅廣告伺服器決定邊個勝出。

呢個改動對買家嘅實際意義，係出價同結算嘅位置唔同咗。過往由一個廣告伺服器做最終決定，之後要多方喺同一個拍賣節點出價。企業未必即刻見到價錢變化，但中介層嘅數量同角色會調整。

Shields 引述 Google 財報，指出第三方展示廣告網絡，即 GAM 嗰部分業務，表現又唔好。佢嘅判斷係 Google 對放手呢塊業務並唔會太在意，Prebid 想要就拎去。呢個判斷如果成立，拍賣結構嘅改動推進得會比預期中順。

對香港企業，購入 marketing services 時要留意嘅係：程式化拍賣嘅規則由平台之間嘅角力決定，買家可以選擇嘅係喺邊個層面落注。把預算交畀一個封閉嘅拍賣，同把受眾同轉化訊號留喺自己手上，係兩種唔同嘅風險。

市場推廣的工作內容是什麼？伺服器端轉移之後的三個變化

企業最常問嘅一條，就係市場推廣嘅工作內容係咩。2026 年嘅答案同幾年前有明顯分別：受眾設定、成效量度同歸因，正由瀏覽器搬去廣告主自己嘅伺服器同 CRM。呢三個環節嘅工作量同問責方式都唔同咗。

受眾設定方面，以前係喺平台後台揀興趣、揀第三方名單。而家要講清楚受眾由邊度嚟、用咩識別碼拼埋、Safari 用戶佔幾多，先決定預算點樣落 落 廣告。冇呢啲資料，預算分配就係靠估，亦會令 marketing services 報表上嘅受眾覆蓋率同實際對唔上。

量度方面，由「睇平台報表」變成「對齊口徑」。每個平台都按自己嘅歸因模型計數，同一筆成交喺 Google 同 Meta 後台可能各記一次。企業要有一份自己嘅紀錄，先可以判斷邊個渠道真係帶來收入，呢個係評估 marketing services 成效嘅前提。

歸因方面，成交事件嘅觸發點要放在企業自己嘅系統。銷售在 CRM 改階段、客戶落單、門店成交，呢啲事件可以經 API 或離線轉化數據流送回平台，唔使等瀏覽器再回訪先觸發像素。

換句話講，企業買 網上廣告 嘅時候，衡量工作做得好的標準由「買到幾多曝光」轉去「有幾多成交訊號係自己送得出」。呢個轉變對中小企嘅要求係要有人管好網站標籤同 CRM，唔再係單靠代理交報表。

如果公司冇人跟網站同 CRM，網上廣告 嘅日常就會停在開戶同交報表，受眾同歸因嘅工作無人接手。呢類公司要麼補人，要麼把這部分交給有數據系統嘅合作方。

Topkee 的觀點：把身份放回自家數據層

Topkee 嘅做法唔係把廣告呼叫搬去伺服器端，而係把身份同事件建在客戶自己嘅數據層。TTO 係 Topkee 自主研發嘅廣告投放同數據分析工具，亦係客戶數據平台，為每位潛在客戶或用戶生成唯一識別碼 ttoclid，入面帶住 UTM 參數、訪問時間、停留時間同瀏覽器資訊，可以跨裝置、跨平台同線上線下串連，建立單一客戶檔案。

TTO TAG 技術負責喺客戶自己網站收集訪客行為、建立受眾標籤名單，再自動回傳去 Google、Facebook／Instagram、Yahoo、Bing UET、Google Analytics 等平台。同一份受眾數據可以在多個平台重用，唔使每個平台各自向第三方身份供應商買比對。

轉化事件數據回傳係另一個環節。TTO 會把轉化後嘅客戶事件，按各廣告平台要求嘅格式回傳，強化平台 AI 對轉化嘅識別，令平台更容易認得邊啲行為值得學習。

離線轉化追蹤處理銷售階段。銷售團隊在 CRM 更新潛客階段時，事件會以 ttoclid 為身份鍵回傳至 TTO TAG，再送去 Google Analytics、Facebook Pixel、Google Ads Conversions、Bing UET 等；成交時填入金額，就可以回查該客戶來自邊個廣告主題同平台人員標籤。成交發生在線下或者後台，都仲歸因得到廣告。

將呢幾件嘢放埋一齊，企業可以得到嘅係一份由自己數據層出發嘅紀錄。ROAS Truth 把 Google、Yahoo、Facebook 廣告同 GA4 放喺同一把歸因標尺、同一份報告，一路追到已簽單交易，唔使靠每個平台自己嘅後台自評。當身份訊號被平台截斷，各平台自評更難互相比較，一份統一嘅紀錄就係企業判斷預算去留嘅依據。

數據所有權同數據可攜係最後一層保障。線索庫、跟進記錄同歸因數據由第一日就建在客戶自己嘅 TTO CDP、CRM 同像素上，採只讀授權，可以隨時撤銷，合作終止後帳戶同數據可以保留或者匯出。瀏覽器政策再變，歸因唔會歸零。

要講清楚嘅係，Topkee 呢套方案係第一方標籤加 ttoclid 加事件回傳加自有 CDP，唔係一個伺服器端繞路方案。企業如果問嘅係「點樣避開 Safari」，呢度答嘅係另一個問題，而答案直接影響 落 廣告 時可以依賴邊啲訊號：點樣令身份同成交紀錄唔再依賴瀏覽器裡面嘅第三方域名。

香港企業今季可以先做嘅三件事

第一步係盤點。列出目前買緊嘅受眾，逐項標明識別碼由邊個提供、係唔係第三方域名、Safari 用戶佔幾多。呢份清單會直接顯示邊部分預算暴露喺封鎖之下，亦係同供應商對話嘅起點。

第二步係把網站上嘅標籤同表單改成第一方部署，確保每個潛在客戶有可以跨裝置對得返嘅識別碼。呢步唔需要換廣告平台，只需要有人願意處理網站同 CRM 之間嘅對接。

第三步係揀一條可以驗證嘅渠道做壓力測試。用同一把尺比較各渠道由展示到簽單嘅表現，唔好只睇平台後台嘅轉化數。如果企業想睇下有冇現成工具可以承接，可以參考 Topkee Cloud 的全漏斗廣告平台，再對照 按推廣瓶頸揀方案的服務頁 睇下邊一類瓶頸同自己最接近，決定要先補哪一段。

唔適合做呢三件事嘅，係月預算好細、廣告只做品牌曝光、完全唔靠名單同成交嘅公司。呢類企業改動成本高過收益，繼續買曝光受眾更划算。

常見問題

Safari 封鎖身份解析域名，係唔係代表第三方 cookie 已死

唔係同一件事。今次封鎖嘅係與身份解析供應商相連嘅域名，針對嘅係用電郵配對瀏覽行為嘅做法。其他形式嘅跨站追蹤會受唔同嘅政策影響，時間表亦唔一樣。

香港企業應唔應該等伺服器端方案成熟先改

等嘅代價係喺過渡期繼續用覆蓋率會跌嘅受眾。企業可以同時做兩件事：短期維持現有投放，同時把第一方標籤同轉化回傳建好，唔使一次過換晒。

Trusted Server 係唔係一個可以依賴嘅長期方案

Digiday 嘅 Joseph 認為行業把 Trusted Server 當成萬靈丹係用錯了它嘅設計目的，Apple 亦會針對機制本身。把它當成過渡期嘅緩衝比較合理，當成長期保障就風險太大。

冇技術團隊嘅中小企可以點開始

由表單同 CRM 入手。確保每條線索都記錄來源廣告、素材同受眾，成交時可以填回金額，然後同供應商對一次數。呢兩步唔需要寫程式，但已經可以令線下成交歸因得返廣告。

統一歸因口徑會唔會令某啲渠道看起來差咗

好多時會。平台後台按自己嘅歸因模型計數，用同一把尺重算之後，部分渠道嘅回報會低過平台自評。呢個差異本身就係企業需要知嘅資訊。

Sources

1. Tim Peterson, "Can ad tech's server-side shift save it from Apple and Google?", Digiday, 2026-11-03. https://digiday.com/media-buying/can-ad-techs-server-side-shift-save-it-from-apple-and-google/
2. "The Digiday Podcast", Digiday, Apple Podcasts, 2026-11-03. https://podcasts.apple.com/us/podcast/the-digiday-podcast/id962605432