Web SDK中的第一方设备ID

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

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

先决条件

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

使用FPID

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

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

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

ID格式要求

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

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

在数据流UI中设置第一方ID Cookie setting-cookie-datastreams

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

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

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

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

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

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

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

使用您自己的服务器设置Cookie

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

何时设置Cookie

在向Edge Network发出任何请求之前，最好先设置FPID Cookie。 但是，在无法实现这一点的情况下，仍会使用现有方法生成ECID，并充当主要标识符（只要Cookie存在）。

假设ECID最终受到浏览器删除策略的影响，而FPID没有受到影响，则FPID将在下次访问时成为主标识符，并用于在每次后续访问时为ECID提供种子。

设置Cookie的过期时间

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

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

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

Cookie标记的影响

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

HTTPOnly http-only

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

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

Secure secure

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

SameSite same-site

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

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

在identityMap中使用FPID identityMap

以下是在identityMap中设置FPID的示例：

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

与其他标识类型一样，您可以将FPID与identityMap中的其他标识一起使用。 以下是经过身份验证的CRM ID所包含的FPID示例：

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

如果启用第一方数据收集时，如果Edge Network正在读取的Cookie中包含FPID，则您应当仅捕获经过身份验证的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}"
    }
}

ID层次结构

当ECID和FPID都存在时，ECID在识别用户时优先。 这可确保当浏览器Cookie存储中存在现有ECID时，该ECID仍保留为主要标识符，并且现有访客计数不会受到影响。 对于现有用户，在ECID过期或因浏览器策略或手动过程而被删除之前，FPID不会成为主要身份。

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

迁移到第一方设备ID

如果您要使用之前实施的FPID迁移到，则可能很难在低级别上直观显示过渡情况。

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

常见问题解答

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

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

种子设定概念的独特之处在于，传递给Adobe Experience Cloud的FPID会使用确定性算法转换为ECID。 每次向Adobe Experience PlatformEdge Network发送同一FPID时，都会从FPID中植入相同的ECID。

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

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

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

当前仅Web SDK支持FPID。

FPID是否存储在任何平台或Experience Cloud解决方案上？

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