随着隐私规则的收紧以及第三方 Cookie 的弃用,Adobe Analytics 提供了 CNAME 跟踪和第一方设备 ID (FPID) 等隐私优先解决方案,以确保数据的准确性和合规性。本文介绍了如何将这些策略与同意管理平台结合使用,以便在尊重用户同意的同时提供卓越的数字体验。
在网站分析中,Cookie 对于理解用户行为至关重要。在 Adobe Analytics 中,Cookie 有助于识别访客、跟踪会话以及衡量页面查看、点击和转化等情况,从而带来更深入的洞察、更出色的效果和更有效的营销。
但不断增长的隐私担忧和浏览器限制已限制了 Cookie 的使用(尤其是第三方 Cookie),也缩短了第一方 Cookie 的有效期。这些变化给传统跟踪方式造成了挑战,迫使战略发生转变。
为了适应调整,许多团队开始转向基于 CNAME 的实施和第一方设备 ID (FPID),以求在尊重用户隐私的同时保持强大的跟踪能力。
在本文中,我们将探讨浏览器隐私变化如何影响 Adobe Analytics,比较不同跟踪方法,并展示如何实施 CNAME 和 FPID 等隐私优先解决方案。
浏览器隐私限制的演变
各大浏览器供应商均已实施注重隐私的更新,以限制第三方 Cookie,甚至是限制第一方 Cookie 的功能。值得注意的更改包括:
- Safari (ITP): 引入了智能防跟踪功能 (ITP) 以阻止第三方 Cookie 并将第一方 Cookie 过期时间限制为 7 天。
- Firefox (ETP): 增强跟踪保护 (ETP) 会默认阻止第三方 Cookie 并阻止跨站点跟踪。
- Chrome(隐私沙盒): 旨在通过 FLoC(现在为 Topics API)和受保护的受众定位等替代方案逐步淘汰第三方 Cookie。
- Edge(跟踪防护): 默认阻止第三方 Cookie 和跟踪器,通过隐私级别(基本、平衡、严格)提供不同程度的保护。
主要浏览器隐私和跟踪保护设置对比
以下直观呈现了多年来主要浏览器实施的隐私相关的关键变更。
主要浏览器与隐私相关的关键变更
浏览器变更对 Adobe Analytics 的影响
第三方 Cookie
- 跨域跟踪:
-
- 以前,借助 Demdex Cookie 的跨域跟踪可实现跨域(例如,域 A 和 B)的无缝访客拼接,从而确保准确报告每一个访客。
- 在第三方 Cookie 限制的影响下,访客在不同域将被作为独立用户进行跟踪,导致报告中的数据碎片化,使用户历程分析的准确性随之降低。 广告/营销活动归因:
- 对第三方 Cookie 的限制会破坏转化归因,使营销人员更难衡量广告效果以及准确跟踪参与度。
- 营销活动效果报告可能会受影响,尤其是对于跨站点或跨设备的交互。
第一方 Cookie
- 访客识别:
-
- 在 Safari 和其他采用严格 Cookie 过期策略的浏览器中,用于访客识别的第一方 Cookie 现在仅在 7 天后就会过期(在某些场景下甚至更短)。
- 这意味着,若访客在 Cookie 过期后重新访问网站,将 被视为新访客 来进行跟踪。 会话跟踪:
- Cookie 过期策略还可能影响会话的连续性,导致分析报告中的会话计数虚高或用户历程不完整。
随着隐私政策变化改进跟踪方式
随着浏览器对第三方和第一方 Cookie 的限制不断增加,Adobe Analytics 实施必须做出调整,以维护数据连续性并保护用户隐私。这些变化可能导致访客数据碎片化、会话中断以及归因受阻。
为解决这一问题,兼顾隐私保护的跟踪策略应运而生:
- 基于 CNAME 的跟踪
通过子域名(例如,smetrics.yourdomain.com)路由数据收集,可将 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) 实施同意管理》,介绍了使用内置的同意处理或与第三方 CMP 的集成在 Adobe Tags 中配置同意的步骤。
使用 setConsent() 命令应用同意
用户通过 CMP 接受跟踪之后,会触发以下 Web SDK 命令以应用同意状态:
alloy("setConsent", {
consent: [{
standard: "Adobe",
version: "2.0",
value: {
collect: {
val: "y"
}
}
}]
});
这样可启用跟踪,并初始化 FPID 和 ECID 值。
在获得同意之前延迟所有跟踪
将 Adobe Tags 规则配置为:
- 延迟 sendEvent 调用,直到同意状态为 in。
- 在 CMP 触发同意之前,阻止 Web SDK 设置任何标识符(ECID、FPID)。
同意管理扩展(基于您选择的 CMP 提供商)可帮助在 Launch 中简化此设置。
通过 Web SDK 和 CMP 将同意正确集成到 Adobe Analytics 中之后,下一步是实施隐私优先的跟踪。以下部分将深入探讨如何配置基于 CNAME 的跟踪和 FPID,以适应浏览器隐私变化,同时保持合规性和数据准确性。
浏览器隐私和跟踪保护设置:第一方 Cookie 跟踪策略
1.基于 CNAME 的分析实施
基于 CNAME 的分析实施支持通过您的域路由跟踪调用,而不是直接使用 Adobe Analytics 服务器。这种方法可确保跟踪调用不易被基于浏览器的跟踪预防机制阻止,因为 Cookie 是以您的域编写的(例如 smetrics.yourdomain.com)。
AppMeasurement.js 和 AEP WebSDK 都支持此方法。
基于 CNAME 的跟踪的优势
- 克服阻止第三方 Cookie 的浏览器限制。
- 确保将分析 Cookie 作为第一方 Cookie。
- 通过浏览器隐私标准提高可靠性和合规性。
实施 CNAME 跟踪的高级步骤
步骤 1:设置第一方域和 SSL 证书
-
- 填写第一方域请求表单(可从Adobe 管理的证书计划文档的“实施”部分下载),列出要使用的域。您可以使用以下格式:smetrics.[yourdomain] 用于安全跟踪 metrics.[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
- 使用以下方式验证 CNAME 配置:
步骤 6:更新 Adobe Analytics 实施
-
- 对于 AppMeasurement.js:更新 Adobe Analytics 扩展中的 s.trackingServer 和 s.trackingSecureServer。
-
- 对于 AEP WebSDK:更新 Adobe Experience Platform Web SDK 扩展中的 Edge Domain 字段。
步骤 7:请求迁移时段
-
- 联系 Adobe 支持以启用迁移时段(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 WebSDK 配置第一方设备 ID (FPID)。
架构
DNS 配置
要实施基于 FPID 的跟踪,请更新域的 DNS 记录,以使用指向 Web 服务器或负载平衡器的 A/AAAA 记录。
可以参考以下与 DNS 记录和 Web 服务器/负载平衡器 IP 相关的屏幕快照。
DNS 记录
Web 服务器负载平衡器 IP
以下是需要注意的关键点:
- A/AAAA 记录与 CNAME 记录不同,可确保直接通过 Web 服务器设置第一方 Cookie,从而提升跟踪可靠性和隐私合规性。
- 已启用 FPID 的 Cookie 将被发送到 Adobe 的 Edge Network,并用于生成 Experience Cloud ID (ECID)——Adobe Experience Cloud 应用程序中的主要标识符 。
设置 Flask 应用程序以生成 FPID
FPID 使用第一方 Cookie,最好通过配置了 DNS A (Ipv4) 或 AAAA (Ipv6) 记录的服务器设置,而不是通过 CNAME 或 JavaScript。设置完成后,FPID 将作为事件数据发送至 Adobe 以生成 ECID,即 Adobe Experience Cloud 中的主要标识符。
以下是使用 UUIDv4 生成 FPID 的 Python Flask 应用程序示例:
GitHub:https://github.com/appuriabhi/fpid_flaskapp/
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,并且无法使用 IP 地址等个人信息。
几乎每种编程语言都有用于生成 UUID 的库,在上述示例中,我们使用了“uuid”Python 包来生成标识符。
更新实施以使用 FPID Cookie 值生成 ECID 值
我们可通过两种方式更新 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
}
]
}
}
Adobe Launch 中的 XDM IdentityMap 数据元素
2.在数据流中更新 CookieName
在数据流 UI 中指定 FPID Cookie 名称,而不是在 IdentityMap 中读取 Cookie 值并进行设置。
FPID 的数据流设置
在网络调用中验证 FPID
您可以在浏览器的网络选项卡中检查 /interact 跟踪调用,以确保 FPID 被包含在有效负载中,如下方屏幕快照所示。
验证“/interact”网络跟踪调用
Analytics 报告验证
我们可以看到,由于 FPID Cookie 值会在访客浏览器中持续存在,因此它可以在多次访问中生成相同的 Experience Cloud ID (ECID)。
Analytics 报告验证
结论和最佳实践
在当今不断变化的数字环境中,在 Adobe Analytics 中整合以隐私为中心的 Cookie 管理策略至关重要。随着浏览器隐私限制的收紧以及用户对数据控制权的需求日益增长,适应这些变化对于维持分析准确性和尊重用户隐私而言至关重要。
- 部署基于 CNAME 的分析跟踪实施,以克服浏览器对营销技术 Cookie 的限制。
- 采用 FPID 进行访客识别与跟踪。FPID 是一个强大的解决方案,可帮助克服主要浏览器的跟踪限制,且完全符合隐私法规要求。
- 持续关注隐私法规和最新的浏览器跟踪预防更新。