Web SDK中的第一方设备ID

Adobe Experience Platform Web SDK使用Cookie将Adobe Experience Cloud ID (ECID)分配给网站访客,以跟踪用户行为。 要说明浏览器对Cookie有效期的限制,您可以选择设置和管理自己的设备标识符。 这些设备称为第一方设备ID (FPIDs)。

NOTE
仅当通过Web SDK向Experience PlatformEdge Network发送数据时,才支持第一方设备ID。
IMPORTANT
第一方设备ID与Web SDK中的第三方Cookie功能不兼容。
您可以使用第一方设备ID,也可以使用第三方Cookie,但不能同时使用这两项功能。

本文档介绍如何为Web SDK实施配置第一方设备ID。

先决条件

本指南假定您熟悉身份数据如何用于Platform Web SDK,包括ECID和identityMap的角色。 有关详细信息,请参阅有关Web SDK中的身份数据的概述

使用第一方设备ID (FPID) using-fpid

第一方设备ID (FPIDs)使用第一方Cookie跟踪访客。 当使用使用DNS A记录(对于IPv4)或AAAA记录(对于IPv6)而不是DNS CNAME或JavaScript代码的服务器设置第一方Cookie时,它们最有效。

IMPORTANT
仅支持A或AAAA记录来设置和跟踪Cookie。 数据收集的主要方法是通过DNS CNAME。 换句话说,FPIDs是使用A记录或AAAA记录设置的,然后使用CNAME发送到Adobe。
第一方数据收集还支持Adobe管理的证书计划

设置FPID Cookie后,在收集事件数据时,可以获取其值并将其发送到Adobe。 收集的FPIDs用作生成ECIDs的种子,该种子继续是Adobe Experience Cloud应用程序中的主标识符。

要将网站访客的FPID发送到Edge Network,您必须在该访客的identityMap中包含FPID。 有关详细信息,请参阅本文档中有关在identityMap🔗中使用FPID的的更详细部分。

第一方设备ID格式要求 formatting-requirements

该Edge Network仅接受符合UUIDv4格式的IDs。 将拒绝不采用UUIDv4格式的设备ID。

生成UUID几乎总是会生成唯一的随机ID,发生冲突的概率可以忽略不计。 无法使用IP地址或任何其他个人可识别信息(PII)为UUIDv4设定种子。 UUIDs无处不在,几乎可以找到每种编程语言的库来生成它们。

您可以在数据流用户界面中指定Cookie名称,该Cookie名称可以位于FPID中,而不必读取Cookie值并在标识映射中包含FPID。

IMPORTANT
此功能要求您启用第一方数据收集

有关如何配置数据流的详细信息,请参阅数据流文档

配置数据流时,启用​ 第一方ID Cookie ​选项。 此设置会告知Edge Network在查找第一方设备ID时引用指定的Cookie,而不是在标识映射中查找此值。

有关第一方Cookie如何与Adobe Experience Cloud配合使用的更多详细信息,请参阅有关第一方Cookie的文档。

平台UI图像,该图像显示了突出显示第一方ID Cookie设置的数据流配置

在启用此设置时,必须提供需要存储ID的Cookie的名称。

使用第一方ID时,无法执行第三方ID同步。 第三方ID同步依赖于Visitor ID服务以及该服务生成的UUID。 使用第一方ID功能时,生成ECID时未使用Visitor ID服务,这会导致无法同步第三方ID。

当您使用第一方ID时,由于Audience Manager合作伙伴ID同步主要基于UUIDsDIDs,因此不支持针对合作伙伴平台中的Audience Manager的激活功能。 从第一方ID派生的ECID未链接到UUID,使其不可寻址。

使用您拥有的服务器设置Cookie时,您可以使用各种方法防止Cookie因浏览器策略而受到限制:

  • 使用服务器端脚本语言生成Cookie
  • 设置Cookie以响应对子域或网站上的其他端点发出的API请求
  • 使用CMS生成Cookie
  • 使用CDN生成Cookie
IMPORTANT
使用JavaScript的document.cookie方法设置的Cookie几乎永远不会受到浏览器策略的保护,这些策略会限制Cookie的持续时间。

最好在向Edge Network发出任何请求之前设置FPID Cookie。 但是,在无法实现的情况下,ECID仍将使用现有方法生成,并充当主要标识符,前提是Cookie存在。

假设ECID最终受到浏览器删除策略的影响,但FPID未受到影响,则FPID将在下次访问时成为主要标识符,并用于在每次后续访问时为ECID设定种子。

设置Cookie的过期时间 set-expiration

在实施FPID功能时,应仔细考虑设置Cookie的过期时间。 在做出决定时,您应该考虑贵组织运营的国家或地区以及其中每个地区的法律和政策。

作为此决策的一部分,您可能希望采用全公司Cookie设置策略,或根据您运营的每个区域设置中的用户而有所不同。

无论您为Cookie的初始过期时间选择的设置如何,都必须确保包含每次发生对网站的新访问时都会延长Cookie过期时间的逻辑。

有各种Cookie标记会影响Cookie在不同浏览器中的处理方式:

HTTPOnly http-only

无法使用客户端脚本访问使用HTTPOnly标志设置的Cookie。 这意味着,如果在设置FPID时设置了HTTPOnly标记,则必须使用服务器端脚本语言来读取包含在identityMap中的Cookie值。

如果您选择让Edge Network读取FPID Cookie的值,则设置HTTPOnly标志可确保任何客户端脚本均无法访问该值,但不会对Edge Network读取Cookie的能力产生任何负面影响。

NOTE
使用HTTPOnly标记不会影响可能会限制Cookie生命周期的Cookie策略。 但是,在设置并读取FPID的值时,您仍应考虑它。

Secure secure

使用Secure属性设置的Cookie仅通过HTTPS协议以加密请求发送到服务器。 使用此标记有助于确保中间人攻击者无法轻松访问Cookie的值。 如果可能,最好设置Secure标志。

SameSite same-site

SameSite属性允许服务器确定是否随跨站点请求一起发送Cookie。 属性提供了一些针对跨站点伪造攻击的保护。 存在三个可能的值: StrictLaxNone。 请咨询您的内部团队,确定适合您组织的设置。

如果未指定SameSite特性,则某些浏览器的默认设置现在为SameSite=Lax

identityMap中使用FPID identityMap

以下是如何在identityMap中设置FPID的示例:

{
  "identityMap": {
    "FPID": [
      {
        "id": "123e4567-e89b-42d3-9456-426614174000",
        "authenticatedState": "ambiguous",
        "primary": true
      }
    ]
  }
}

与其他标识类型一样,您可以在identityMap中包含FPID和其他标识。 以下是经过身份验证的CRM ID所包含的FPID的示例:

{
  "identityMap": {
    "FPID": [
      {
        "id": "123e4567-e89b-42d3-9456-426614174000",
        "authenticatedState": "ambiguous",
        "primary": false
      }
    ],
    "EMAIL": [
      {
        "id": "email@mail.com",
        "authenticatedState": "authenticated",
        "primary": true
      }
    ]
  }
}

如果启用第一方数据收集时,如果FPID包含在Edge Network正在读取的Cookie中,则应当仅捕获经过身份验证的CRM ID:

{
  "identityMap": {
    "EMAIL": [
      {
        "id": "email@mail.com",
        "authenticatedState": "authenticated",
        "primary": true
      }
    ]
  }
}

以下identityMap将导致来自Edge Network的错误响应,因为它缺少FPID的primary指示器。 identityMap中存在的ID中至少有一个必须标记为primary

{
  "identityMap": {
    "FPID": [
      {
        "id": "123e4567-e89b-12d3-a456-426614174000",
        "authenticatedState": "ambiguous"
      }
    ],
    "EMAIL": [
      {
        "id": "email@mail.com",
        "authenticatedState": "authenticated"
      }
    ]
  }
}

在这种情况下,Edge Network返回的错误响应类似于以下内容:

{
    "type": "https://ns.adobe.com/aep/errors/EXEG-0306-400",
    "status": 400,
    "title": "No primary identity set in request (event)",
    "detail": "No primary identity found in the input event. Update the request accordingly to your schema and try again.",
    "report": {
        "requestId": "{REQUEST_ID}",
        "configId": "{CONFIG_ID}",
        "orgId": "{ORG_ID}"
    }
}

在您自己的域上设置FPID setting-fpid-domain

除了在身份映射中设置FPID之外,如果您配置了第一方数据收集CNAME,则还可以在您自己的域上设置FPID Cookie。

使用CNAME启用第一方数据收集后,将对向数据收集端点发出的请求发送您域的所有Cookie。

所有与Adobe数据收集目的无关的Cookie都会被丢弃。 对于FPID,您可以在数据流配置中指定FPID Cookie的名称。 执行此操作时,Edge Network将读取FPID Cookie的内容,而不是在身份映射中查找FPID。

要使用此功能,您需要在域的顶级设置FPID,而不是在特定的子域设置。 如果您在子域中设置它,则Cookie值将不会发送到Edge Network,并且FPID解决方案将无法按预期工作。

ID层次结构 id-hierarchy

当ECID和FPID都存在时,将优先考虑ECID来标识用户。 这样可以确保当浏览器Cookie存储中存在现有的ECID时,它仍然是主要标识符,并且现有访客计数不会受到影响。 对于现有用户,在ECID过期或因浏览器策略或手动过程而被删除之前,FPID不会成为主标识。

身份按以下顺序排定优先级:

  1. ECID包含在identityMap
  2. ECID存储在Cookie中
  3. FPID包含在identityMap
  4. FPID存储在Cookie中

迁移到第一方设备ID migrating-to-fpid

如果您从以前的实施迁移到第一方设备ID,则可能很难在低级别上直观显示过渡情况。

为了帮助说明此过程,请考虑一个涉及以前访问过您网站的客户的情形,以及FPID迁移对Adobe解决方案中识别该客户的方式有何影响。

显示迁移至FPID后客户的ID值在两次访问之间更新的图表

IMPORTANT
ECID Cookie的优先级始终高于FPID
前往
描述
首次访问
假设您尚未开始设置FPID Cookie。 AMCV Cookie中包含的ECID将是用于识别访客的标识符。
第二次访问
FPID解决方案的转出已开始。 现有ECID仍然存在,并且仍然是访客标识的主要标识符。
第三次访问
在第二次和第三次访问之间,由于浏览器策略,已经过了足够的时间删除ECID。 但是,由于FPID是使用DNS A记录设置的,因此FPID仍然存在。 FPID现在被视为主ID,用于为写入最终用户设备的ECID提供种子。 此时,该用户将被视为Adobe Experience Platform和Experience Cloud解决方案中的新访客。
第四次访问
在第三次和第四次访问之间,经过了足够长的时间,由于浏览器策略,ECID已被删除。 与上次访问一样,FPID仍因设置方式而异。 此时,将生成与上次访问相同的ECID。 在整个Experience Platform和Experience Cloud解决方案中,都会将该用户视为与上次访问相同的用户。
第五次访问
在第四次和第五次访问之间,最终用户清除了其浏览器中的所有Cookie。 已生成新FPID,并用它来创建新ECID。 此时,该用户将被视为Adobe Experience Platform和Experience Cloud解决方案中的新访客。

常见问题解答 faq

以下是有关第一方设备ID的常见问题解答列表。

植入ID与仅生成ID有何不同?

种子设定的概念是唯一的,因为传递到Adobe Experience Cloud的FPID使用确定性算法转换为ECID。 每次将相同的FPID发送到Edge Network时,相同的ECID都是从FPID中植入的。

何时应生成第一方设备ID?

为了减少潜在的访客虚增,应在使用Web SDK发出您的第一个请求之前生成FPID。 但是,如果您无法执行此操作,仍将为该用户生成ECID,并将用作主要标识符。 在ECID不再存在之前,生成的FPID不会成为主标识符。

哪些数据收集方法支持第一方设备ID?

当前仅Web SDK支持第一方设备ID。

第一方设备ID是否存储在任何平台或Experience Cloud解决方案上?

使用FPID为ECID设定种子后,它将从identityMap中删除,并替换为已生成的ECID。 FPID未存储在任何Adobe Experience Platform或Experience Cloud解决方案中。

recommendation-more-help
ad108910-6329-42f1-aa1d-5920a2b13636