此页面举例说明 Marketing Cloud ID 服务如何将访客从旧版 Analytics ID 迁移到 Marketing Cloud ID。某些概念已进行了简化,以方便大多数人理解。

视频:MCID 如何迁移旧版 Analytics 访客


环境

下面显示了一个典型的 Web 环境。左侧是一个访客的浏览器。中间是 My Company Inc. 所拥有的网站集合,它们都已成功地部署了 ID 服务。在右侧和左下方,可看到一些代表 Adobe 服务器的圆柱。

典型的 Web 环境图

您可以看到此用户的浏览器有一个 s_vi Cookie。此 Cookie 看上去是在 SiteA.com 域中设置中。如果您熟悉 Analytics 跟踪,则应该知道此 Cookie 包含“aid”值。由于此 Cookie 的存在,该用户之前至少访问过一个 My Company Inc. 所拥有的网络资产。

情景

下面讨论两个不同的情景。

在第一个情景中,用户自 My Company Inc. 部署 ID 服务以来第一次返回到 SiteA.com。此情景显示 ID 服务如何将他们现有的 ID 从旧版 s_vi Cookie 迁移到 AMCV Cookie。第一个情景在图表中以蓝色显示。

在第二个情景中,同一位用户访问 My Company Inc. 拥有的第二个域。此域也部署了 ID 服务。这是该用户第一次访问此网站。此网站利用与第一个域相同的 Analytics 跟踪服务器。此情景显示 ID 服务从跟踪服务器中检索旧版 ID,同时还保持相同的 ID 服务 ID。第二个情景在图表中以红色显示

 

显示两个访客情景的图表

注意:

使用同一 Analytics 跟踪服务器的多个域通常涉及如何在 ID 服务之前完成跨域跟踪。

步骤

  1. 用户自 My Company Inc. 部署 Marketing Cloud ID 服务以来第一次访问 SiteA.com。

     

    Step 1
  2. ID 服务代码 (VisitorAPI.js) 作为页面的一部分加载,并进行检查以确定“AMCV”Cookie 是否存在于当前域 (SiteA.com) 中。由于此类 Cookie 不存在,因此 ID 服务会检查 demdex.net 域中是否有 Demdex Cookie 存在。demdex.net Cookie 也不存在。

    检查 Cookie
  3. 由于浏览器内当前不存在 Marketing Cloud ID,ID 服务代码从 ID 服务服务器 (dpm.demdex.net) 请求 ID。通过 Experience Cloud Organization ID 向 dpm.demdex.net 发起网络请求。

    发起网络请求

    注意:

    Experience Cloud Organization ID 从页面中提取,以作为实施的一部分,并唯一识别 Adobe Experience Cloud 中的每个客户公司。每个 ID 类似于以下值:016D5C175213CCA80A490D05@AdobeOrg

  4. ID 服务服务器接收请求。由于请求不包含“uuid”值,服务器会生成一个值以在生成 Marketing Cloud ID 或“mid”值时使用。生成“uuid”值后,服务器即会使用“uuid”和 Experience Cloud Organization ID 生成“mid”。 

    ID 服务服务器接收请求
  5. ID 服务使用“uuid”和“mid”对请求做出响应。

    包含 uuid 和 mid 的响应
  6. ID 服务最后检查是否存在旧版 Analytics ID。为此,它会检查 Analytics 跟踪服务器域中是否存在有“s_vi”Cookie。在本示例中,使用 metrics.siteA.com 作为 Analytics 跟踪服务器。

    检查是否存在旧版 Analytics ID

    注意:

    该检查是必要的,因为对于那些还没有旧版 Analytics ID 或“aid”的访客,Analytics 会使用“mid”值来作为其主 ID。如果未完成现有 ID 的迁移,用户会成为新访客,所有与旧版“aid”关联的历史数据都将不会与新访客相关联。

     

  7. 在本示例中,浏览器在跟踪服务器域中包含旧版 s_vi Cookie,这意味着 ID 服务可读取此 Cookie,并能够从该 Cookie 中检索“aid”值。

    浏览器包含旧版 Cookie
  8. 既然 ID 服务代码拥有了它需要的信息,接下来将在当前域 (SiteA.com) 中设置 AMCV Cookie。由于尚不存在 demdex.net Cookie,ID 服务还会设置包含 UUID 的 demdex.net Cookie。

    ID 服务设置 AMCV Cookie

    注意:

    ID 服务在当前域中写入其 Cookie。这不同于旧版 Analytics 识别,后者是在跟踪服务器中写入 Cookie。

    此外,Analytics 跟踪服务器域未必始终与网页的域相匹配。

  9. 将 AMCV Cookie 写入浏览器后,会加载页面的其余部分并触发 Adobe 解决方案信标。

    页面加载且 Adobe 解决方案信标触发
  10. 在情景 2 中,使用同一浏览器的同一用户访问 My Company Inc. 所拥有的其他网络资产,并且该资产中已部署 ID 服务。

    情景 2 - 同一浏览器访问
  11. ID 服务代码加载,并像步骤 2 中一样,检查当前域 (siteB.com) 中是否存在有 AMCV Cookie。由于这是该用户第一次访问此网站,因此不存在任何 AMCV。由于不存在任何 AMCV Cookie,接下来查找 demdex.net Cookie。此时 Demdex Cookie 是存在的,因为在上一个情景的步骤 8 中已设置了该 Cookie。ID 服务读取 Demdex Cookie,并返回“uuid”值。

    检查是否存在 AMCV Cookie
  12. 与第一个情景(步骤 3)中一样,ID 服务代码从 ID 服务服务器请求 ID。但此时 Demdex Cookie 中已经存在“UUID”值。“UUID”和 Experience Cloud Organization ID 将随请求一起发送出去。

    ID 服务请求 ID
  13. 服务器接收请求并生成“mid”值,为此需使用“uuid”(ABC) 和组织 ID (1234),它们随请求一起发送。请注意,“mid”值是使用与前一示例相同的组织 ID 和“UUID”生成而来。由于使用了相同的两个参数生成 ID,因此结果也是一样的。这就是在 ID 服务中实现跨域跟踪的方式。

    服务器接收请求并生成“mid”值
  14. 浏览器通过请求响应将“mid”值发送回页面。

    浏览器将“mid”值发送回页面
  15. ID 服务代码执行一次最终检查,确定 s_vi Cookie 是否存在于 Analytics 跟踪服务器上(与第一个情景类似,以确保不会丢下任何现有访客数据)。

    ID 服务代码 - 最终检查是否存在 Cookie
  16. 由于跟踪服务器域与浏览器当前访问的域 (siteb.com) 不匹配,因此会对 metrics.siteA.com 发起调用,以便跟踪服务器能够响应请求。跟踪服务器通过 AID 值响应请求,假定该值存在(在本案例中该值确实存在,因为您可以在图形浏览器顶部看到)。

    对 metrics.siteA.com 发起调用
  17. 既然 ID 服务代码拥有了它需要的所有信息,接下来将在当前域上写入一个 AMCV Cookie。此时在 siteB.com 上写入 Cookie。AMCV Cookie 同时包含“mid”和“aid”。由于同时具有这两个值,将允许我们继续使用所有与旧版 ID 关联的数据,同时还通过 MID 给我们带来了拥有跨解决方案 ID 的诸多好处

    在当前域上写入 AMCV Cookie
  18. 最后,将执行其余的页面代码并触发 Adobe 解决方案信标

有疑问?

本文深入讨论了 Marketing Cloud ID 服务 (MCID) 的运作原理。某些概念已进行了简化,以便得到普遍理解。如果您有其他问题,请参阅 Marketing Cloud ID 服务文档。您也可以在 社区论坛 中提问。

本产品经 Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License 许可  Twitter™ 与 Facebook 中的内容不在 Creative Commons 的条款约束之下。

法律声明   |   在线隐私策略