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

目录

• 背景
  • AMP 页面的显示上下文
  • 多个上下文意味着多个状态管理
• 实施指南
  • 开始之前
  • 任务 1：对于发布者来源上的非 AMP 页面，设置标识符并发送分析 ping
  • 任务 2：对于 AMP 页面，通过在 amp-analytics ping 中包含客户端 ID 替换来设置标识符并发送分析 ping
  • 任务 3：处理来自发布者来源上的页面的分析 ping
  • 任务 4：处理来自 AMP 缓存或 AMP 查看器显示上下文的分析 ping，并建立标识符映射（如果需要）
  • 任务 5：在链接和表单提交中使用客户端 ID
• 强烈推荐的做法
  • 只保留一个关联
  • 尊重 cookie 和本地存储删除
  • 遵守当地法律法规

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

• 一位商家构建了一个有用的购物车，在用户第二次访问时向其展示他们在几周前的第一次访问期间添加到购物车中的相同商品。这种体验通过确保用户始终了解他们过去考虑购买的商品，从而增加了他们购买该商品的机会。
• 一位新闻发布者可以根据读者反复访问发布者的文章，为读者定制推荐文章，这有助于让读者保持参与并发现更多内容。
• 运行任何类型网站的网站开发人员收集分析，可以判断两个页面浏览量属于看到两个页面的同一个人，还是属于看到单个页面的两个人。获得此洞察有助于了解网站的运行情况，并最终了解如何改进网站。

本文旨在帮助您更成功地管理 AMP 中的非认证用户状态，即使用户未采取提供其身份（例如登录）的操作，也可以提供无缝的用户旅程。在回顾了处理此主题时面临的一些挑战和注意事项后，本指南概述了 AMP 支持用户状态的方式，并提供了有关如何处理技术实现的建议。

背景

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

AMP 页面的显示上下文

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

• 发布者的来源
• AMP 缓存
• AMP 查看器

让我们仔细研究每种情况。

上下文 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 设置在某些情况下可能会阻止这一点，因此这组任务可能不足以在所有场景中完全管理用户状态。

在奠定基础后，我们随后访问一个用例范围较窄但为这些用例提供完整解决方案的主题。

部分 #2：在链接和表单提交中使用客户端 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，你将看到没有与 uid 对应的 Cookie 中设置的值

> 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 查看器中显示。

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

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

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

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

值得了解

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

在发布者来源中，最简单的想法是将“范围”视为您对 Cookie 的称呼。通过在 任务 2 中推荐客户端 ID 参数的值为 uid，我们与在 任务 1 中使用名为 uid 的 Cookie 的选择保持一致。

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

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

下表对此进行了说明

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

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

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

审查问题

考虑以下流程

1. 用户访问AMP 查看器显示上下文中的 AMP 页面，例如https://google.com/amp/s/example.com/article.amp.html。由于 AMP 查看器无法访问发布者来源上的uid cookie，因此生成了一个随机值$amp_client_id来识别用户。
2. 然后，同一用户访问发布者来源上的页面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 值与发布者原始标识符，如下所示

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

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

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

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

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

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

1. 生成一个预期发布者原始标识符。在以下示例中，我们称之为 $prospective_identifier。此值应根据您在发布者原始标识符上设置值的方式创建，如上文 任务 1 中所述。
2. 接下来，尝试将预期发布者原始标识符 设置为 发布者原始标识符上的 cookie。如果可以写入第三方 cookie，则此操作将成功，否则将失败。
3. 然后，存储 {预期发布者原始标识符、AMP 客户端 ID} 对。

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

我们将预期发布者原始标识符用作分析记录标识符，因为这是与发布者原始标识符上的状态关联的值。在这种情况下，即 $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 时的标识符排列

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

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

案例 #2：从不在发布者来源上的 AMP 页面发送分析 ping 时的标识符排列

在搜索映射表时，请注意适用哪种情况，并在映射表的列中搜索预期出现的值。例如，如果分析 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 的一部分传递。服务器端处理是唯一可用的选项。为了说明，以下是登录页面可以发送的包含 (1) 当前页面的客户端 ID 值、(2) 我们已设置为引荐页面中客户端 ID 值的通过 URL 传递的值以及 (3) 引荐来源信息本身以验证 (2) 的值的分析 ping：https://analytics.example.com/ping?type=pageview&orig_user_id=${queryParam(ref_id)}&user_id=${clientId(uid)}&referrer=${documentReferrer}

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

强烈推荐的做法

仅保留一个关联

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

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

尊重 cookie 和本地存储删除

您应尊重向用户提供的全部适用的隐私控制，包括创建删除所有 Cookie 和本地存储的能力的任何此类控制。在用户明确删除标识符关系的一方之后，AMP 客户端 ID 或 AMP 基础设施不得在任何时候用于重建已删除的标识符。

遵守当地法律法规

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