Launch Offer2 free audits with all 229 checks. No credit card required.Start free audit

GA4 User Deletion and Data Portability: Handling DSARs in 2026

Intermediate

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:

TypeWhat it removes
All user data for a specific userAll events associated with a specific User-ID or client_id
Specific event parametersValues of specified event parameters across all users in the date range
Specific user propertiesValues of specified user properties across all users in the date range

How to submit:

  1. Admin → Data Deletion Requests → Create request
  2. Select date range (must be specific — you cannot delete all data ever)
  3. Select what to delete: user data (specific user) or event parameters/user properties containing PII
  4. 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:

  1. Ask the user for the _ga cookie value from their browser (Application → Cookies → _ga in Chrome DevTools)
  2. The _ga cookie 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:

  1. If User-ID is implemented: target deletion by User-ID (much simpler)
  2. 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_email parameter 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?

Yes. Many consent-related issues come from when the signal arrives, not whether the setting exists in the interface. Browser-level validation matters more than screenshots of the CMP setup.

Should I test this only in GA4 reports?

No. Start in the browser first, then confirm the reporting impact in GA4. Otherwise you may confuse modeled-data shifts with broken implementation.

What is the fastest way to prevent this from happening again?

Create a repeatable QA step for banner changes, region logic, and container releases so consent behavior is validated before it reaches production users.

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.

These findings come from auditing thousands of GA4 properties. See how your property compares

GA4 Audits Team

GA4 Audits Team

Analytics Engineering

Specialising in GA4 architecture, consent mode implementation, and multi-layer audit frameworks.

Share