使用 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-4 對於讓基本功能運作至關重要。它們依賴於一組最少的功能，這些功能是讓工作部分完成所需的功能：AMP 的用戶端 ID 替換、Cookie 的讀取和寫入，以及維護後端對應表。為什麼是「部分」？因為這些工作中傳達的步驟依賴於 Cookie 的讀取和寫入，而且由於瀏覽器的 Cookie 設定可能會在某些情況下阻止此操作，因此這組工作可能不足以在所有情境中完全管理使用者狀態。

在奠定基礎之後，我們接著探討一個使用案例範圍較窄的主題，但該主題為這些使用案例提供了完整的解決方案。

第二部分：在連結和表單提交中使用用戶端 ID： 在工作 5 中，您將學習如何利用連結遍歷和/或表單提交，以在使用者從一個頁面直接遍歷到另一個頁面的情境界線之間傳遞 AMP 用戶端 ID 資訊。

注意

以下實作指南建議使用 Cookie 並與 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 (請求) 傳送到您的分析資料伺服器，其中包含請求網址本身內的實用資料。以下範例也說明瞭如何在請求中加入 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：

請注意，傳遞到用戶端 ID 替換的參數 ${clientId(uid) 是 uid。這是一個刻意的選擇，與工作 1中所述在發布商網域上使用的相同 Cookie 名稱相符。為了獲得最流暢的整合，您應該應用相同的技術。

關於 amp-analytics 實作的其餘部分，請參閱amp-analytics 設定的說明文件，以瞭解關於如何設定 amp-analytics 請求或修改分析資料供應商的請求的更多詳細資訊。Ping 可以進一步修改，以傳輸您直接定義的其他資料，或利用其他AMP 替換。

小知識

為什麼我們對傳遞到用戶端 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 變數替換類型。

更新外連連結以使用 Client ID 替換： 定義一個新的查詢參數 ref_id（「referrer ID」），它將出現在 URL 中，並指示使用者的來源情境識別碼。將此查詢參數設定為等於 AMP 的 Client ID 替換值

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

將 Client 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>

更新表單輸入以使用 Client ID 替換： 為輸入欄位定義一個名稱，例如 orig_user_id。指定表單欄位的 default-value 為 AMP 的 Client ID 替換值

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

透過採取這些步驟，Client ID 可用於目標伺服器，和/或作為使用者在連結點擊或表單提交後登陸的頁面（目標情境）上的 URL 參數。名稱（或「key」）將會是 ref_id，因為這是我們在上述實作中定義的方式，並且將具有與 Client ID 相等的關聯值。例如，透過點擊上面定義的連結 (<a> 標籤)，使用者將導航到此 URL

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

當使用者登陸包含 ref_id 值的頁面時，無論是作為 URL 參數還是標頭，我們都有機會共同處理 ref_id 識別碼以及透過頁面本身公開的識別碼（即 Cookie 值）。透過將兩者都包含在分析 Ping 中，您的分析伺服器可以同時處理這兩個值，並且在知道它們相關的情況下，在您的後端反映這種關係。下一步提供了有關如何執行此操作的詳細資訊。

提取 URL 查詢參數

透過使用替換功能，我們設定了連結導航流程或表單提交流程，將資訊（特別是 Client ID）公開給目標伺服器，和/或作為 URL 參數，使用者完成導航後可以在用戶端讀取。

如果資訊僅公開給伺服器，例如透過表單 POST，那麼您可以繼續處理資訊並呈現結果頁面。在處理此類資料時，請注意以下詳述的關於 參數驗證 的步驟。

如果資訊可透過 URL 取得，並且您希望處理它，則可以使用幾種方法

• 在重新導向期間處理（伺服器端處理）
• 在登陸頁面上處理（用戶端處理）

在重新導向期間處理（伺服器端處理）

若要在重新導向期間處理，請在伺服器上處理請求並提取相關參數。請注意以下詳述的關於 參數驗證 的步驟。處理資料，結合包含其他相關識別碼的 Cookie 值，然後重新導向到不包含參數的 URL。

在登陸頁面上處理（用戶端處理）

若要在登陸頁面上處理，該方法會根據該頁面是 AMP 頁面還是非 AMP 頁面而有所不同。

更新 AMP 頁面： 在您的 amp-analytics 配置中使用查詢參數替換功能，以取得 URL 內的 ref_id 識別碼值。查詢參數功能採用一個參數，該參數指示 URL 中所需鍵值對的「key」，並傳回對應的值。使用 Client 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 頁面，則參數的 Key 將會反轉，但我們參考值的方式不會反轉（即 $amp_client_id 始終指的是儲存在不在發布商來源的 AMP 頁面上的識別碼）

案例 #2：當分析 Ping 從不在發布商來源的 AMP 頁面傳送時的識別碼排列

當您搜尋對應表時，請注意哪種情況適用，並在您預期它們出現的對應表欄中搜尋值。例如，如果分析 Ping 是從發布商來源的頁面傳送的（案例 #1），則檢查對應表中「發布商來源上的使用者 ID」欄中以 user_id 為 Key 的值，並檢查「不在發布商來源的 AMP 頁面上的使用者 ID（「別名」）」欄中以 orig_user_id 為 Key 的值。

如果您在對應表中找不到正在使用的任何一個識別碼值，請建立新的對應

• 如果分析請求來自您的發布商來源的頁面，那麼您應該選擇與 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 頁面上，使用 Document Referrer 替換變數，將來源頁面值作為分析 Ping 的一部分傳遞。伺服器端處理是唯一可用的選項。為了說明，以下是登陸頁面可以傳送的分析 Ping，其中包含 (1) 當前頁面的 Client ID 值，(2) 透過 URL 傳遞的值（我們已設定為來源頁面中的 Client 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 Client ID 與您發布的新 Cookie 或使用者識別碼一起出現，則您應刪除您針對先前 Cookie 和使用者識別碼持有的所有狀態。

這些步驟將有助於確保與使用者對隱私的期望保持一致。如前幾節所述，在 AMP 中管理使用者狀態通常涉及跨多個顯示 AMP 內容的情境儲存和關聯不同的識別碼。絕不應濫用這種情況來重建資料或執行使用者不期望或您未明確向使用者揭露的追蹤，例如，在使用者刪除其網站的 Cookie 後。

尊重 Cookie 和本機儲存體的刪除

您應尊重所有適用於使用者的隱私控制，包括任何建立刪除所有 Cookie 和本機儲存體的能力的此類控制。 在任何時候都不應使用 AMP Client ID 或 AMP 基礎架構來 重建已刪除的識別碼，在使用者明確刪除識別碼關係的一方之後。

遵守當地法律和法規

關聯來自兩個或多個網域的 Cookie 和/或識別碼可能需要更新您的隱私權政策、提供額外的使用者揭露，或在某些司法管轄區獲得最終使用者同意。 AMP Client ID 的使用（它使用 Cookie 或本機儲存體作為持久儲存的方式來提供穩定的識別碼）應由每個發布商根據所有關於資料收集、儲存、處理和使用者通知的適用法律和法規進行分析。