本指南說明應用程式如何授權向 User Deletion API 提出要求。
授權要求
使用者必須先登入 Google 帳戶，才能在 Google Analytics 網站上查看自己的帳戶資訊。同樣地，當使用者首次存取您的應用程式時，他們需要授權應用程式存取其資料。
您的應用程式傳送至 Analytics API 的每項要求都必須包含授權權杖。這個權杖也可讓 Google 識別您的應用程式。
關於授權通訊協定
您的應用程式必須使用 OAuth 2.0 對要求進行授權，系統不支援其他授權通訊協定。如果您的應用程式採用使用 Google 帳戶登入功能，系統會為您處理部分授權事項。
使用 OAuth 2.0 對要求進行授權
所有 Analytics API 要求都必須獲得已驗證使用者的授權。
OAuth 2.0 授權程序 (或「流程」) 的細節會根據您編寫的應用程式類型而有所不同。下列一般程序適用於所有應用程式類型：
- 建立應用程式後，請透過 Google API 控制台註冊應用程式。接著 Google 會向您提供稍後需要的資訊，例如用戶端 ID 和用戶端密碼。
- 在 Google API 控制台中啟用 Analytics API。(如果 API 控制台裡沒有列出該 API，則可略過這個步驟)。
- 當應用程式需要存取使用者資料時，會向 Google 要求特定的存取範圍。
- Google 會向使用者顯示同意畫面，請對方授權您的應用程式要求部分資料。
- 如果使用者同意，Google 即會授予短期存取權杖給您的應用程式。
- 您的應用程式向使用者要求資料，並且在要求中附上存取權杖。
- 如果 Google 判定您的要求與權杖有效，便會傳回您要求的資料。
部分流程包含額外步驟，例如使用「更新權杖」來取得新的存取權杖。如要進一步瞭解各類應用程式的流程，請參閱 Google 的 OAuth 2.0 說明文件。
以下列出 Analytics API 的 OAuth 2.0 範圍相關資訊：
| 範圍 | 意義 |
|---|---|
https://www.googleapis.com/auth/analytics.user.deletion |
使用 User Deletion API 刪除資料。 |
如要透過 OAuth 2.0 要求存取權，您的應用程式需要範圍資訊，以及 Google 在您註冊應用程式時提供的資訊 (例如用戶端 ID 和用戶端密碼)。
提示：Google API 用戶端程式庫可以為您處理部分授權程序，且適用於多種程式設計語言；詳情請參閱程式庫和範例頁面。
常見的 OAuth 2.0 流程
以下列出特定 OAuth 2.0 流程的常見用途：
網頁伺服器
這個流程適用於自動、離線或排程存取使用者 Google Analytics 資料的情況。
範例：
- 自動更新使用者資訊主頁，以便顯示最新的 Google Analytics 資料。
用戶端
此流程非常適合使用者直接與應用程式互動，以便在瀏覽器中存取 Google Analytics 資料。這麼做可免除使用伺服器端功能的需求，但會導致自動、離線或排程報表無法使用。
範例：
- 以瀏覽器為基礎的報表工具，例如 Analytics Query Explorer。
已安裝的應用程式
這個流程適用於以套件形式發布，並由使用者安裝的應用程式。此流程需要應用程式或使用者有權存取瀏覽器，才能完成驗證流程。
範例：
- 電腦或 Mac 上的桌面小工具。
- 內容管理系統外掛程式：相較於網頁伺服器或用戶端，這個流程的好處是應用程式可使用單一 API 主控台專案。這可讓您統整報表，並為使用者提供更簡便的安裝方式。
服務帳戶
服務帳戶可用於自動、離線或排程存取您帳戶的 Google Analytics 資料。例如，建立自己的 Google Analytics 資料即時資訊主頁，並與其他使用者分享。
如要開始使用 Analytics API，請先使用設定工具；這項工具會引導您在 Google API 控制台中建立專案、啟用 API，並建立憑證。
如要設定新的服務帳戶，請按照下列步驟操作：
- 依序按一下 [Create credentials] (建立憑證) > [Service account key] (服務帳戶金鑰)。
- 選擇要將服務帳戶的公開/私密金鑰下載為標準 P12 檔案，還是可透過 Google API 用戶端程式庫載入的 JSON 檔案。
接著，系統就會為您產生新的公開/私密金鑰，並下載至您的電腦中；這是金鑰的唯一副本，您必須負責妥善保管。
疑難排解
在下列情況中，授權失敗：
如果
access_token已過期，或您使用錯誤的 API 範圍，就會收到401狀態碼。如果授權使用者沒有資料檢視 (個人資料) 的存取權，您會收到
403狀態碼。請確認您已獲得正確使用者的授權，且該使用者確實擁有您選取的檢視畫面 (設定檔)。
OAuth 2.0 Playground
這個工具可讓您透過網頁介面完成整個授權流程。這項工具也會顯示提出授權查詢所需的所有 HTTP 要求標頭。如果您無法取得授權在自己的應用程式中運作，建議您透過 OAuth 2.0 Playground 嘗試執行這項動作。接著，您可以比較 Playground 中的 HTTP 標頭和要求，以及應用程式傳送至 Google Analytics 的內容。這項檢查是確保您正確設定要求格式的簡單方法。
授權無效
嘗試使用重新整理權杖時，系統會傳回 invalid_grant 錯誤：
- 您的伺服器時鐘未與網路時間通訊協定 - NTP 保持同步。
- 已超過重新整理權杖限制。
應用程式可以要求多個重新整理權杖，存取單一 Google Analytics 帳戶。
舉例來說，如果使用者想在多部電腦上安裝應用程式，並存取相同的 Google Analytics 帳戶，則每部電腦都需要個別的符記。當重新整理權杖數量超過上限時，較舊的權杖就會失效。如果應用程式嘗試使用失效的重新整理權杖，系統會傳回 invalid_grant 錯誤回應。
每組 OAuth 2.0 用戶端和 Google Analytics 帳戶不重複組合的數量上限為 25 個更新權杖。如果應用程式繼續為相同的客戶端/帳戶組合要求重新整理權杖，第 26 個權杖一經核發，先前核發的第 1 個重新整理權杖就會失效。第 27 個要求的更新憑證會使先前核發的第 2 個憑證失效，以此類推。