What happens when a user requests deletion of their GA4 data?
Under GDPR (and UK GDPR), data subjects have the right to erasure ("right to be forgotten"). If your GA4 implementation processes personal data, users can request deletion. GA4 provides a Data Deletion Request tool that deletes event data and user data matching specified criteria within 63 days of the request. Critical limitation: GA4 deletion requests are not instantaneous — they take up to 63 days to complete.
During this period the data remains visible in reports. Critically, aggregate data and modelled conversions in Google Ads are not individually deletable — deletion removes the event-level records but aggregated statistics derived from them may persist in historical report snapshots.
The GA4 deletion tools
Data Deletion Requests (event and user property data)
Where: Admin → Data Deletion Requests
What it deletes: Event data and user properties matching the criteria you specify, within a date range you define.
Deletion types:
| Type | What it removes |
|---|---|
| All user data for a specific user | All events associated with a specific User-ID or client_id |
| Specific event parameters | Values of specified event parameters across all users in the date range |
| Specific user properties | Values of specified user properties across all users in the date range |
How to submit:
- Admin → Data Deletion Requests → Create request
- Select date range (must be specific — you cannot delete all data ever)
- Select what to delete: user data (specific user) or event parameters/user properties containing PII
- Submit — Google reviews and processes within 63 days
Limitation: You need to know the user's User-ID or client_id to delete their specific user data. If you haven't implemented User-ID and don't have the _ga cookie value for the specific user, you cannot target their specific records. You can only delete parameters that contained PII across all users in the date range (which is more destructive than a targeted deletion).
Identifying the user's client_id for targeted deletion
For targeted user deletion, you need the GA4 client_id (the value of the _ga cookie for that user). If the user is requesting erasure:
- Ask the user for the
_gacookie value from their browser (Application → Cookies → _gain Chrome DevTools) - The
_gacookie format:GA1.1.XXXXXXXX.XXXXXXXXXX— the client_id is the last two sections:XXXXXXXX.XXXXXXXXXX
Alternatively, if you captured client_id in your CRM or order management system at the time of their transaction, retrieve it from there.
Practical reality: Most users cannot retrieve their own _ga cookie. For standard DSAR responses, the most practical approach for most businesses is:
- If User-ID is implemented: target deletion by User-ID (much simpler)
- If not: submit an event parameter deletion for the date range most likely to contain the user's data, targeting the parameter that contained their identifying information (e.g.,
customer_emailparameter value if you were storing hashed emails)
Handling a full DSAR workflow
When you receive a DSAR mentioning GA4
Step 1 — Identify the scope of GA4 data
Need to validate whether consent timing is distorting your GA4 data?
GA4 collects:
- Pseudonymous session and event data (device ID, session timestamps, events triggered)
- User properties you've set (subscription plan, customer tier, etc.)
- Any accidentally collected PII (if URL redaction isn't configured correctly)
Under most GDPR frameworks, pseudonymous data (device-ID-based) may not constitute "personal data" about an identifiable individual unless it can be linked to a specific person via other data. If you have not implemented User-ID and have no way to link a client_id to the specific data subject, GA4's pseudonymous data may fall outside the scope of the erasure request.
Consult your DPO for the specific determination — this depends on your overall data architecture, not just GA4 in isolation.
Step 2 — If GA4 data is in scope, submit deletion request
If User-ID is implemented:
- Admin → Data Deletion Requests → User data → specify the User-ID for the requesting user → date range: all of their activity history → submit
If User-ID is not implemented and you have the client_id:
- Submit targeted client_id deletion
If neither identifier is available:
- Submit parameter-level deletion for the date range where the user's data might be, targeting any PII-containing parameters
Step 3 — Document the response
Record in your DSAR log:
- Date request received
- Date GA4 deletion request submitted
- GA4 request ID (shown in Admin → Data Deletion Requests after submission)
- Expected completion date (up to 63 days after submission)
- What was deleted (user-level vs parameter-level)
Step 4 — Respond to the data subject
Inform them that deletion is in process and will complete within 63 days. This meets GDPR's requirement to fulfil erasure requests without undue delay (within 30 days, extendable to 60 days for complex requests).
What GA4 cannot delete
Even with a data deletion request:
- Aggregated, non-reversible statistics — historical report summaries (e.g., "May 2025 had 10,000 sessions") that have been aggregated before deletion are not retroactively updated. Standard GA4 reports showing aggregate metrics may not change.
- BigQuery export data — GA4 data exported to BigQuery before the deletion request is NOT deleted by the GA4 deletion tool. You must separately delete the relevant records from BigQuery.
- Google Ads modelled conversion data — modelled conversions already processed for Smart Bidding are not individually deletable.
For GDPR completeness, your deletion process must also cover BigQuery-exported data.
FAQ: GA4 User Deletion and Data Portability: Handling DSARs in
Can ga4 user deletion and data portability: handling dsars in be caused by consent timing instead of a tag bug?
Should I test this only in GA4 reports?
What is the fastest way to prevent this from happening again?
Related guides for GA4 User Deletion and Data Portability: Handling DSARs in
How to Test Consent Mode V2 in 5 Minutes: A DevTools Walkthrough (2026)
Open Chrome DevTools → Network tab → filter for collect → reject all on the cookie banner → confirm GA4 hits still fire with gcs=G100 (denied) and ad_user_data=denied. Then accept all → confirm gcs=G111 (granted). If hits don't fire at all in either state, Consent Mode is misconfigured. If gcs is missing entirely…
GCS Parameter Decoded: What G100, G110, G111 Mean in GA4 Hits
The gcs parameter in GA4 network requests encodes the user's consent state for two of the four Consent Mode signals. Format: G1xy where G1 is constant, x is ad_storage (0=denied, 1=granted), y is analytics_storage (0=denied, 1=granted)…
Validate GA4 User Deletion and Data Portability: Handling DSARs in before it becomes a compliance and reporting problem
Run a free audit to check consent timing, browser behavior, and downstream GA4 impact in one workflow.