设置 Analytics 和 Experience Cloud ID

Experience Cloud Identity 服务取代了旧版 Analytics 访客 ID 方法。

在实施 ID 服务后，此代码将在 AppMeasurement 之前执行。ID 服务会检索 Experience Cloud ID 和 Analytics ID，以便这两个 ID 值在加载 AppMeasurement 时可以使用。

加载 AppMeasurement 时，将从 ID 服务请求 Experience Cloud ID 和 Analytics ID 值，并在每次服务器调用中将这两个值发送到数据收集。由于 ID 服务可确定访客 ID 并轻松将该 ID 传递给 AppMeasurement，因此必须先在每个页面上包含并实施 ID 服务，然后再实施 AppMeasurement JavaScript 文件。

对Analytics ID流程所做的更改

迁移到 Experience Cloud ID 服务后，主要的变化是：ID Cookie 会使用 JavaScript 进行设置，而不是在由数据收集 Web 服务器返回的 HTTP 标头中进行设置。为了解此更改，以下各部分将介绍如何使用这两种方法设置 Cookie。

HTTP 标头

来自 Web 服务器的 HTTP 响应将在浏览器中设置 Cookie。这就是 s_vi Cookie 的设置方式。s_vi Cookie 可识别 Analytics 访客。设置完 Cookie 后，所有后续 HTTP 请求会将 Cookie 发送至该服务器。

请求发送至 Adobe 数据收集服务器后，将检查标头是否存在 s_vi Cookie。如果此 Cookie 位于请求中，则将其用于识别访客。如果此 Cookie 不在请求中，则服务器会生成一个唯一的 Experience Cloud ID，并将其设置为 HTTP 响应标头中的 Cookie，然后随请求发送回来。Cookie 存储在浏览器中，并会在随后访问网站期间发送回数据收集服务器。如此一来，便可以在每次访问中识别访客。

但是，某些浏览器（如 Apple Safari）不接受第三方 Cookie。第三方 Cookie 是指在浏览器中从当前网站之外的其他域设置的 Cookie。此外，如果访客之前未访问过第三方域，Safari 还会阻止第三方域上的 Cookie。例如，如果您在 mysite.com 上，您的数据收集服务器为 mysite.omtrdc.net，那么从 mysite.omtrdc.net 的 HTTP 标头中返回的 Cookie 可能会遭到浏览器的拒绝。

要避免此问题，许多客户为其数据收集服务器实施了 CNAME 记录。这会成为第一方 Cookie 实施策略的有效部分。如果 CNAME 记录被配置为将客户域上的主机名映射至数据收集服务器（例如，将 metrics.mysite.com 映射至 mysite.omtrdc.net），则可以存储 Experience Cloud ID Cookie，因为数据收集域现在与网站的域相匹配。这增加了对 ID 服务 Cookie 进行存储的可能性。但是，这确实会带来一些额外的开销，因为您需要配置 CNAME 记录并维护数据收集服务器的 SSL 证书。

JavaScript

JavaScript 可以读写在第一方域（当前网站的域）中设置的 Cookie。Experience Cloud ID 服务可使用此方法来设置包含所有访客 ID 的 AMCV_###@AdobeOrg Cookie，这样一来，跟踪服务器的域便不再需要匹配网站的域，即可存储访客 ID Cookie。在大多数情况下，这是设置 ID 服务 Cookie 的首选方式，因为它消除了由 CNAME 记录和 SSL 证书产生的开销。