使用 AMP 管理未经验证的用户状态

背景
- AMP 页面的显示上下文
- 多个上下文意味着多个状态管理
实施指南
强烈建议的做法

用户状态是当今 Web 上的一个重要概念。考虑以下通过管理用户状态启用的用例

商家构建一个有用的购物车，在用户第二次访问时向用户显示他们在几周前第一次访问时添加到购物车中的相同商品。这样的体验通过确保用户仍然了解他们过去考虑购买的商品，从而增加了用户购买该商品的机会。
新闻发布商可以根据读者对发布商文章的重复访问来为读者定制推荐文章，这有助于保持读者的参与度并发现更多内容。
运行任何类型网站的网站开发人员收集分析数据，可以判断两个页面浏览量是属于查看了两个页面的同一个人，还是属于各自查看一个页面的两个不同的人。有了这种洞察力，就可以了解网站的性能，并最终了解如何改进它。

本文旨在帮助您在 AMP 中成功管理未经验证的用户状态，这是一种即使在用户没有采取任何操作来提供其身份（例如登录）的情况下也能提供无缝用户旅程的方法。在回顾了处理此主题的一些挑战和注意事项之后，本指南概述了 AMP 如何支持用户状态，并就您如何进行技术实施提供了建议。

背景

用户状态主题在 AMP 中值得特别关注，因为 AMP 页面可以在多种上下文中显示，例如在您的网站、Google 搜索或第三方应用中。当用户在这些之间移动时，这会给管理用户状态带来挑战。

AMP 页面的显示上下文

您可以将 AMP 视为一种可移植的内容格式，使内容可以在任何地方快速加载。AMP 文档可以通过三个值得注意的上下文显示

发布商的来源
AMP 缓存
AMP 查看器

上下文	可以从此处提供非 AMP 页面吗？	可以从此处提供 AMP 页面吗？	示例 URL
发布商的来源	是	是	`https://example.com/article.amp.html`
AMP 缓存	否	是	`https://example-com.cdn.ampproject.org/s/example.com/article.amp.html`
AMP 查看器	否	是	`https://google.com/amp/s/example.com/article.amp.html`

让我们更仔细地研究这些情况。

上下文 #1：发布商的来源。 AMP 页面经过部署，因此它们最初由发布商的网站托管并可通过该网站访问，例如在 https://example.com 上可能会找到 https://example.com/article.amp.html。

发布商可以选择仅以 AMP 形式发布，或者发布两个版本的内容（即，AMP 内容与非 AMP 内容“配对”）。“配对”模型需要一些特定步骤，以确保搜索引擎、社交媒体网站和其他平台可以发现 AMP 版本的页面。完全支持这两种发布方法；由发布商决定采取哪种方法。

注意

由于刚刚描述的“配对”发布模型，发布商的来源（在上面的示例中为 https://example.com）是可以访问 AMP 和非 AMP 内容的上下文。实际上，这是唯一可以发生这种情况的上下文，因为下面描述的 AMP 缓存和 AMP 查看器仅提供有效的 AMP 内容。

上下文 #2：AMP 缓存。 AMP 文件可以由第三方缓存缓存在云中，以减少内容到达用户移动设备所需的时间。

通过使用 AMP 格式，内容生产者可以使 AMP 文件中的内容可被第三方缓存。在这种类型的框架下，发布商继续控制其内容（通过如上所述发布到其来源），但平台可以缓存或镜像内容，以实现最佳的向用户交付速度。

传统上，以这种方式提供的内容来自不同的域。例如，Google AMP 缓存使用 https://cdn.ampproject.org 提供内容，例如 https://example-com.cdn.ampproject.org/s/example.com/article.amp.html。

上下文 #3：AMP 查看器。 AMP 格式旨在支持嵌入第三方 AMP 查看器中。这实现了 AMP 文件和查看器体验之间的高度协作，其优势包括：智能且安全的内容预加载和预渲染，以及在完整的 AMP 页面之间滑动等创新功能。

就像 AMP 缓存的情况一样，预计 AMP 查看器的域也与发布商来源不同。例如，Google 搜索的查看器托管在 https://google.com 上，并嵌入一个 iframe，该 iframe 从 Google AMP 缓存请求发布商内容。

多个上下文意味着多个状态管理

发布商必须准备好单独管理每个显示上下文的用户状态。AMP 的客户端 ID 功能利用 Cookie 或本地存储来持久化状态，为 AMP 页面提供必要支持，以便为用户提供稳定且匿名的标识符。从实施的角度来看，可以使用 Cookie 或本地存储，而 AMP 会根据显示上下文决定使用哪个。此选择会受到将此状态扩展到数百或数千个发布商的技术可行性的影响。

但是，AMP 页面的发布商很容易（不知不觉地）设计出涉及多个上下文的用户旅程。让我们回顾一下之前对购物车用例的介绍，并添加一些更多细节，使其成为一个完整的用户故事

在第 1 天，用户通过 Google 搜索从 Example Inc. 发现了一个 AMP 页面。Google 搜索在 AMP 查看器中加载 AMP 页面。在查看页面时，用户将四件商品添加到购物车，但没有结帐。两周后，在第 15 天，用户记起他们考虑购买的四件商品，并决定现在是购买的时候了。他们直接访问 Example Inc. 的主页 https://example.com（这是一个非 AMP 主页），发现他们的四件商品仍然保存在购物车中。

在这种情况下，即使她已经从 AMP 查看器上下文转移到发布商来源上下文（并且这些事件之间经过了一段时间），用户也获得了始终如一的购物车体验。这种体验非常合理，如果您正在设计购物体验，则应该期望支持它，那么您如何实现它呢？

要启用此体验和任何涉及用户状态的体验，用户遍历的所有上下文都必须相互共享各自维护的状态。“完美！”，您说，想法是在这些上下文边界之间共享具有用户标识符的 Cookie 值。一个问题：即使这些上下文都显示由同一发布商控制的内容，但它们彼此都将对方视为第三方，因为每个上下文都位于不同的域上。

正如您将在以下讨论中看到的那样，在与 Cookie 交互时处于第三方位置可能会带来挑战，具体取决于用户浏览器的设置配置。特别是，如果在特定情况下阻止了第三方 Cookie，则会阻止跨上下文共享信息的能力。另一方面，如果允许第三方 Cookie 操作，则可以共享信息。

实施指南

本节提供有关管理用户状态的建议。下面的任务按顺序排列，但大致可以分为两个部分

第 1 部分：基本实施：任务 1-4 对于使基本功能正常运行至关重要。它们依赖于部分完成工作所需的一组最小功能：AMP 的客户端 ID 替换、Cookie 的读取和写入以及维护后端映射表。为什么是“部分”？因为这些任务中传达的步骤依赖于读取和写入 Cookie，并且由于浏览器的 Cookie 设置可能会在某些情况下阻止这种情况，因此这组任务可能不足以在所有情况下完全管理用户状态。

在奠定基础之后，我们将探讨一个应用范围较窄但能为这些应用场景提供完整解决方案的主题。

第二部分：在链接和表单提交中使用客户端 ID： 在任务 5 中，您将学习如何利用链接遍历和/或表单提交来跨上下文边界传递 AMP 客户端 ID 信息，即用户从一个页面直接跳转到另一个页面时。

注意

以下实施指南建议使用和处理 Cookie。请务必查阅强烈建议的实践部分，了解需要注意的重要建议。

开始之前

在阅读下面的技术指导时，让我们假设您将把用户状态绑定到一个代表用户的稳定标识符。例如，标识符可能类似于 n34ic982n2386n30。然后在服务器端，您将 n34ic982n2386n30 与任何用户状态信息集相关联，例如购物车内容、以前阅读过的文章列表或取决于使用场景的其他数据。

为了在本文档的其余部分保持清晰，我们将用更易读的名称（以美元符号 ($) 开头）来称呼各种表示标识符的字符串。

n34ic982n2386n30 ⇒ $sample_id

我们的使用场景： 在本指南中，我们将致力于一个旨在实现简单页面浏览跟踪（即分析）的示例，其中我们希望尽可能准确地进行用户计数。这意味着，即使用户从不同的上下文访问特定发布商的内容（包括在 AMP 和非 AMP 页面之间切换），我们仍希望将这些访问计入对用户的单一理解，这与用户仅浏览该发布商的传统非 AMP 页面时的情况相同。

关于稳定 Cookie 值的可用性的假设： 我们还假设用户使用相同的设备、浏览器和非隐私/隐身浏览，以确保 Cookie 值在用户会话中得到保留并可用。如果不是这种情况，则不应期望这些技术有效。如果这是必需的，请考虑根据用户的已验证（即已登录）身份来管理用户状态。

以下介绍的概念可以扩展到其他用例： 尽管我们只关注分析用例，但以下传达的概念可以为其他需要在不同上下文中进行用户状态管理的用例进行修改。

任务 1：对于发布商源上的非 AMP 页面，设置标识符并发送分析 Ping

让我们首先为从发布商源提供的非 AMP 页面配置分析。这可以通过多种方式实现，包括使用 Google Analytics 或 Adobe Analytics 等分析包，或编写自定义实现。

如果您使用供应商的分析包，则该包很可能会通过其配置代码和 API 来处理设置 Cookie 和传输 Ping。如果是这种情况，您应该仔细阅读以下步骤，以确保它们与您的分析方法一致，但预计您无需在完成此任务时进行任何更改。

如果您希望设置自己的分析，则本任务的其余部分将提供指导。

使用第一方 Cookie 设置标识符

如果您有从发布商源提供的非 AMP 页面，请设置一个持久且稳定的标识符以在这些页面上使用。这通常使用第一方 Cookie 实现。

就我们的示例而言，假设您已设置一个名为 uid（“用户标识符”）的 Cookie，该 Cookie 将在用户首次访问时创建。如果不是用户首次访问，则读取首次访问时先前设置的值。

这意味着发布商源上的非 AMP 页面的状态有两种情况

情况 1：首次访问。 首次访问非 AMP 页面时，将没有 Cookie。如果您在设置 Cookie 之前检查了 Cookie，您会在 Cookie 中看到没有与 uid 对应的设置值

> document.cookie
  ""

在初始加载期间的某个时间，应该设置 Cookie，这样如果您在页面加载完成后执行此操作，您将看到已设置一个值

> document.cookie
  "uid=$publisher_origin_identifier"

情况 2：非首次访问。 将会设置一个 Cookie。因此，如果您在页面上打开开发者控制台，您将看到

> document.cookie
  "uid=$publisher_origin_identifier"

发送分析 Ping

设置标识符后，您现在可以将其纳入分析 Ping 中以开始跟踪页面浏览量。

具体实现将取决于您所需的配置，但通常您将希望向您的分析服务器发送 Ping（请求），其中包含请求 URL 本身内的有用数据。这是一个示例，其中还指示了如何在请求中包含 Cookie 值

https://analytics.example.com/ping?type=pageview&user_id=$publisher_origin_identifier

请注意，在上面的示例中，用户的标识符由特定的查询参数 user_id 表示

user_id=$publisher_origin_identifier

此处 “user_id” 的使用应由您的分析服务器期望处理的内容确定，并且不特别与您在本地存储标识符的 Cookie 名称相关联。

任务 2：对于 AMP 页面，通过在 amp-analytics Ping 中包含客户端 ID 替换来设置标识符并发送分析 Ping

现在转到 AMP 页面，让我们看看如何建立和传输用于分析的标识符。这将适用于 AMP 页面呈现的任何上下文，因此这涵盖了发布商源上的任何 AMP 页面、通过 AMP 缓存提供的任何 AMP 页面或在 AMP 查看器中显示的任何 AMP 页面。

通过使用需要客户端 ID 的功能，AMP 将在“幕后”进行工作，以生成和存储客户端 ID 值，并将其提供给需要它们的功能。可以使用 AMP 的客户端 ID 的主要功能之一是 amp-analytics，这恰好是我们实现分析用例示例所需要的。

在 AMP 页面上，构造包含客户端 ID 的 amp-analytics Ping

amp-analytics 配置如下所示	`https://analytics.example.com/ping?type=pageview&user_id=${clientId(uid)}`
通过网络传输的内容如下所示	`https://analytics.example.com/ping?type=pageview&user_id=$amp_client_id` 在这种情况下，`${clientId(uid)}` 被 AMP 在该时刻生成的实际值替换，或者将根据用户浏览器已在本地存储的内容返回。

请注意，传递给客户端 ID 替换的参数 ${clientId(uid) 是 uid。这是一个经过深思熟虑的选择，它与任务 1 中描述的发布商源上使用的相同 Cookie 名称相匹配。为了实现最无缝的集成，您应该应用相同的技术。

关于 amp-analytics 实现的其余部分，请参阅amp-analytics 配置的文档，了解有关如何设置 amp-analytics 请求或修改分析供应商的请求的更多详细信息。Ping 可以进一步修改以传输您直接定义或利用其他 AMP 替换的其他数据。

须知

为什么我们将名称 uid 用于传递给客户端 ID 功能的参数？clientId(...) 替换所采用的参数用于定义作用域。您实际上可以将客户端 ID 功能用于许多用例，因此生成许多客户端 ID。该参数区分这些用例，因此您可以使用它来指定您想要哪个用例的客户端 ID。例如，您可能希望向第三方（如广告商）发送不同的标识符，并且您可以使用“作用域”参数来实现此目的。

在发布商源上，将“作用域”视为您调用 Cookie 的名称是最容易的。通过建议在任务 2 中此处客户端 ID 参数的值为 uid，我们与在任务 1 中使用名为 uid 的 Cookie 的选择保持一致。

任务 3：处理来自发布商源上的页面的分析 Ping

由于在任务 1 和 2 中执行的设置，当有人访问 AMP 版本（来自任何上下文）或发布商源上的非 AMP 版本时，分析 Ping 将使用相同的标识符。通过遵循任务 2 中的指导，选择与您在任务 1 中使用的 Cookie 的名称相同的客户端 ID “作用域”，AMP 将重用相同的 Cookie。

下表对此进行了说明

来自发布商源上的非 AMP 页面的分析 Ping 如下所示	`https://analytics.example.com/ping?type=pageview&user_id=$publisher_origin_identifier`
来自发布商源上的 AMP 页面的分析 Ping 如下所示	`https://analytics.example.com/ping?type=pageview&user_id=$publisher_origin_identifier` 在这种情况下，它是相同的！通过选择 `uid` 的作用域值，`uid` Cookie 的基础值（即 `$publisher_origin_identifier`）将被使用。

任务 4：处理来自 AMP 缓存或 AMP 查看器显示上下文的分析 Ping 并建立标识符映射（如果需要）

当我们在任务 2 中设置分析 Ping 以传输来自 AMP 缓存或 AMP 查看器中显示的 AMP 页面的数据时，我们也制造了一个问题。如前所述，AMP 缓存和 AMP 查看器上下文与发布商源上下文不同，并且随之而来的是维护标识符的不同方式。为了处理这些 Ping 以避免诸如用户重复计数之类的问题，我们将采取一些步骤来尽可能地协调标识符。

为了帮助解释我们正在采取的步骤，首先重新考虑重复计数问题是如何产生的很有帮助。

回顾问题

考虑以下流程

用户在 AMP 查看器显示环境中访问 AMP 页面，例如 https://google.com/amp/s/example.com/article.amp.html。由于 AMP 查看器无法访问发布商源上的 uid Cookie，因此会生成一个随机值 $amp_client_id 来标识用户。
然后，同一用户访问发布商源上的页面 https://example.com。如任务 3中所述，用户使用 $publisher_origin_identifier 进行标识。

此处 (1) 和 (2) 发生在不同的源（或环境）上。因此，没有共享状态，并且 $amp_client_id 与 $publisher_origin_identifier 不同。那么，这有什么影响？(1) 是一个看起来像一个用户的单页浏览会话，而 (2) 是另一个看起来像是来自另一个用户的单页浏览会话。基本上，即使该用户一直参与 https://example.com 的内容，我们也会高估用户数量，并且 (1) 中的用户看起来像是跳出（单页访问）。

解决方案策略

为了解决高估用户数量的问题，您应该采用以下策略，该策略的有效性取决于是否允许读取或写入第三方 Cookie

立即标识符协调：如果您可以访问或更改发布商源 Cookie，请使用或创建发布商源标识符，并忽略分析请求中的任何标识符。您将能够成功链接两个环境之间的活动。
延迟标识符协调：如果您无法访问或更改发布商源标识符（即 Cookie），则回退到分析请求本身中附带的 AMP 客户端 ID。请将此标识符用作“别名”，而不是使用或创建新的发布商源标识符（Cookie），因为您无法执行此操作（由于第三方 Cookie 阻止），并将别名添加到映射表。您将无法立即链接两个环境之间的活动，但是通过使用映射表，您也许能够在用户将来访问时将 AMP 客户端 ID 值与发布商源标识符链接起来。发生这种情况时，您将拥有所需的信息来链接活动并协调不同环境中的页面访问来自同一用户。任务 5 描述了如何在用户从一个页面立即跳转到另一个页面的特定场景中实现完整的解决方案。

实施步骤

在服务器上检查是否存在发布商源标识符

读取作为分析请求一部分发送的 Cookie。在我们的示例中，这意味着检查来自 example.com 的 uid Cookie。

如果成功读取 uid 值，请使用它来记录分析数据（分析记录标识符）。由于任务 1，我们知道此标识符的值为 $publisher_origin_identifier。建立分析记录标识符后，我们可以跳到数据存储部分。
如果 uid 值未能成功读取，请继续执行下面涉及映射表的步骤。

映射表

我们的映射表将关联在分析 ping 中看到的 AMP 客户端 ID 值与发布商源标识符，如下所示

发布商源上的用户 ID	不在发布商源上的 AMP 页面上的用户 ID（“别名”）
来自发布商源标识符，如果无法访问发布商源标识符，则生成为预期的值。	来自 AMP 客户端 ID

在确定无法成功读取发布商源标识符后，立即检查分析 ping 中包含的 AMP 客户端 ID 是否已在映射中使用。为此，首先查阅传入的 amp-analytics 请求以获取客户端 ID 值。例如，从此请求中

https://analytics.example.com/ping?type=pageview&user_id=$amp_client_id

我们提取出对应于 AMP 客户端 ID 的加粗部分：$amp_client_id。

接下来，检查映射表，尝试在“别名”列中查找相同的值

发布商源上的用户 ID	不在发布商源上的 AMP 页面上的用户 ID（“别名”）
`$existing_publisher_origin_identifier`	`$amp_client_id`

在上面的示例中，我们找到了一个已经存在的记录。我们找到的与 AMP 客户端 ID 配对的值将成为分析记录标识符。在这里，它是 $existing_publisher_origin_identifier。建立分析记录标识符后，我们可以跳到数据存储部分。

否则，如果在映射中未找到 AMP 客户端 ID，我们需要创建一个映射

生成一个预期的发布商源标识符。在以下示例中，我们将其称为 $prospective_identifier。该值的创建方式应与您在发布商源上设置值的方式一致，如上面的任务 1中所述。
接下来，尝试在发布商源上将预期的发布商源标识符设置为 Cookie。如果可以写入第三方 Cookie，这将成功，否则将失败。
然后，存储 {预期的发布商源标识符，AMP 客户端 ID} 对。

我们创建的映射最终看起来像这样

发布商源上的用户 ID	不在发布商源上的 AMP 页面上的用户 ID（“别名”）
`$prospective_identifier`（在收到分析 ping 时即时生成）	`$amp_client_id`（来自分析 ping）

我们将使用预期的发布商源标识符作为分析记录标识符，因为该值与发布商源上的状态相关联。在这种情况下，它是 $prospective_identifier，它将在后面的数据存储部分中发挥作用。

数据存储

现在您已经确定了分析记录标识符，您可以实际存储以该标识符为键的用户状态信息（在本例中为分析数据）

{analytics record identifier, analytics data ...}

任务 5：在链接和表单提交中使用客户端 ID

通常，当不允许读取和写入第三方 Cookie 时，管理用户状态的情况将无法完全有效地完成。在任务 1-4 中，我们采取的步骤在两个方面有所帮助：（1）它们为允许读取和写入第三方 Cookie 的情况提供了完全有效的解决方案；（2）它们设置了我们的系统，以便在由于浏览器的 Cookie 设置而无法立即协调的情况下，利用任何最终协调跨环境标识符的机会。

在此任务中，我们将介绍一个额外的优化，该优化在用户通过链接或表单提交从一个页面跨环境导航到另一个页面时有所帮助。在这些情况下，通过下面描述的实现工作，可以建立一个完全有效的方案来管理跨环境的用户状态。

使用替换功能

我们的方法将利用两种类型的 AMP 变量替换。

要更新传出链接以使用客户端 ID 替换：定义一个新的查询参数 ref_id（“引用者 ID”），它将出现在 URL 中，并指示用户的起始环境标识符。将此查询参数设置为等于 AMP 的客户端 ID 替换的值

<a
  href="https://example.com/step2.html?ref_id=CLIENT_ID(uid)"
  data-amp-replace="CLIENT_ID"
></a>

将客户端 ID 传递到传出链接的替代解决方案：将新的查询参数 ref_id 定义为数据属性 data-amp-addparams 的一部分，对于需要参数替换的查询，请将这些详细信息作为 data-amp-replace 的一部分提供。使用此方法，URL 将看起来简洁，并且 data-amp-addparams 上指定的参数将动态添加

<a
  href="https://example.com/step2.html"
  data-amp-addparams="ref_id=CLIENT_ID(uid)"
  data-amp-replace="CLIENT_ID"
></a>

要通过 data-amp-addparams 传递多个查询参数，请使用 & 分隔它们，例如

<a
  href="https://example.com/step2.html"
  data-amp-addparams="ref_id=CLIENT_ID(uid)&pageid=p123"
  data-amp-replace="CLIENT_ID"
></a>

要更新表单输入以使用客户端 ID 替换：为输入字段定义一个名称，例如 orig_user_id。将表单字段的 default-value 指定为 AMP 的客户端 ID 替换的值

<input
  name="ref_id"
  type="hidden"
  value="CLIENT_ID(uid)"
  data-amp-replace="CLIENT_ID"
/>

通过执行这些步骤，客户端 ID 可用于目标服务器，并且/或者作为用户在点击链接或提交表单后着陆的页面上的 URL 参数（目标环境）。名称（或“键”）将为 ref_id，因为这是我们在上述实现中定义它的方式，并且将具有与客户端 ID 相等的相关值。例如，通过跟踪上面定义的链接（<a> 标签），用户将导航到此 URL

https://example.com/step2.html?ref_id=$amp_client_id

当用户登陆包含 ref_id 值的页面时（作为 URL 参数或在标头中），我们有机会协同处理 ref_id 标识符以及通过页面本身公开的标识符（即 Cookie 值）。通过在分析 ping 中包含两者，您的分析服务器可以同时处理这两个值，并且知道它们是相关的，从而在您的后端反映这种关系。下一步提供了有关如何执行此操作的详细信息。

提取 URL 查询参数

通过使用替换功能，我们建立了一个链接导航流程或表单提交流程，该流程将信息（特别是客户端 ID）公开给目标服务器，并且/或者作为 URL 参数，该参数可以在用户完成导航后在客户端读取。

如果信息仅暴露给服务器，例如通过表单 POST，那么您可以继续处理信息并呈现结果页面。在处理此类数据时，请注意下面详细介绍的有关参数验证的步骤。

如果信息可通过 URL 获得并且您希望对其进行处理，则可以使用以下几种方法

在重定向期间处理（服务器端处理）
在目标页面上处理（客户端处理）

在重定向期间处理（服务器端处理）

要在重定向期间处理，请在服务器上处理请求并提取相关参数。请注意下面详细介绍的有关参数验证的步骤。处理数据，结合包含其他相关标识符的 Cookie 值，然后重定向到不包含参数的 URL。

在目标页面上处理（客户端处理）

要在目标页面上处理，该方法将因该页面是 AMP 页面还是非 AMP 页面而异。

AMP 页面更新：在您的 amp-analytics 配置中使用查询参数替换功能，以获取 URL 中的 ref_id 标识符值。查询参数功能采用一个参数，该参数指示 URL 中所需键值对的“键”，并返回相应的值。像我们一直在做的那样使用客户端 ID 功能来获取 AMP 页面环境的标识符。

https://analytics.example.com/ping?type=pageview&orig_user_id=${queryParam(ref_id)}&user_id=${clientId(uid)}

当通过网络传输时，实际值将被替换

https://analytics.example.com/ping?type=pageview&orig_user_id=$referrer_page_identifier&user_id=$current_page_identifier

按照我们上面的示例，我们有

$referrer_page_identifier is $amp_client_id
$current_page_identifier is $publisher_origin_id

因此，ping 实际上是

https://analytics.example.com/ping?type=pageview&orig_user_id=$amp_client_id&user_id=$publisher_origin_id

我们建议使用以下参数验证部分中概述的步骤来验证查询参数值的真实性。

非 AMP 页面更新：同样，在从您的发布商源提供的非 AMP 页面上，提取并传输 URL 中包含的 ref_id 值。按照以下参数验证部分中概述的步骤来验证该值的真实性。然后，构造分析 ping，其中将包含一个从 ref_id 派生的 orig_user_id 和一个基于第一方 Cookie 标识符值的 user_id。

重要提示

如果您选择在目标页面上客户端处理参数，则目标页面应在捕获标识符后立即从 URL 中删除标识符信息。

在删除参数之前，请确保需要运行以读取它们的其他代码已经

在移除操作发生之前运行；或者

可以访问代码读取并移除参数后存储数据的位置

要在非 AMP 页面上执行此操作，请包含以下 JavaScript 代码，它将从 URL 中删除所有查询参数
var href = location.href.replace(/\?[^#]+/, '');
history.replaceState(null, null, href);
根据需要调整此代码以删除较少的查询参数。

在分析 ping 中处理多个标识符

与任务 4中配置分析 ping 只包含一个标识符值不同，通过我们在任务 5 中到目前为止采取的步骤，我们现在有两个标识符：orig_user_id 和 user_id。接下来，我们将介绍如何处理作为入站分析 ping 一部分的这两个标识符。

在我们继续之前，请务必注意下面参数验证中描述的步骤，并确保您愿意信任 orig_user_id 和 user_id 指示的两个值。

检查您的映射表中是否存在与入站分析 ping 相对应的任何值。在上面的示例中，第一个页面浏览发生在非发布商源的 AMP 页面上，然后第二个页面浏览发生在发布商源上。因此，分析 ping 查询参数的值将如下所示

案例 #1：当分析 ping 从发布商源页面发送时，标识符的排列

	发布商源上的用户 ID	不在发布商源上的 AMP 页面上的用户 ID（“别名”）
在分析 ping 中如何表达	`user_id=$publisher_origin_id`	`orig_user_id=$amp_client_id`
参数键	`user_id`	`orig_user_id`
参数值	`$publisher_origin_id`	`$amp_client_id`

请注意，来自第一个页面浏览的标识符对应于最右侧的列，来自第二个页面浏览的标识符位于中间列，这与我们上面的示例流程的构造方式一致。

如果用户首先从发布商源提供的页面开始，然后导航到非发布商源的 AMP 页面，则参数的键将反转，但我们引用值的方式不会反转（即 $amp_client_id 始终指的是存储在非发布商源的 AMP 页面上的标识符）

案例 #2：当分析 ping 从非发布商源的 AMP 页面发送时，标识符的排列

	发布商源上的用户 ID	不在发布商源上的 AMP 页面上的用户 ID（“别名”）
在分析 ping 中如何表达	`orig_user_id=$publisher_origin_id`	`user_id=$amp_client_id`
参数键	`orig_user_id`	`user_id`
参数值	`$publisher_origin_id`	`$amp_client_id`

在搜索映射表时，请注意适用哪种情况，并在映射表的列中查找您期望出现的值。例如，如果分析 ping 是从发布商源页面发送的（案例 #1），则在映射表的“发布商源上的用户 ID”列中检查以 user_id 为键的值，并在“非发布商源的 AMP 页面上的用户 ID (‘别名’)”列中检查以 orig_user_id 为键的值。

如果您在映射表中找不到任何标识符值，请建立新的映射

如果分析请求来自您发布商源的页面，则应选择与 uid 对应的值作为分析记录标识符；选择 orig_uid 的值作为“别名”。
如果分析请求不是来自您发布商源的页面，则应选择与 uid 对应的值作为映射表中的“别名”值。然后，按照任务 4中的剩余说明继续操作，创建一个潜在的发布商源标识符，并尝试将此值设置为该源上的 Cookie。

参数验证

URL 中包含的值可能会被恶意更改、格式错误或以某种方式不是您期望的值。这有时被称为跨站点请求伪造。正如确保您的分析服务器接收到的分析 ping 来自您期望发送分析 ping 的页面一样重要，当您“转发” URL 中包含的值时，请务必验证引荐来源，以确保您可以信任这些值。

例如，在上面的步骤中，我们构造了以下 URL，目的是让用户点击并导航到相应的页面

https://example.com/step2.html?orig_user_id=$amp_client_id

但是，用户或某些攻击者也完全有可能将此 URL 更改为

https://example.com/step2.html?orig_user_id=$malicious_value

您要确保只处理 $amp_client_id 的实例，并避免使用 $malicious_value 的实例。

验证通过 URL 查询参数接收的值的建议步骤： 确认着陆页的引荐来源与您期望看到的 URL 匹配。这通常应该是您在有效的 CORS 请求中看到携带先前看到的标识符值的 URL。我们建议您只接受此类已知标识符。

在非 AMP 页面上，直接在客户端检查 document.referrer，或将该值作为分析 ping 的一部分传递，以便能够在服务器端进行验证。如果引荐来源值是您可以信任的，则可以接受和处理源自着陆页 URL 的值，例如上面示例中的 orig_user_id。

在 AMP 页面上，使用文档引荐来源替换变量将引荐来源值作为分析 ping 的一部分传递。服务器端处理是唯一可用的选项。为了说明，这是一个着陆页可以发送的分析 ping，其中包含 (1) 当前页面的客户端 ID 值，(2) 通过 URL 传递的值，我们已将其设置为引荐页面中的客户端 ID 值，以及 (3) 引荐来源信息本身，用于验证 (2) 的值：https://analytics.example.com/ping?type=pageview&orig_user_id=${queryParam(ref_id)}&user_id=${clientId(uid)}&referrer=${documentReferrer}

如果您无法信任引荐来源，则拒绝通过 URL 参数提供的任何值，并且不要使用它们。

强烈建议的做法

仅保留一个关联

任何两个上下文的标识符之间应仅保持一个关联。 如果您之前与您发出的 Cookie 或其他用户标识符关联的 AMP 客户端 ID 与您发出新的 Cookie 或用户标识符一起出现，则应删除您针对先前的 Cookie 和用户标识符持有的所有状态。

这些步骤将有助于确保与用户对隐私的期望保持一致。如前几节所述，在 AMP 中管理用户状态通常涉及存储和关联在显示 AMP 内容的多个上下文中不同的标识符。绝不应滥用这种情况来重建数据或执行用户不期望的或您未向用户明确披露的跟踪，例如，在用户删除其您网站的 Cookie 之后。

您应尊重提供给用户的所有适用隐私控制，包括创建删除所有 Cookie 和本地存储的功能的任何此类控制。 在用户明确删除标识符关系的其中一方后，绝不应使用 AMP 客户端 ID 或 AMP 基础结构来重建已删除的标识符。

遵守当地法律法规

关联来自两个或多个域的 Cookie 和/或标识符可能需要在某些司法管辖区更新您的隐私政策、提供额外的用户披露或获得最终用户同意。 每个发布商应根据所有关于数据收集、存储、处理和用户通知的适用法律和法规来分析 AMP 客户端 ID 的使用，AMP 客户端 ID 使用 Cookie 或本地存储作为持久存储的方式来提供稳定的标识符。