第三方 Cookie 是由使用者目前瀏覽的網站以外的網域所設定的資料，常見於嵌入網頁的廣告、社群外掛與跨站分析服務，能在不同網站之間辨識同一個瀏覽器。Safari 與 Firefox 預設就會封鎖或隔離這類資料；Chrome 預設允許，但使用者可以在設定中封鎖，無痕模式也預設封鎖。對企業來說，依賴跨站辨識的再行銷名單與轉換歸因可能因此出現缺漏，可以準備的方向是經營第一方資料，並把追蹤改以第一方 Cookie 與自己控管的伺服器為主。以下整理差異、瀏覽器現況、影響範圍與準備步驟。
第三方和第一方 Cookie 差在哪
| 項目 | 第一方 | 第三方 |
|---|---|---|
| 判斷方式 | 網域與協定和網址列上的網站相同 | 網域或協定和網址列上的網站不同 |
| 設定者 | 正在瀏覽的網站 | 嵌入的廣告、外掛或其他服務 |
| 常見用途 | 登入、購物車、GA4 流量分析 | 跨站廣告、跨站分析、共用登入元件 |
| 跨站傳送條件 | 不需要跨站 | 須設定 SameSite=None，並同時設定 Secure |
同一個服務屬於哪一方，取決於使用者當下瀏覽的網站：在廣告平台自己的網站上，它寫入的是第一方 Cookie；被嵌入到你的網站時，就成了第三方。MDN 也指出，第三方伺服器可以把嵌入在許多網站上取得的資訊組合起來，建立使用者的瀏覽輪廓，這種用途因此被稱為追蹤，也是瀏覽器限制它的原因。基本運作與工作階段、持續型的分類，見網站 Cookie 是什麼。
各瀏覽器怎麼處理第三方 Cookie
- Safari：WebKit 官方文件說明，Safari 的 Intelligent Tracking Prevention（ITP）預設封鎖所有第三方 Cookie；使用者介面中相關的是「防止跨網站追蹤」設定。
- Firefox：加強型追蹤保護的標準模式預設在所有網站封鎖跨網站追蹤用的項目，其他第三方資料則被隔離，每個網站使用各自獨立的儲存空間。
- Chrome：預設不封鎖，使用者可以在「隱私權和安全性」中的「第三方 Cookie」選擇封鎖，無痕模式預設封鎖。Google 在隱私權沙盒官方部落格宣布，會維持讓使用者自行選擇是否允許的做法，不推出新的獨立提示；後續也宣布停用 Topics、Protected Audience、Attribution Reporting API 等多項隱私權沙盒技術，CHIPS 與 FedCM 則會繼續支援。
換句話說，同一個網站的訪客中，有一部分人的瀏覽器會擋下跨站資料，比例取決於訪客使用的瀏覽器與設定。各瀏覽器的政策仍可能調整，規劃時請以官方公告為準。
對再行銷與轉換歸因的影響
受影響的是需要「跨網站認出同一個人」的功能。Chrome 說明中心也提醒，封鎖後某些依賴這類資料的網站可能無法正常運作。常見的影響有：
- 再行銷名單：靠跨站辨識在別的網站認出你的訪客時，預設封鎖的瀏覽器上名單可能累積較慢。這時可以搭配平台的顧客名單功能，前提是資料來源合規。
- 轉換追蹤：Google 代碼管理工具的轉換連接器，是把廣告點擊資訊存在網頁所屬網域的第一方 Cookie 與本機儲存空間，受跨站限制的影響較小；但 Safari 偵測到透過網址參數跨站追蹤時，會縮短到達網頁上由 JavaScript 建立的 Cookie 效期，點擊後隔較久才成交的訪客，可能無法對應回原本的點擊。
- 歸因與報表：辨識不到的接觸點不會出現在轉換路徑中，各平台看到的路徑也不同，數字落差的原因見歸因模式的說明。
企業可以先做的準備：經營第一方資料
不依賴跨站追蹤的根本做法，是讓顧客在你的網站或服務中主動留下資料：會員註冊、詢價表單、電子報、官方帳號好友。取得時清楚告知用途，需要同意的項目另外取得同意，這些資料才能放心用在後續溝通與廣告評估。
在評估工具上，可以從以下幾項著手：
- 確認分析工具使用第一方 Cookie：GA4 官方說明代碼使用第一方 Cookie 識別使用者與工作階段。
- 設定 Google Ads 強化轉換：把網站代碼或匯入的離線事件中、經雜湊處理的第一方轉換資料傳給 Google，用來提升轉換評估準確度；分成網站強化轉換與待開發客戶強化轉換兩種。
- 統一網址參數：廣告與社群連結的 UTM 命名一致，跨管道比較時資料才對得起來。
伺服器端追蹤與轉換 API 的概念
另一個方向是把部分資料處理從訪客的瀏覽器移到自己的伺服器：
- 伺服器端代碼：Google 開發者文件說明，伺服器容器不在使用者的瀏覽器或手機上執行，而是由你控管的伺服器執行，你可以完全掌控資料的形狀與傳送路徑；在選擇送往其他位置之前，只有你能存取伺服器中的資料。伺服器可以架在自己的 Google Cloud 專案或其他環境。
- Meta 轉換 API：在廣告主的伺服器與 Meta 的轉換 API 端點之間建立連線，從伺服器傳送事件；和 Meta 像素（舊稱 Facebook Pixel）並用時，要確認事件已去重複並正確比對，設定方式見Meta 像素的事件設定。
要注意，伺服器端架構改變的是資料傳送的路徑，不是取得同意的義務。訪客拒絕分析或廣告用途時，伺服器端也應依同意狀態決定是否轉送資料。
盤點網站上的第三方 Cookie
- 用 Chrome 開發人員工具開啟「Application」中「Storage」下的「Cookies」，選取網站來源；第三方項目具有 SameSite=None 屬性，工具會在旁邊顯示警告圖示。
- 對照每一筆的網域，找出來源服務，例如嵌入的影片、社群外掛、線上客服、廣告代碼。
- 判斷是否還需要：不再使用的外掛與代碼直接移除，需要的寫進隱私權政策與同意設定。
- 在 Chrome 設定中開啟封鎖，或改用 Safari 測試登入、嵌入表單、金流與客服等功能是否正常。
- 功能異常時，和服務供應商確認是否支援 CHIPS 這類分割儲存的做法，或其他不依賴跨站資料的方案。
常見問題
封鎖第三方 Cookie 會影響 GA4 嗎？
GA4 代碼使用第一方 Cookie 辨識使用者與工作階段，不靠第三方 Cookie 運作；但訪客拒絕分析用途，或瀏覽器清除儲存資料時，數據仍會受影響。
網站上的 YouTube 影片或社群外掛會寫入第三方資料嗎？
可能會。MDN 說明這類資料可以由透過 iframe 嵌入網站的第三方內容設定，建議用開發人員工具確認實際寫入了哪些項目，再寫進隱私權政策與同意設定。
第一方 Cookie 就不需要訪客同意嗎？
不一定。是否需要同意，要看用途與網站面對的地區法規，而不是由哪個網域設定；用於分析或廣告的第一方 Cookie，在部分地區仍須先取得同意。
伺服器端追蹤可以完全取代網站上的代碼嗎？
伺服器端代碼是改由你控管的伺服器處理與轉送資料，網站仍要把事件送進這台伺服器，所以導入前要規劃網站端與伺服器端的分工，以及同意狀態怎麼一起傳遞。
還沒有資源導入伺服器端架構，可以先做什麼？
先確認重要事件與網址參數命名正確、廣告轉換追蹤以第一方 Cookie 運作，並開始經營會員、電子報等自有名單。基礎資料整理好，之後評估伺服器端架構時也比較容易判斷效益。
本文由京采數位科技整理。我們自 2005 年起提供官網設計、系統開發與 Google SEO 服務，實際案例可見成果與案例。
想直接討論你自己的網站狀況，或需要一份初步的搜尋機會評估？
相關主題
下一步
建議先用瀏覽器開發人員工具盤點網站上的第三方 Cookie，再檢查轉換追蹤、強化轉換與自有名單的設定。京采的轉換優化與數據追蹤服務可以協助檢查代碼與儲存項目、規劃以第一方資料為主的追蹤架構，並評估伺服器端代碼或轉換 API 是否適合你的網站。想了解你的追蹤受影響多少，歡迎與我們聯繫。
