隱私權優先：Adobe Analytics Cookie 策略

10 分鐘

style

article-header-section

隨著隱私法規日益嚴格，且第三方 Cookie 逐漸消失，Adobe Analytics 提供了以隱私為先的解決方案，例如 CNAME 追蹤和第一方裝置 ID (FPID)，以確保數據的準確性和合規性。本文將說明如何結合同意管理平台運用這些策略，在尊重使用者同意的前提下，提供卓越的數位體驗。

Cookie 在網站分析中對於理解使用者行為至關重要。在 Adobe Analytics 中，Cookie 有助於識別訪客、追蹤工作階段，並度量諸如頁面瀏覽量、點擊量和轉換率等行為，從而實現更深入的洞察、更優異的效能以及更有效的行銷。

然而，日益嚴重的隱私問題和瀏覽器限制已限制了 Cookie 的使用——尤其是第三方 Cookie——並縮短了第一方 Cookie 的使用壽命。這些變化對傳統追蹤方式提出了挑戰，迫使策略轉變。

為適應這些變化，許多團隊正轉向採用基於 CNAME 的實作方式和第一方裝置 ID (FPID)，以在尊重使用者隱私的同時，保持強大的追蹤能力。

在本文中，我們將探討瀏覽器隱私變化如何影響 Adobe Analytics，比較不同的追蹤方法，並展示如何實施以隱私為先的解決方案，如 CNAME 和 FPID。

瀏覽器隱私限制的演進

主要瀏覽器廠商已實作以隱私為重心的更新，以限制第三方 Cookie 的使用，甚至限制第一方 Cookie 的功能。顯著變更包括：

Safari (ITP)： 引入了智慧型追蹤防護（Intelligent Tracking Prevention，ITP）機制，以封鎖第三方 Cookie，並將第一方 Cookie 的過期時間限制為僅 7 天。
Firefox (ETP)： 增強型追蹤防護（Enhanced Tracking Protection，ETP）會預設封鎖第三方 Cookie，並防止跨站追蹤。
Chrome（隱私權沙箱）： 旨在以 FLoC（現為 Topics API）和受保護的客群目標選擇等替代方案，逐步淘汰第三方 Cookie。
Edge（預防追蹤）： 預設會封鎖第三方 Cookie 和追蹤程式，並提供不同層級的隱私保護（基本、平衡、嚴格），供使用者依需求選擇不同程度的防護。

主要瀏覽器的隱私權與追蹤保護設定之比較

以下是主要瀏覽器多年來實施隱私相關主要變更的視覺化呈現。

主要瀏覽器進行的隱私權相關重要變更

瀏覽器變更對 Adobe Analytics 的影響

跨網域追蹤：
- 過去，利用 Demdex Cookie 進行跨網域追蹤，能夠實現跨不同網域名稱（例如網域名稱 A 和網域名稱 B）的訪客無縫關聯，確保單一訪客的數據能被準確彙報。
- 然而，隨著第三方 Cookie 受到限制，訪客在跨網域時會被視為不同的使用者進行追蹤，這導致報告中的數據出現碎片化，且使用者行為歷程的洞察也變得不夠準確。 廣告/行銷活動歸因：
- 第三方 Cookie 限制會中斷轉換歸因，使行銷人員更難以度量廣告效益及準確追蹤參與度。
- 行銷活動績效報告可能會受到影響，尤其是針對跨網站或跨裝置的互動。

訪客身分識別：
- 在 Safari 等對 Cookie 過期政策設限嚴格的瀏覽器中，用於識別訪客的第一方 Cookie 現在的過期時間最短僅為 7 天（在某些情況下甚至更短）。
- 這表示，當訪客在 Cookie 過期後再次造訪網站時，會被視為 新訪客進行追蹤。 工作階段追蹤：
- Cookie 過期政策也可能影響工作階段的連續性，導致分析報告中的工作階段數量被誇大，或是使用者歷程的記錄不完整。

根據隱私權轉換發展追蹤方法

隨著瀏覽器對第三方和第一方 Cookie 的限制日益嚴格，Adobe Analytics 的實作方式必須做出調整，以維持數據的連續性並保護使用者隱私。這些變更可能會造成訪客數據的碎片化、中斷工作階段，以及妨礙歸因分析。

為應對此情況，已出現了注重隱私的追蹤策略：

基於 CNAME 的追蹤
透過將數據收集路由至子網域名稱（例如 smetrics.yourdomain.com），Cookie 被設為第一方 Cookie，從而繞過許多瀏覽器的追蹤封鎖。
第一方裝置 ID (FPID)
FPID 是伺服器產生的ID，儲存在瀏覽器中，它透過 Web SDK 傳送，以協助建立 ECID，同時符合隱私權規範。

這些方法可改善數據品質，但需要使用者同意才能符合 GDPR 和 CCPA 等法規，因此同意管理平台 (CMP) 整合至關重要。

下一節將說明如何將 CMP 與 Adobe Web SDK 整合，以在啟用 CNAME 和 FPID 等方法的同時尊重使用者偏好設定。

將同意管理整合至 Adobe Analytics（基於 Web SDK 的實作）

GDPR、CCPA 和 ePrivacy 等現代隱私權法均要求在設定 Cookie 或追蹤 ID 之前，須獲得使用者的同意。在採用 Web SDK、CNAME 或 FPID 的 Adobe Analytics 實作中，數據收集必須基於使用者的同意進行控制。

本節說明如何透過 Web SDK 將同意管理平台 (CMP) 與 Adobe Analytics 整合，以確保在數據處理上優先考量隱私並符合法規要求。

在 Adobe Analytics 中為何同意很重要

用於初始化 Experience Cloud ID 的 FPID，必須在獲得使用者同意後才能設定。
採用 CNAME 追蹤方式時，也必須在獲得許可後才能開始傳送任何數據。
Web SDK 提供了相關工具，可延遲追蹤操作，直至確認獲得使用者同意為止。
（請洽詢您的法律團隊，瞭解何時可以設定 FPID。）

逐步 CMP 整合

在 Web SDK 之前載入 CMP
確保您的 CMP（例如 OneTrust、TrustArc）在 Web SDK 載入之前先行載入，以便在開始追蹤之前就能獲知使用者的同意狀態。
在 Web SDK 擴充功能中設定同意
在 Adobe Tags (Launch) 中：
- 將預設同意狀態設定為 待處理 以暫停追蹤。
- 使用數據元素從 CMP 讀取同意訊號，並將其傳遞至 Web SDK。

本官方指南「使用 Platform Web SDK 擴充功能，透過同意管理平台 (CMP) 實作同意）」，會逐步說明在 Adobe Tags 中使用內建同意處理或整合第三方 CMP 來設定同意的步驟。

使用 setConsent() 命令套用同意狀態

一旦使用者透過 CMP 接受追蹤，請觸發以下 Web SDK 命令以應用該同意狀態：

alloy("setConsent", {

consent: [{

standard: "Adobe",

version: "2.0",

value: {

collect: {

val: "y"

}

}]

});

此舉將啟用追蹤功能，並允許初始化 FPID 和 ECID 的值。

在獲得同意前暫緩所有追蹤操作

設定 Adobe Tags 規則以：

在確認同意狀態之前，暫緩 sendEvent 呼叫。
防止 Web SDK 在 CMP 觸發同意之前設定任何識別碼（ECID、FPID）。

同意管理擴充功能（根據您選擇的 CMP 提供者）可協助簡化 Launch 中的這項設定。

在同意狀態透過 Web SDK 和 CMP 正確整合至 Adobe Analytics 後，下一步就是實作隱私權優先追蹤。下一節將深入探討如何設定基於 CNAME 的追蹤和 FPID，以符合瀏覽器隱私權變更，同時保持合規性和數據準確性。

1. 基於 CNAME 的 Analytics 實作

基於 CNAME 的 Analytics 實作可讓您透過網域路由追蹤呼叫，而非直接使用 Adobe Analytics 伺服器。此方法可確保降低基於瀏覽器的追蹤預防機制封鎖追蹤呼叫的可能性，因為 Cookie 會寫入您的網域下（例如 smetrics.yourdomain.com）。

AppMeasurement.js 和 AEP WebSDK 都支援此方法。

基於 CNAME 的追蹤的優點

克服封鎖第三方 Cookie 的瀏覽器限制。
確保將 Analytics Cookie 視為第一方 Cookie。
提升瀏覽器隱私權標準的可靠性和合規性。

實作 CNAME 追蹤的簡要步驟

步驟 1：設定第一方網域和 SSL 憑證

- 填寫第一方網域要求表單（可從 Adobe 管理的憑證方案文件的實作區段下載)，列出要使用的網域。您可以使用下列格式：smetrics。[yourdomain] 用於安全追蹤 指標。[yourdomain] 用於不安全追蹤。

- 取得這些網域的 SSL 憑證。

步驟 2：建立子網域

- 與您的 IS/IT 或託管團隊合作，建立必要的子網域（smetrics.yourdomain.com 和 metrics.yourdomain.com）。

步驟 3：向 Adobe 提交支援要求

- 透過 Adobe Admin Console 開立票證。
- 共用在步驟 1 中建立的網域要求表單。

步驟 4：從 Adobe 接收 SSL CNAME 詳細資料

- Adobe 提供必要的 CNAME 記錄詳細資訊，可將數據轉送至 Adobe 的伺服器（例如 random-10-character-string.data.adobedc.net）。

使用此 CNAME 資訊更新您的網域名稱伺服器 (DNS)。

步驟 5：驗證主機名稱重新導向

- 使用下列方式驗證 CNAME 設定：
  - 瀏覽器： https://smetrics.yourdomain.com/_check
  - cURL： curl -k https://smetrics.yourdomain.com/_check
  - nslookup： nslookup smetrics.yourdomain.com

步驟 6：更新 Adobe Analytics 實作

- 對於 AppMeasurement.js：更新 Adobe Analytics 擴充功能中的 s.trackingServer 和 s.trackingSecureServer。

- 對於 AEP WebSDK：更新 Adobe Experience Platform Web SDK 擴充功能中的 Edge 網域 欄位。

步驟 7：請求移轉期間

- 聯絡 Adobe Support 以啟用移轉期間（30/60/90 天）。
- 這可讓現有的訪客身分識別 Cookie 在轉換為新的基於 CNAME 之實作期間擷取相同的訪客 ID。

2. 第一方裝置 ID (FPID)

第一方裝置 ID (FPID) 提供強大的機制，可用來識別訪客、收集數據及管理數據，而無需依賴第三方 Cookie。 Adobe Experience Platform (AEP) WebSDK 透過與Adobe的Edge Network整合來啟用此功能，提供符合未來證據和隱私權規範的第一方追蹤。

本節將逐步說明使用 Flask 應用範例設定 FPID 的完整流程，包括 DNS 設定、Adobe WebSDK 整合，以及設定 Adobe Launch 進行數據收集。

示範設定

我們已為此實作設定測試網域。此環境可讓我們示範使用 Adobe Experience Platform Web SDK 設定第一方裝置 ID (FPID)。

架構

DNS 設定

若要實作基於 FPID 的追蹤，請更新網域的 DNS 記錄，以使用指向您的網頁伺服器或負載平衡器的 A/AAAA 記錄。

您可以參考下列與 DNS 記錄和 Web 伺服器/負載平衡器 IP 相關的螢幕擷圖。

DNS 記錄

Web 伺服器負載平衡器 IP

以下是需要注意的關鍵點：

與 CNAME 記錄不同，A/AAAA 記錄可確保第一方 Cookie 由您的 Web 伺服器直接設定，進而改善追蹤可靠性和隱私權法規遵循。
啟用 FPID 的 Cookie 會傳送至 Adobe 的 Edge Network，在那裡用於產生 Experience Cloud ID (ECID)——跨 Adobe Experience Cloud 應用程式 的主要識別碼。

設定 Flask 應用程式以產生 FPID

FPID 最好透過擁有 DNS A (IPv4) 或 AAAA (IPv6) 記錄的伺服器來設定第一方 Cookie，而非透過 CNAME 或 JavaScript 進行設定。設定完成後，FPID 會以事件數據的形式傳送至 Adobe，用以產生 ECID，這是 Adobe Experience Cloud 中的主要識別碼。

以下是使用 UUIDv4 產生 FPID 的 Python Flask 應用程式範例：

GitHub： https://github.com/appuriabhi/fpid_flaskapp/

from flask import Flask, render_template, request, make_response
from datetime import datetime, timedelta
import uuid

app = Flask(__name__)

@app.before_request
def before_request():
    cookie_name = ‘FPID’
    cookie_value = request.cookies.get(cookie_name)

    if not cookie_value:
        cookie_value = str(uuid.uuid4())
        expires = datetime.now() + timedelta(days=30*13)
        response = make_response()
        response.set_cookie(cookie_name, cookie_value,
                            expires=expires, secure=False, samesite=’Lax’)
        return response

#routes below
@app.route(‘/’)
def home():
    response = make_response(render_template(‘home.html’))
    return response

@app.route(‘/about’)
def about():
    response = make_response(render_template(‘about.html’))
    return response

if __name__ == ‘__main__’:
    app.run(debug=True)

Platform Edge Network 僅接受 UUIDv4 格式的 ID，拒絕任何其他格式。 UUIDv4 會建立唯一、隨機的 ID，這些 ID 極不可能重複，且不會使用如 IP 位址等個人資訊。

幾乎每一種程式設計語言都有用於產生 UUID 的程式庫，在上述範例中，我們使用了 Python 的 uuid 套件來產生識別碼。

我們有兩種方法可以更新 WebSDK 的實作，以利用 FPID Cookie 值 (UUID) 來初始化 Experience Cloud ID 值，具體說明如下：

1. 在 identityMap 中使用 FPID

更新 XDM IdentityMap 以設定以下格式的「FPID」值，以納入 /interact 追蹤呼叫

{
"identityMap": {
    "FPID": [
      {
        "id": "321a7654-b12c-42d3-9456-426614174123,"
        "authenticatedState": "ambiguous,"
        "primary": true
      }
    ]
}
}