Back to blog
|6 min read

Handling Data Deletion Requests in GA4

GDPR's right to erasure gives users the ability to request deletion of their personal data. For organisations using GA4, this means having a process to identify the user's GA4 client ID and submit a deletion request through the appropriate channel, a process most organisations have not actually tested.

How GA4's Data Deletion Works

GA4 provides a user deletion flow through Google Analytics that allows property admins to request deletion of data associated with a specific user identifier.

The API accepts three types of identifiers: the GA4 client ID (stored in the _ga cookie), the user ID (if you have implemented user ID tracking), and the app instance ID (for Firebase/mobile implementations).

When a deletion request is submitted, Google processes it within 72 hours in the Individual User Report, then removes the data from Analytics servers during the next deletion process.

However, deletion from aggregated reporting views is not guaranteed, because those reports are based on precomputed data rather than removable per user records.

This is an important limitation: deleting a user's raw events does not retroactively alter the aggregate metrics (sessions, conversions, revenue) that already incorporated those events into pre computed reports.

The Client ID Challenge

The practical challenge with GA4 deletion requests is connecting a deletion request from a user to their GA4 client ID.

Users do not know their own client ID, it is a randomly generated string stored in a cookie they may not even be aware of.

For organisations that implement user ID tracking in GA4 (passing a consistent internal user identifier like an account ID to GA4), deletion is straightforward: you have the user's internal ID, you know which GA4 user ID it maps to, and you can submit the deletion request using that identifier.

For organisations that have not implemented user ID tracking, you need a way to retrieve the client ID associated with the user.

Options include asking the user to provide the value of their _ga cookie (unrealistic), storing the client ID server side when the user authenticates (proactive and recommended), or using your BigQuery export to identify client IDs associated with the user's known actions like purchase transactions (complex but workable).

Building a reliable client ID retrieval process before you receive your first deletion request is strongly recommended.

BigQuery and Data Deletion

If you are exporting GA4 data to BigQuery, data deletion from GA4 does not automatically propagate to your BigQuery tables. The BigQuery export is a copy of the GA4 event data at the time it was exported.

When GA4 deletes a user's events, the corresponding rows in BigQuery are not removed.

This means your BigQuery deletion process must operate independently: when a deletion request is received, you need to identify all rows in BigQuery associated with the user's client ID or user ID and delete them separately.

If BigQuery data is further downstream in a data warehouse or BI tool, those copies also need to be addressed.

Maintaining a documented data lineage map, showing where GA4 data flows after it leaves GA4, is essential for responding to deletion requests comprehensively and avoiding compliance gaps in downstream systems that are easy to overlook.

Ready to audit your GA4 property?

Run a full GA4 audit in under 10 minutes. Free to start.

Start Free Audit