Web SDK中的第一方设备ID
Adobe Experience Platform Web SDK使用Cookie将Adobe Experience Cloud ID (ECID)分配给网站访客，以跟踪用户行为。 要说明浏览器对Cookie有效期的限制，您可以选择设置和管理自己的设备标识符。 这些设备称为第一方设备ID (FPIDs)。
您可以使用第一方设备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时，它们最有效。
设置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无处不在，几乎可以找到每种编程语言的库来生成它们。
在数据流UI中设置第一方ID Cookie setting-cookie-datastreams
您可以在数据流用户界面中指定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 set-cookie-server
使用您拥有的服务器设置Cookie时，您可以使用各种方法防止Cookie因浏览器策略而受到限制：
- 使用服务器端脚本语言生成Cookie
- 设置Cookie以响应对子域或网站上的其他端点发出的API请求
- 使用CMS生成Cookie
- 使用CDN生成Cookie
document.cookie方法设置的Cookie几乎永远不会受到浏览器策略的保护，这些策略会限制Cookie的持续时间。何时设置Cookie when-to-set-cookie
最好在向Edge Network发出任何请求之前设置FPID Cookie。 但是，在无法实现的情况下，ECID仍将使用现有方法生成，并充当主要标识符，前提是Cookie存在。
假设ECID最终受到浏览器删除策略的影响，但FPID未受到影响，则FPID将在下次访问时成为主要标识符，并用于在每次后续访问时为ECID设定种子。
设置Cookie的过期时间 set-expiration
在实施FPID功能时，应仔细考虑设置Cookie的过期时间。 在做出决定时，您应该考虑贵组织运营的国家或地区以及其中每个地区的法律和政策。
作为此决策的一部分，您可能希望采用全公司Cookie设置策略，或根据您运营的每个区域设置中的用户而有所不同。
无论您为Cookie的初始过期时间选择的设置如何，都必须确保包含每次发生对网站的新访问时都会延长Cookie过期时间的逻辑。
Cookie标记的影响 cookie-flag-impact
有各种Cookie标记会影响Cookie在不同浏览器中的处理方式：
HTTPOnly http-only
无法使用客户端脚本访问使用HTTPOnly标志设置的Cookie。 这意味着，如果在设置FPID时设置了HTTPOnly标记，则必须使用服务器端脚本语言来读取包含在identityMap中的Cookie值。
如果您选择让Edge Network读取FPID Cookie的值，则设置HTTPOnly标志可确保任何客户端脚本均无法访问该值，但不会对Edge Network读取Cookie的能力产生任何负面影响。
HTTPOnly标记不会影响可能会限制Cookie生命周期的Cookie策略。 但是，在设置并读取FPID的值时，您仍应考虑它。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
}
]
}
}
与其他标识类型一样，您可以在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不会成为主标识。
身份按以下顺序排定优先级：
- ECID包含在
identityMap中 - ECID存储在Cookie中
- FPID包含在
identityMap中 - FPID存储在Cookie中
迁移到第一方设备ID migrating-to-fpid
如果您从以前的实施迁移到第一方设备ID，则可能很难在低级别上直观显示过渡情况。
为了帮助说明此过程，请考虑一个涉及以前访问过您网站的客户的情形，以及FPID迁移对Adobe解决方案中识别该客户的方式有何影响。
ECID Cookie的优先级始终高于FPID。常见问题解答 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解决方案中。