使用 AMP 管理未經驗證的使用者狀態

背景
- AMP 頁面的顯示環境
- 多個環境表示多種狀態管理
實作指南
強烈建議的做法

使用者狀態是當今網路上一個重要的概念。請思考下列透過管理使用者狀態而實現的使用案例：

商家建置一個實用的購物車，在使用者第二次瀏覽時，顯示與數週前第一次瀏覽時加入購物車的相同商品。這種體驗可確保使用者持續注意到過去考慮購買的商品，進而提高購買機率。
新聞發布商可以根據讀者重複瀏覽發布商文章的行為，為讀者量身打造推薦文章，這有助於維持讀者的參與度並發掘更多內容。
網站開發人員 (無論執行何種類型的網站) 收集分析資料，以判斷兩個網頁瀏覽量是來自同一個人瀏覽兩個網頁，還是來自兩個人分別瀏覽一個網頁。掌握這種洞察力有助於瞭解網站的效能，並最終瞭解如何改進網站。

本文旨在協助您更成功地管理 AMP 中未經驗證的使用者狀態，這是一種提供流暢使用者歷程的方式，即使使用者未採取提供身分資訊的動作 (例如登入)。在回顧一些處理此主題的挑戰和考量因素後，本指南概述 AMP 支援使用者狀態的方式，並提供關於如何進行技術實作的建議。

背景

使用者狀態的主題在 AMP 中值得特別關注，因為 AMP 頁面可以顯示在多個環境中，例如在您的網站上、在 Google 搜尋或第三方應用程式中。當使用者在這些環境之間移動時，這會對使用者狀態的管理帶來挑戰。

AMP 頁面的顯示環境

您可以將 AMP 視為一種可攜式內容格式，讓內容可以在任何地方快速載入。AMP 文件可以透過三個值得注意的環境顯示：

發布商的網域
AMP 快取
AMP 檢視器

環境	可以從這裡提供非 AMP 頁面嗎？	可以從這裡提供 AMP 頁面嗎？	範例網址
發布商的網域	是	是	`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 設定可能會在某些情況下阻止此操作，因此這組任務可能不足以完全管理所有情境中的使用者狀態。

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

第 2 部分：在連結和表單提交中使用用戶端 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：

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` 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

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

在判斷您未能成功讀取發布商網域識別碼後，請立即檢查分析資料 ping 中包含的 AMP 用戶端 ID 是否已在對應中使用。為此，首先查閱傳入的 amp-analytics 請求以取得用戶端 ID 值。例如，從這個請求：

我們擷取與 AMP 用戶端 ID 對應的粗體部分：$amp_client_id。

我們的對應表將分析資料 ping 中看到的 AMP 用戶端 ID 值與發布商網域識別碼關聯，如下所示：	發布商網域上的使用者 ID
`接下來，檢查對應表以嘗試在「別名」欄中尋找相同的值：`	`$existing_publisher_origin_identifier`

$amp_client_id

在上面的範例中，我們找到一個已存在的記錄。我們找到的與 AMP 用戶端 ID 配對的值將成為分析記錄識別碼。在這裡，它是 $existing_publisher_origin_identifier。建立分析記錄識別碼後，我們可以跳到「資料儲存」章節。

否則，如果在對應中找不到 AMP 用戶端 ID，我們需要建立一個對應：
產生預期發布商網域識別碼。在以下範例中，我們將其稱為 $prospective_identifier。此值的建立方式應與您在發布商網域上設定值的方式一致，如上方的任務 1中所述。
接下來，嘗試在發布商網域上將預期發布商網域識別碼設定為 Cookie。如果可以寫入第三方 Cookie，這將成功，否則將失敗。

然後，儲存 {預期發布商網域識別碼，AMP 用戶端 ID} 配對。

我們的對應表將分析資料 ping 中看到的 AMP 用戶端 ID 值與發布商網域識別碼關聯，如下所示：	發布商網域上的使用者 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 變數替換項。

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

更新外連連結以使用用戶端 ID 替換項： 定義一個新的查詢參數 ref_id (「參照來源 ID」)，它將出現在網址中，並指示使用者的來源環境識別碼。將此查詢參數設定為等於 AMP 用戶端 ID 替換項的值：

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

用於將用戶端 ID 傳遞到外連連結的替代解決方案： 將新的查詢參數 ref_id 定義為資料屬性 data-amp-addparams 的一部分，對於需要參數替換的查詢，請提供這些詳細資訊作為 data-amp-replace 的一部分。使用此方法，網址看起來會很簡潔，並且 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>

對於透過 data-amp-addparams 傳遞多個查詢參數，請將它們以 & 分隔，例如：

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

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

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

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

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

擷取網址查詢參數

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

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

如果資訊可透過網址取得，並且您希望處理它，則可以使用幾種方法：
在重新導向期間處理 (伺服器端處理)

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

在登陸頁面處理 (用戶端處理)

在重新導向期間處理 (伺服器端處理)

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

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 值。依照下方「參數驗證」章節中概述的步驟，驗證值的真實性。然後，建構將包含從 ref_id 衍生的 orig_user_id 和基於第一方 Cookie 識別碼值的 user_id 的分析 ping。

重要

如果您選擇在到達頁面上於用戶端處理參數，則到達頁面應在識別碼被擷取後立即從 URL 中移除識別碼資訊。

在移除參數之前，請確保需要執行以讀取這些參數的其他程式碼已經

在移除發生之前執行；或

可以存取程式碼儲存資料的位置，該程式碼已讀取並移除了參數

若要在您的非 AMP 頁面上執行此操作，請包含以下 JavaScript，它將從 URL 中移除所有查詢參數
var href = location.href.replace(/\?[^#]+/, '');
history.replaceState(null, null, href);
視需要調整此程式碼以移除較少的查詢參數。

在分析 ping 中處理多個識別碼

與我們在 Task 4 中將分析 ping 設定為僅包含一個識別碼值不同，透過我們在 Task 5 中目前採取的步驟，我們現在有兩個識別碼 — orig_user_id 和 user_id。接下來我們將介紹如何處理屬於 inbound 分析 ping 的這兩個識別碼。

在我們繼續之前，請務必注意下方「參數驗證」中描述的步驟，並確保您願意信任由 orig_user_id 和 user_id 指示的這兩個值。

檢查與 inbound 分析 ping 對應的值是否出現在您的對應表中。在我們上面的範例中，第一個頁面瀏覽發生在「非」發布商來源的 AMP 頁面上，接著第二個頁面瀏覽發生在發布商來源上。因此，分析 ping 查詢參數的值將如下所示

案例 #1：當分析 ping 從發布商來源的頁面傳送時的識別碼排列方式

	我們的對應表將分析資料 ping 中看到的 AMP 用戶端 ID 值與發布商網域識別碼關聯，如下所示：	發布商網域上的使用者 ID
在分析 ping 中的表示方式	`user_id=$publisher_origin_id`	`orig_user_id=$amp_client_id`
參數鍵	`user_id`	`orig_user_id`
參數值	`$publisher_origin_id`	`$existing_publisher_origin_identifier`

請注意，來自第一個頁面瀏覽的識別碼對應到最右欄，而來自第二個頁面瀏覽的識別碼則在中間欄，這與我們上面範例流程的建構方式一致。

相反地，如果使用者從發布商來源提供的頁面開始，然後導航到「非」發布商來源的 AMP 頁面，則參數的鍵將會反轉，但我們參考值的方式不會改變（即 $amp_client_id 始終指的是儲存在「非」發布商來源的 AMP 頁面上的識別碼）

案例 #2：當分析 ping 從「非」發布商來源的 AMP 頁面傳送時的識別碼排列方式

	我們的對應表將分析資料 ping 中看到的 AMP 用戶端 ID 值與發布商網域識別碼關聯，如下所示：	發布商網域上的使用者 ID
在分析 ping 中的表示方式	`orig_user_id=$publisher_origin_id`	`user_id=$amp_client_id`
參數鍵	`orig_user_id`	`user_id`
參數值	`$publisher_origin_id`	`$existing_publisher_origin_identifier`

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

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

如果分析請求來自您發布商來源的頁面，則您應該選擇與 uid 對應的值作為分析記錄識別碼；選擇 orig_uid 的值作為「別名」。
如果分析請求不是來自您發布商來源的頁面，則您應該選擇與 uid 對應的值作為對應表中的「別名」值。然後，繼續執行 Task 4 中的剩餘指示，以建立潛在的發布商來源識別碼，並嘗試將此值設定為來源上的 Cookie。

參數驗證

URL 中包含的值可能會被惡意更改、格式錯誤，或以其他方式不是您期望在那裡的值。這有時稱為跨網站請求偽造。正如確保您的分析伺服器接收到的分析 ping 來自您期望發送分析 ping 的頁面非常重要一樣，當您「轉發」URL 中包含的值時，請務必驗證 referrer 以確保您可以信任這些值。

例如，在上面的步驟中，我們建構了以下 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 查詢參數接收的值的建議步驟： 確認到達頁面的 referrer 符合您期望看到的 URL。這通常應該是您在有效的 CORS 請求中看到攜帶先前看過的識別碼值的 URL。我們建議您僅接受此類已知的識別碼。

在非 AMP 頁面上，直接在用戶端檢查 document.referrer，或將該值作為分析 ping 的一部分傳遞，以便能夠在伺服器端驗證。如果 referrer 值是您可以信任的值，那麼您可以接受和處理源自到達頁面 URL 的值，例如上述範例中的 orig_user_id。

在 AMP 頁面上，使用 Document Referrer 替換變數，將 referrer 值作為分析 ping 的一部分傳遞。伺服器端處理是唯一可用的選項。為了說明，以下是到達頁面可以發送的分析 ping，其中包含 (1) 當前頁面的用戶端 ID 值，(2) 透過 URL 傳遞的值，我們已將其設定為參考頁面中的用戶端 ID 值，以及 (3) referrer 資訊本身，用於驗證 (2) 的值： https://analytics.example.com/ping?type=pageview&orig_user_id=${queryParam(ref_id)}&user_id=${clientId(uid)}&referrer=${documentReferrer}

如果您無法信任 referrer，則拒絕透過 URL 參數提供的任何值，並且不要使用它們。

強烈建議的做法

僅保留一個關聯

任何兩個內容的識別碼之間應僅維護一個關聯。 如果先前與您發布的 Cookie 或其他使用者識別碼關聯的 AMP 用戶端 ID 與您發布的新 Cookie 或使用者識別碼一起出現，您應該刪除您針對先前的 Cookie 和使用者識別碼持有的所有狀態。

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

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

遵守當地法律和法規

從兩個或多個網域關聯 Cookie 和/或識別碼可能需要在某些司法管轄區更新您的隱私權政策、提供額外的使用者揭露或取得最終使用者同意。 每個發布商都應針對所有關於資料收集、儲存、處理和使用者通知的適用法律和法規，分析 AMP 用戶端 ID 的使用情況，該用戶端 ID 使用 Cookie 或本機儲存空間作為持久儲存的方式來提供穩定的識別碼。