[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["没有我需要的信息","missingTheInformationINeed","thumb-down"],["太复杂/步骤太多","tooComplicatedTooManySteps","thumb-down"],["内容需要更新","outOfDate","thumb-down"],["翻译问题","translationIssue","thumb-down"],["示例/代码问题","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-07-26。"],[[["\u003cp\u003eApplications must utilize OAuth 2.0 for authorization when accessing the User Deletion API to manage user data, as no other authorization protocols are supported.\u003c/p\u003e\n"],["\u003cp\u003eThe authorization process involves registering your application with Google, obtaining necessary credentials, requesting specific data access scopes, and receiving an access token upon user consent.\u003c/p\u003e\n"],["\u003cp\u003eDifferent OAuth 2.0 flows cater to various application types, such as web server, client-side, installed applications, and service accounts, each with its own implementation and use cases.\u003c/p\u003e\n"],["\u003cp\u003eCommon authorization issues include expired access tokens, incorrect scopes, and insufficient user permissions, leading to specific error codes like 401 and 403.\u003c/p\u003e\n"],["\u003cp\u003eRefresh tokens enable continued access to user data, but they have limitations and can become invalid if the maximum limit per client/account pair is exceeded.\u003c/p\u003e\n"]]],["Applications must use OAuth 2.0 to authorize requests to the Analytics API. This involves registering the application with the Google API Console to obtain a client ID and secret, and activating the Analytics API. When access to user data is needed, the application requests a specific scope, and the user is shown a consent screen. Upon approval, Google grants the application a short-lived access token, which is then used for data requests. Refresh tokens can be used to aquire new access token, but are limited to 25 per client/account pair.\n"],null,["This guide describes how an application authorizes requests to the\nUser Deletion API.\n\nAuthorize requests\n\nBefore users can view their account information on the Google Analytics web\nsite, they must first sign in to their Google Accounts. Similarly, when users\nfirst access your application, they need to authorize your application to access\ntheir data.\n\nEvery request your application sends to the Analytics API must include an authorization token. The token also identifies your application to Google.\n\nAbout authorization protocols\n\nYour application must use [OAuth 2.0](https://developers.google.com/identity/protocols/OAuth2) to authorize requests. No other authorization protocols are supported. If your application uses [Sign In With Google](https://developers.google.com/identity/gsi/web), some aspects of authorization are handled for you.\n\nAuthorizing requests with OAuth 2.0\n\nAll requests to the Analytics API must be authorized by an authenticated user.\n\nThe details of the authorization process, or \"flow,\" for OAuth 2.0 vary somewhat depending on what kind of application you're writing. The following general process applies to all application types:\n\n1. When you create your application, you register it using the [Google API Console](https://console.cloud.google.com/). Google then provides information you'll need later, such as a client ID and a client secret.\n2. Activate the Analytics API in the Google API Console. (If the API isn't listed in the API Console, then skip this step.)\n3. When your application needs access to user data, it asks Google for a particular **scope** of access.\n4. Google displays a **consent screen** to the user, asking them to authorize your application to request some of their data.\n5. If the user approves, then Google gives your application a short-lived **access token**.\n6. Your application requests user data, attaching the access token to the request.\n7. If Google determines that your request and the token are valid, it returns the requested data.\n\nSome flows include additional steps, such as using **refresh tokens** to acquire new access tokens. For detailed information about flows for various types of applications, see Google's [OAuth 2.0 documentation](https://developers.google.com/identity/protocols/OAuth2).\n\nHere's the OAuth 2.0 scope information for the Analytics API:\n\n| Scope | Meaning |\n|-----------------------------------------------------------|------------------------------------------|\n| `https://www.googleapis.com/auth/analytics.user.deletion` | Delete data using the User Deletion API. |\n\nTo request access using OAuth 2.0, your application needs the scope information, as well as\ninformation that Google supplies when you register your application (such as the client ID and the\nclient secret).\n\n**Tip:** The Google APIs client libraries can handle some of the authorization process for you. They are available for a variety of programming languages; check the [page with libraries and samples](/analytics/devguides/config/userdeletion/v3/libraries) for more details.\n\nCommon OAuth 2.0 Flows\n\nThe following lists common use cases for specific OAuth 2.0 flows:\n\n[Web Server](/accounts/docs/OAuth2WebServer)\n\nThis flow is good for automated, offline, or scheduled access of a user's Google\nAnalytics data.\n\nExample:\n\n- Automatically updating user dashboards with the latest Google Analytics data.\n\n| **Note:** The user must complete a one-time auth flow to grant your application offline access to their Google Analytics data. Afterwards, a [refresh\n| token](/accounts/docs/OAuth2WebServer#offline) can be used to obtain a new access token.\n\n[Client-side](/accounts/docs/OAuth2UserAgent)\n\nThis flow is ideal for applications when users interact directly with the\napplication to access their Google Analytics data within a browser. It\neliminates the need for server-side capabilities, but it makes automated,\noffline, or scheduled reporting impractical.\n\nExample:\n\n- A browser based reporting tool such as the [Analytics Query\n Explorer](//ga-dev-tools.web.app/explorer/).\n\n[Installed Applications](/accounts/docs/OAuth2InstalledApp)\n\nThis flow is for applications that are distributed as a package and installed by\nthe user. This flow requires that the application or user have access to a\nbrowser to complete the authentication flow.\n\nExamples:\n\n- A desktop widget on a PC or Mac.\n- A plugin for a content management system --- The benefit of this flow compared to web server or client-side is that a single API Console project can be used for your application. This allows for consolidated reporting and a simpler installation for users.\n\n[Service Accounts](/accounts/docs/OAuth2ServiceAccount)\n\nService accounts are useful for automated, offline, or scheduled access to\nGoogle Analytics data for your own account. For example, to build a live\ndashboard of your own Google Analytics data and share it with other users.\n\n\nTo get started using Analytics API, you need to first\n[use\nthe setup tool](https://console.cloud.google.com/start/api?id=analytics&credential=client_key), which guides you through creating a project in the\nGoogle API Console, enabling the API, and creating credentials.\n\nTo set up a new service account, do the following:\n\n1. Click **Create credentials \\\u003e Service account key**.\n2. Choose whether to download the service account's public/private key as a standard P12 file, or as a JSON file that can be loaded by a Google API client library.\n\nYour new public/private key pair is generated and downloaded to your machine;\nit serves as the only copy of this key. You are responsible for storing it\nsecurely.\n\n\u003cbr /\u003e\n\n| **Note:** You need to add the service account email address as an authorized user of the view (profile) you want to access.\n\nTroubleshooting\n\nYour authorization fails in these situations:\n\n- You will get a `401` status code if your `access_token` has expired or if\n you are using the wrong [scope](#scopes) for the API.\n\n- You will get a `403` status code if the authorized user does not have access\n to the view (profile). Make sure you are authorized with the correct user\n and that they indeed have the view (profile) you have selected.\n\n[OAuth 2.0 playground](/oauthplayground)\n\nThis tool lets you go through the entire authorization flow through a web\ninterface. The tool also displays all the HTTP request headers required for\nmaking an authorized query. If you can't get authorization to work in your own\napplication, you should try to get it working through the OAuth 2.0 playground.\nThen you can compare the HTTP headers and request from the playground to what\nyour application is sending to Google Analytics. This check is a simple way to\nensure you format your requests properly.\n\nInvalid grant\n\nWhen you try to use a refresh token, the following returns you an\n`invalid_grant` error:\n\n- Your server's clock is not in sync with [network time protocol -\n NTP](//en.wikipedia.org/wiki/Network_Time_Protocol).\n- The refresh token limit has been exceeded.\n\nApplications can request multiple refresh tokens to access a single Google\nAnalytics account.\n\nFor example, if a user wants to install an application on multiple machines and\naccess the same Google Analytics account, then a separate token would be\nrequired for each machine. When the number of refresh tokens exceeds the limit,\nolder tokens become invalid. If the application attempts to use an invalidated\nrefresh token, an `invalid_grant` error response is returned.\n\nThe limit for each unique pair of OAuth 2.0 client and Google Analytics account\nis **25 refresh tokens**. If the application continues to request refresh tokens\nfor the same Client/Account pair, once the 26th token is issued, the 1st refresh\ntoken that was previously issued will become invalid. The 27th requested refresh\ntoken would invalidate the 2nd previously issued token and so on.\n| **Note:** The limit of **25 refresh tokens** is subject to change."]]
