平台Web SDK中的身份数据

Adobe Experience Platform Web SDK利用 Adobe Experience Cloud ID(ECID) 来跟踪访客行为。 使用ECID，您可以确保每个设备都具有一个唯一标识符，该标识符可以跨多个会话保留，从而将在Web会话期间和跨Web会话发生的所有点击与特定设备相关联。

本文档概述了如何使用平台Web SDK管理ECID。

使用SDK跟踪ECID

Platform Web SDK通过使用Cookie分配和跟踪ECID，以及使用多种可用方法配置这些Cookie的生成方式。

当新用户到达您的网站时，Adobe Experience Cloud Identity服务会尝试为该用户设置设备标识Cookie。 对于首次访客，会在Adobe Experience Platform边缘网络的首次响应中生成并返回ECID。 对于重复访客，将从 kndctr_{YOUR-ORG-ID}_AdobeOrg_identity cookie和Edge Network添加到有效负载中。

设置包含ECID的Cookie后，Web SDK生成的每个后续请求都将在 kndctr_{YOUR-ORG-ID}_AdobeOrg_identity cookie。

使用Cookie进行设备标识时，您有两个选项可与边缘网络进行交互：

  1. 将数据直接发送到边缘网络域 adobedc.net. 此方法称为 第三方数据收集.
  2. 在您自己的域上创建指向 adobedc.net. 此方法称为 第一方数据收集.

如以下各节所述，您选择使用的数据收集方法会直接影响各种浏览器的Cookie生命周期。

第三方数据收集

第三方数据收集涉及将数据直接发送到边缘网络域 adobedc.net.

近年来，Web浏览器在处理第三方设置的Cookie时越来越受限。 默认情况下，某些浏览器会阻止第三方Cookie。 如果您使用第三方Cookie来识别网站访客，则这些Cookie的生命周期几乎总是比使用第一方Cookie时可能提供的生命周期短。 在某些情况下，第三方Cookie的过期时间最少为七天。

此外，当使用第三方数据收集时，某些广告拦截器会将流量限制为完全Adobe数据收集端点。

第一方数据收集

第一方数据收集涉及在您自己的域上通过CNAME设置Cookie，该CNAME指向 adobedc.net.

虽然浏览器长期以来处理由CNAME端点设置的Cookie的方式与由站点拥有的端点设置的方式类似，但浏览器实施的最新更改在处理CNAME Cookie的方式上有所区别。 虽然默认情况下没有阻止第一方CNAME Cookie的浏览器，但某些浏览器会将使用CNAME设置的Cookie的生命周期限制为仅7天。

Cookie生命周期对Adobe Experience Cloud应用程序的影响

无论您选择是第一方还是第三方数据收集，Cookie可持续的时长都会直接影响Adobe Analytics和Customer Journey Analytics中的访客计数。 此外，当在网站上使用Adobe Target或Offer decisioning时，最终用户可能会遇到不一致的个性化体验。

例如，假设您创建了一个个性化体验，如果用户在过去七天中查看了任何项目三次，则该体验会将其提升到主页。

如果最终用户一周内访问三次，但七天内没有返回网站，则当他们返回网站时，该用户可能会被视为新用户，因为浏览器策略可能已删除了其Cookie（具体取决于他们访问网站时使用的浏览器）。 如果出现这种情况，您的Analytics工具会将访客视为新用户，即使他们在七天多一点前访问了网站。 此外，将再次开始为用户个性化体验的任何工作。

第一方设备ID

要考虑如上所述Cookie生命周期的影响，您可以选择设置并管理您自己的设备标识符。 请参阅 第一方设备ID 以了解更多信息。

检索当前用户的ECID和区域

要检索当前访客的唯一ECID，请使用 getIdentity 命令。 对于首次没有ECID的访客，此命令会生成一个新的ECID。 getIdentity 也会返回访客的区域ID。

注意

此方法通常与需要读取 Experience Cloud ID或需要Adobe Audience Manager的位置提示。 标准实施不使用该函数。

alloy("getIdentity")
  .then(function(result) {
    // The command succeeded.
    console.log("ECID:", result.identity.ECID);
    console.log("RegionId:", result.edge.regionId);
  })
  .catch(function(error) {
    // The command failed.
    // "error" will be an error object with additional information.
  });

使用 identityMap

使用XDM identityMap 字段，您可以使用多个标识来识别设备/用户，设置其身份验证状态，并确定哪个标识符被视为主标识符。 如果未将标识符设置为 primary，则主要默认为 ECID.

identityMap 字段将使用 sentEvent 命令。

alloy("sendEvent", {
  xdm: {
    "identityMap": {
      "ID_NAMESPACE": [ // Notice how each namespace can contain multiple identifiers.
        {
          "id": "1234",
          "authenticatedState": "ambiguous",
          "primary": true
        }
      ]
    }
  }
});

中的每个属性 identityMap 表示属于特定 标识命名空间. 属性名称应该是身份命名空间符号，您可以在Adobe Experience Platform用户界面的“ ”下找到该符号标识" 属性值应该是与该标识命名空间相关的标识数组。

重要

传入的命名空间ID identityMap 区分大小写。 确保使用正确的命名空间ID以避免数据收集不完整。

标识数组中的每个标识对象都包含以下属性：

属性 数据类型 描述
id 字符串 （必需） 要为给定命名空间设置的ID。
authenticationState 字符串 （必需） ID的身份验证状态。 可能的值为 ambiguous, authenticated和 loggedOut.
primary 布尔型 确定此标识是否应用作配置文件中的主片段。 默认情况下，ECID将设置为用户的主标识符。 如果忽略，则此值默认为 false.

从访客API迁移到ECID

使用访客API从迁移时，您还可以迁移现有的AMCV Cookie。 要启用ECID迁移，请将 idMigrationEnabled 参数。 ID迁移可支持以下用例：

  • 当域的某些页面使用访客API，而其他页面使用此SDK时。 为支持这种情况，SDK会读取现有AMCV Cookie，并使用现有ECID写入新Cookie。 此外，SDK还会编写AMCV Cookie，以便如果首先在使用SDK分析的页面上获取ECID，则使用访客API分析的后续页面将具有相同的ECID。
  • 在同时具有访客API的页面上设置Adobe Experience Platform Web SDK时。 要支持这种情况，如果未设置AMCV Cookie，SDK将在页面上查找访客API，并调用该API以获取ECID。
  • 当整个网站使用Adobe Experience Platform Web SDK并且没有访客API时，迁移ECID以保留回访访客信息会非常有用。 在将SDK部署为 idMigrationEnabled 一段时间后，该设置便可关闭，以便迁移大部分访客cookie。

更新迁移特征

当XDM格式化的数据被发送到Audience Manager时，迁移时需要将这些数据转换为信号。 您的特征需要更新以反映XDM提供的新键值。 使用 BAAAM工具 Audience Manager创建的。

在事件转发中使用

如果您当前 事件转发 已启用且正在使用 appmeasurement.js 和 visitor.js，则可以保持启用事件转发功能，这不会导致任何问题。 在后端，Adobe会获取任何AAM区段，并将其添加到对Analytics的调用中。 如果对Analytics的调用包含这些区段，则Analytics不会调用Audience Manager来转发任何数据，因此不会进行任何双重数据收集。 使用Web SDK时也不需要位置提示，因为后端会调用相同的分段端点。

在此页面上