Skip to content

Guide 191 · Admin · GA4 + Tag Manager

Delete a user's data with the User Deletion API: one POST, one identifier, and the 63-day wait

Checked 11 November 2026 · Verification: figures recomputed in Python with decimal arithmetic; downloadable JSON carries the same recomputed figures · Steps traced to Analytics Help, opened 11 November 2026 · 7-minute read

The User Deletion API deletes one user's data by programmatic request — one POST, one identifier, and the analytics.edit scope — where the Admin screens handle one request at a time.

Expected signal

After step 5, you hold a deletionRequestTime for exactly one identifier, you know what it does and does not prove, and you know the two dates that bound the wait.

Download the reference: the User Deletion API request (JSON) (1511 bytes, MD5 66bd74b5662dacdddf8fc407f2f7c858). It holds the report or event definition and the worked example with the recomputed figures shown on this page.

What you need

  • The property resource name: properties/ followed by the property ID — for example properties/123456789.
  • An OAuth token with the analytics.edit scope. The call requires https://www.googleapis.com/auth/analytics.edit; a read-only token is refused.
  • Exactly one identifier for the user. userId, clientId, appInstanceId, or userProvidedData — never two. userProvidedData holds one email address or one phone number, normalized before you send it.

The trace

  1. Pick the one identifier you actually have. The request body is a union field: userId is the Google Analytics user ID, clientId is the Google Analytics client ID, appInstanceId is the Firebase app instance ID, and userProvidedData is one email address or one phone number. If you have a user ID from your own sign-in system, send userId. If you only have the browser value, send clientId. Pick one and send only that one.
  2. Normalize userProvidedData before you send it. Email addresses are lowercased, periods are removed before the @ for gmail.com and googlemail.com addresses, and all spaces are removed. Phone numbers have all non-digit characters removed and a + prefix added. The worked example below shows both normalized forms. Send the normalized value, not the typed value: the match is against the normalized form.
  3. Send the POST. POST to https://analyticsadmin.googleapis.com/v1alpha/properties/123456789:submitUserDeletion — the property ID in the path is your property's ID, not the example's. The body holds the one identifier field, for example {"userId": "user_12345"}. Send it with the analytics.edit scope.
  4. Read the response for what it is. A successful response holds one field: deletionRequestTime, an RFC 3339 timestamp such as 2014-10-02T15:01:23Z. It marks the moment for which all visitor data before that point should be deleted, and it is set to the time the request was received. It is a receipt, not a completion notice: it does not say the data is gone yet.
  5. Wait out the removal window, then check. The user's data stops displaying in the user explorer within 24 hours, and it is permanently removed within the next 63 days. The worked example below computes both dates from a request date. There is no status call that reports progress in between — the disappearance from the explorer is the check.

Dead ends

DEAD END — SENDING TWO IDENTIFIERS IN ONE REQUEST. The user field is a union: only one of userId, clientId, appInstanceId, or userProvidedData may be set. A body with two set does not delete two users; it is not a valid request. One request deletes one user by one identifier.

DEAD END — SENDING THE EMAIL AS TYPED. An email sent with capitals, spaces, or periods in a Gmail address does not match the stored normalized form. Normalize first — lowercase, strip the periods before the @ for Gmail addresses, strip the spaces — or the request targets nobody.

DEAD END — EXPECTING A CANCEL BUTTON OR A PROGRESS REPORT. Requesting deletion of user data is not reversible, and the API returns no request ID to track and no status to poll. The response timestamp is the receipt. If the request was wrong, there is nothing to cancel through the API — the 24-hour display check is the first moment you can see it took effect.

End state

The User Deletion API is the programmatic path to the same deletion the Admin screens do one at a time. It suits a deletion queue: one request per user, each with its own receipt timestamp. The worked example below shows both normalized forms and the removal window.

Worked example — stated inputs, recomputed results. The two identifiers below are stated inputs for the example. The normalized forms were recomputed from the documented rules.

IdentifierAs suppliedNormalized for the request
Email[email protected][email protected]
Phone+1 (416) 555-0132+14165550132

For the email, the rule is: lowercase, remove periods before the @ for gmail.com and googlemail.com addresses, remove all spaces — so [email protected] becomes [email protected]. For the phone, the rule is: remove all non-digit characters, add a + prefix — so +1 (416) 555-0132 becomes +14165550132.

For the timeline, a request received on 2026-11-11 stops displaying in the user explorer within 24 hours — by 2026-11-12 — and the data is permanently removed within the next 63 days — by 2027-01-13. 2026-11-11 plus 63 days is 2027-01-13.

Sources

Checked 11 November 2026. The click paths above are the ones in Google's help and developer pages, opened in full on 11 November 2026. No step in this guide was run inside a live Analytics property, because that needs a Google sign-in and this site does not sign in as anyone. The worked-example figures on this page were recomputed in Python with decimal arithmetic, and the downloadable JSON file carries the same recomputed figures. Google moves menu items without warning; if a path on this page no longer matches, the linked help page is the current map.