B2B 網站個人化與資料隱私：如何維持合規

大多數 B2B 個人化專案在第二週都會撞上同一堵牆。行銷已備好區隔與標題版本，接著法務有人問起訪客識別在 GDPR 下如何運作，卻沒有人寫下過答案。專案只好暫停。

這篇文章就是我們希望能寫成文字的答案。它涵蓋 B2B 網站個人化的資料隱私，依據引發最多疑問的三套規範（GDPR、歐盟關於 Cookie 與裝置存取的 ePrivacy 規範，以及加州的 CCPA/CPRA），說明各自實際要求什麼，並提供可交給法務團隊的上線檢查清單。本文不構成法律意見。目標是讓行銷與法務更快展開同一場對話，並附上原始資料來源連結，讓您的法律顧問可以查核。

為什麼 B2B 個人化有不同的隱私面貌

大多數隱私指引都是針對消費者情境撰寫的：跨購物網站的廣告追蹤、販售給第三方的行為檔案。B2B 網站個人化通常看起來很不一樣：

• 主要輸入資料是公司層級資料（產業、規模、地點、使用的技術），通常由訪客的 IP 位址推得。
• 產出相當溫和：製造業訪客看到的是製造業客戶案例，而不是金融科技業的。
• 許多訪客來自您已經在銷售或鎖定的公司，因此向他們展示相關內容有合理的商業理由。

但這些都不代表 B2B 個人化可以豁免於隱私法規。每個 IP 位址背後仍是一個人，而法律保護的是那個人，不是公司。改變的是風險程度，以及哪種法律基礎較為可行。把這個分類做對，就完成了大部分的工作。

GDPR：IP 位址的問題

法務會問的第一個問題是：IP 位址算不算個人資料？誠實的答案是「通常算，取決於由誰持有」。在 Breyer 案（Case C-582/14）中，歐盟法院認定，如果網站經營者具有法律手段，能結合網路服務供應商持有的額外資訊來識別訪客，那麼動態 IP 位址對該經營者而言就是個人資料。此案是依據舊的資料保護指令判決，但 GDPR 在第 4(1) 條對個人資料的定義中，明確將「線上識別碼」列為可識別個人的資訊，因此同樣的推論依然適用。

我們的看法：請假設您處理的每個 IP 位址都是個人資料來規劃。主張相反的觀點省不了多少事，反而會讓您的文件在監管機關眼中顯得閃躲。

選擇法律依據

GDPR 第6條列出六種法律依據，其中兩種與網站個人化相關：

這裡有兩個細節很重要。第一，Breyer 案的新聞稿也提到法院的觀點：網站經營者處理訪客資料可以具有正當利益，前提是必須與訪客的權利進行權衡。這正是您的 LIA 必須呈現的權衡過程。第二，如果個人化屬於直接行銷的一部分，第 21(2) 條與第 21(3) 條賦予訪客絕對的反對權：一旦訪客提出反對，您就必須停止。請在上線前就建好退出機制，而不是等到第一次被投訴之後。

GDPR 失誤可能的代價

根據Article 83(5)，違反處理原則、Article 6 的合法依據規定、Article 7 的同意條件，以及 Articles 12 至 22 的資料主體權利，可處以最高2,000萬歐元或全球年營業額 4% 的罰款，以較高者為準。這些是上限，而非一般罰款金額。對中型市場的 B2B 團隊來說，更實際的代價是主管機關的調查，迫使您暫停個人化，同時補齊您早該備妥的文件。

ePrivacy：「無 Cookie」最常被誤解的地方

ePrivacy 指令（2002/58/EC，第 5(3) 條）是 Cookie 橫幅背後的規定。它要求在使用者裝置上儲存資訊或存取其中資訊之前，必須取得同意，除非該儲存或存取是提供使用者所要求服務的絕對必要措施。它與 GDPR 同時適用，而且不論該資訊是否為個人資料。

在英國，對應的規定在 PECR 中。ICO 的指引明確指出，同意必須主動且清楚地給予，而且僅具輔助或便利性質的 Cookie 仍然需要取得同意。個人化 Cookie 就屬於這一類。

這是許多廠商部落格略過的部分。許多個人化行銷宣稱「伺服器端、無 Cookie，所以不需要同意」。這太過簡化了。EDPB 的 Guidelines 2/2023 on the technical scope of Article 5(3)（2024 年 10 月最終版）指出，僅以 IP 位址為基礎的追蹤可能屬於第 5(3) 條的範圍，除非您能確保 IP 位址並非來自使用者的裝置，否則必須視為適用。同一份指引也指出，當用戶端程式碼指示瀏覽器將識別碼傳送給您時，第 5(3) 條也同樣適用。

實務上的意義：

• 在伺服器端進行一次性的 IP 查詢，只用來為當前頁面瀏覽挑選標題，是風險最低的模式。有些律師仍會希望它有同意作為依據，或依 EDPB 指引進行清楚的豁免分析，所以請詢問您的律師。
• 利用 IP 位址在不同頁面或工作階段間追蹤訪客，就屬於追蹤行為，而 EDPB 的見解是，這與 Cookie 一樣需要進行同意分析。
• 任何會在瀏覽器中讀取或設定識別碼（Cookie、本機儲存空間、指紋辨識信號）的 JavaScript 程式碼片段，都必須在執行前取得同意，除非是絕對必要的。

時程上要注意一點：原本預計取代該指令的 ePrivacy Regulation 已經取消。歐盟執委會在其2025年工作計畫中宣布將撤回該提案，現行指令及各國實施法律繼續有效。不要等新的歐盟 Cookie 規範出來才好好設定同意機制。

CCPA/CPRA：真的適用於您嗎？

加州的法律只適用於在加州營業、且至少符合一項門檻的營利事業。根據加州隱私保護局，這些門檻是：

1. 年度總營收達2,662.5萬美元以上（自2025年1月1日起調整後的金額）。
2. 購買、銷售或分享10萬名以上加州居民或家戶的個人資訊。
3. 年營收有 50% 以上來自販售或分享加州居民的個人資料。

對 B2B 團隊來說，重要的歷史是：針對企業聯絡資料與員工資料的暫時豁免已於 2023年1月1日到期。在加州用公司筆電瀏覽您網站的買家，在法律上就是消費者。

如果您在適用範圍內，與個人化相關的義務包括：

• 在隱私權政策中揭露您為個人化蒐集由 IP 推得的資料，以及使用的資料類別。
• 如果資料擴充或廣告合作夥伴取得訪客資料的方式構成「出售」或「分享」（分享涵蓋跨情境行為廣告），請提供「請勿出售或分享我的個人資訊」連結，並遵守退出請求。
• 根據CPPA 常見問答，須在45個日曆天內回應查閱、刪除或更正的請求；若通知當事人，可再延長45天。

根據 CPPA 公告，罰款已於 2025 年 1 月 1 日依通膨調高：每次違規最高 2,663美元、每次故意違規最高 7,988美元的行政罰款。美國其他州有各自的全面性隱私法，門檻不同，因此如果您有來自這些州的可觀流量，請分別評估，不要假設加州的分析就能涵蓋。

可行的框架：三個資料層級

要讓這件事變得可管理，最簡單的方法是在建立任何東西之前，先將個人化使用的每項輸入資料分類。

我們的看法：先以第 1 層級上線。向物流公司展示您的物流客戶案例，不需要知道閱讀者本人的任何資訊。大多數明顯的個人化成效（產業標題、相關佐證、依公司規模強調價格）都屬於第 1 層級。第 2 和第 3 層級能增加價值，但也會增加對同意的依賴和文書作業，因此請在第 1 層級衡量完成且穩定後再加入。

逐步說明：合規上線

1. 依同意狀態區分體驗

常見的錯誤是在訪客點擊「接受」之前封鎖所有個人化。更好的設計是：

1. 取得同意前：只進行來自伺服器端查詢的第1級個人化，不在裝置上儲存任何識別碼，也沒有行為歷史。
2. 同意個人化 Cookie 之後：開始記錄回訪與互動情況，並將其用於第二層級規則。
3. 表單送出後：在您的隱私權聲明與法律依據涵蓋範圍內，將客戶與 CRM 資料（第3級）連結。

用最樸實的方法測試：用乾淨的瀏覽器設定檔開啟網站，拒絕所有選項，然後檢查 DevTools 中的 Application 分頁。不應出現任何個人化 Cookie 或本機儲存鍵值。接著選擇接受，再檢查一次。

2. 讓同意類別與實際情況相符

接受「分析」Cookie 的訪客，並不代表同意「個人化」。如果您的同意管理工具有細分類別，請新增個人化類別（或將個人化歸入能準確描述它的既有「功能」或「行銷」類別），並確保個人化腳本專門依該類別的同意狀態運作。

3. 稽核資料流中的每個供應商

針對每個會接觸訪客資料的廠商（IP 資料補充、分析、CDP、CRM、同意管理工具），請記錄：

• 他們從您的網站接收哪些資料，又回傳哪些資料。
• 他們在哪裡儲存和處理資料，以及任何移轉至歐洲經濟區以外的資料適用哪種移轉機制。
• 他們是否將您的訪客資料用於自家產品。如果是，他們可能是控制者而不是受託處理者，這會改變您的合約與隱私權聲明。
• 是否已簽署資料處理協議，以及存放在哪裡。

合約只涵蓋一半；另一半是每家供應商實際上如何保護資料。如果您的團隊沒有內部資安專業，可以在簽約前請外部的資安服務審查供應商的存取控管與儲存方式。

這類稽核常會發現的例子（示範用）：某個分析工具的條款允許它使用客戶資料來建立自家的受眾產品。這並不是受託處理者關係，您要嘛重新議約、適當揭露，要嘛改用維持受託處理者角色的工具，例如只依您的指示處理資料的個人化分析設定。

4. 撰寫三份文件

• 隱私權政策段落。您收集什麼（由 IP 推得的公司資料、經同意的行為資料）、為什麼收集（為了顯示相關內容）、法律依據、保存期限、供應商，以及如何提出異議。
• 正當利益評估。目的測試（向企業訪客展示相關內容）、必要性測試（為何公司層級的資料就已足夠、不需要更多）、權衡測試（無敏感資料、公司層級的輸出、容易提出異議、保留期間短）。
• Cookie 政策。個人化系統設定的每個 Cookie 或儲存鍵值、其用途、存續期間與類別。

5. 設定您能確實執行的保存期限

GDPR Article 5(1)(e) 的儲存限制原則，意指個人資料的保存時間不得超過目的所需。法律並未規定具體天數，因此請自行訂定並說明理由。範例：行為資料保存 90 天，補強後的帳戶資料保存 12 個月，以涵蓋一般 B2B 銷售週期。無論選擇什麼，都要在工具中設定，讓刪除自動進行。

6. 演練資料主體請求

依據 Article 12(3)，您必須在無不當延遲的情況下、於一個月內回應存取、刪除和反對的請求，必要時可再延長兩個月。加州則給予 45 天。上線前先做一次測試請求：找一位造訪過網站的同事，試著找出、匯出並刪除您的技術堆疊中所有關於他的資料。如果您的訪客辨識工具無法依 IP 位址或聯絡人做到這一點，那麼在上線前您就有問題要解決。

常見的法規遵循錯誤

把公司資料稱為「匿名」

識別一家公司並不等同於處理匿名資料。在大多數實際情境中，您用來查詢的 IP 位址就是個人資料。請在文件中明確說明，依據有記錄的法律依據處理，然後繼續前進。

以為「伺服器端」就等於「不需同意」

如上所述，EDPB 對 Article 5(3) 的解讀範圍廣泛，足以涵蓋以 IP 為基礎的追蹤與用戶端識別碼收集。伺服器端、按請求進行的公司查詢是風險最低的設計，但這仍是需要與法律顧問討論的設計選擇，而不是自動豁免。

沒有反對途徑

如果您的合法依據是正當利益，訪客就可以提出反對。隱私權政策裡一個連到沒人看的電子信箱的連結，並不算數。請提供一個能關閉個人化的設定，並在個人化引擎中確實遵守。

未檢查來源就匯入第三方意圖資料

第三方意圖資料通常建立在跨網站瀏覽之上。如果供應商無法說明這些資料的收集是如何取得同意或其他法律依據的，您一使用就會承接這個弱點。簽約前請索取資料來源文件，並優先使用第一方行為信號。我們在用於 B2B 網站個人化的意圖資料指南中更詳細說明了其中的取捨。

無限期保留

個人化工具通常預設保留所有資料。請檢查技術堆疊中每項工具的保留設定，而不只是主要的個人化平台。

上線前檢查清單

1. 已完成資料盤點，每項輸入都已歸類為第1、2或3級。
2. 每個層級都記錄了法律依據，第一層級附有 LIA。
3. IP 查詢及任何用戶端程式碼的 ePrivacy 分析已經法律顧問審閱。
4. 同意橫幅有涵蓋個人化的類別，並經由乾淨瀏覽器測試確認在取得同意前不會儲存任何資料。
5. 已與每家供應商簽署 DPA；已記錄儲存位置與傳輸機制。
6. 已更新隱私權政策與 Cookie 政策。
7. 異議與退出流程正常運作，且個人化引擎會遵守。
8. 每個工具都已設定保存期限。
9. 已在 GDPR 與 CCPA 規定期限內完成測試用資料主體請求。
10. 已依三項門檻確認 CCPA 適用範圍；若在其他美國州有流量，也已盤點當地法律。

為什麼隱私限制反而能促成更好的個人化

這是觀點的部分，有些團隊會不同意。在隱私規範內工作，反而會把您推向那些本來就比較有效的個人化做法。

公司層級的區隔能觸及每一位訪客，包括拒絕 Cookie 的人，因此您的第一次測試不會只限於點了「接受」的那一部分人。較少、較廣的區隔（例如依產業與公司規模分成五、六個）比依瀏覽模式建立的數十個微區隔更容易撰寫好內容，而且每個區隔都有足夠的流量可供衡量。當您無法依賴第三方資料時，您會投資在建立於人們實際如何使用您網站的第一方資料策略上，而這正是反映他們對您特別感興趣的資料。

如果您想為這些分眾找個起點，我們關於能轉換的公司屬性分眾的文章說明了如何挑選，公司層級訪客識別如何運作則解釋了 IP 查詢能告訴您什麼、不能告訴您什麼。

起步而不卡在法務審查

對大多數 B2B 團隊來說，真正的風險不是罰款，而是因為沒有人給法務一份具體設計可以審查，導致來回溝通好幾個月。所以給他們一份：

1. 一頁式資料流程圖，說明 IP 查詢、回傳的內容，以及儲存的資料。
2. 上方的層級表格，依您的技術堆疊填寫完成。
3. LIA 草稿與隱私權政策段落。
4. 全新瀏覽器的同意測試結果。

接著在幾個高流量頁面上推出第1級，衡量30天，等同意機制運作正常且數字證明值得時，再加入第2級。

Markettailor 符合這個執行順序：它的公司屬性分眾以公司層級資料運作，讓您在同意相關工作完成之前就能先從第1級規則開始。如果您想在和法務討論前先比較方案，請查看 Markettailor 價格。