What are GA4's GDPR data subject rights obligations?
Under GDPR and UK GDPR, data subjects have the right to access their personal data, request its deletion, and in some cases request portability. As the data controller, you are responsible for fulfilling these rights for data collected via GA4. GA4 provides two tools: the Data Deletion Request (for erasure requests) and User Explorer (for access requests, limited).
Neither tool fully covers all GDPR obligations for analytics data — particularly for access requests, which require identifying and providing all data held about a specific individual, a task that's difficult with GA4's pseudonymous identifier system. Most robust DSAR processes for analytics data combine GA4 tools with BigQuery direct queries.
GA4 data deletion requests: what they do and don't delete
What a GA4 deletion request deletes
Admin → Data Deletion Requests → Create request → specify:
- Delete by user property: Delete all events from users with a specific user property value (e.g., User-ID = internal_12345)
- Delete by event parameter value: Delete events where a specific parameter matches a value
- Delete all events for all users: Nuclear option — wipes all event data for the specified date range
Timeline: GA4 processes deletion requests within 63 days. The data is removed from standard reports and the BigQuery export after processing.
What a GA4 deletion request does NOT delete
- Data already exported to BigQuery before the deletion was processed — you must also delete matching rows from BigQuery separately
- Data in Looker Studio report caches — caches refresh automatically but there may be a temporary window
- Backups in Google's infrastructure beyond the 63-day processing window
- Data shared via Google Analytics Audiences to Google Ads (separately managed in Google Ads)
Important: If you have a BigQuery export of GA4 data, every DSAR deletion also requires a corresponding BigQuery DELETE query. The GA4 deletion tool does not retroactively modify previously exported data.
The BigQuery deletion query
Need to validate whether consent timing is distorting your GA4 data?
Challenge: Wildcard table deletion (events_*) requires identifying all date-partitioned tables containing the user's data. For large historical datasets, this may span hundreds of tables. Build a scheduled query or Python script that handles the multi-table deletion automatically.
Handling an access request (right of access)
A DSAR access request requires you to provide the data subject with a copy of all personal data held about them. For GA4:
Step 1 — Identify the user in GA4 If you have User-ID implemented: User Explorer in GA4 Explorations → search by User-ID → view event history. This shows the user's event stream within the GA4 retention window.
If no User-ID: User Explorer requires the GA4 pseudonymous client ID (from the _ga cookie), which you may not be able to link to a specific individual without other identifying data.
Step 2 — Extract data for the access request For a comprehensive access response, query BigQuery:
Export to CSV and include in the DSAR response.
Step 3 — Consider what GA4 data constitutes personal data This is a legal question, not purely technical. GA4's user_pseudo_id is a pseudonymous identifier — it's personal data if you can link it to an individual (which you can if you have User-ID). If you can't link the pseudonymous ID to an individual, it may not constitute personal data for DSAR purposes. Consult your DPO.
The 30-day DSAR response workflow for analytics
| Day | Action |
|---|---|
| Day 1 | DSAR received → log in your DSAR tracker → identify if analytics data is in scope |
| Days 2–5 | Identify the user in GA4 (User Explorer / BigQuery query by User-ID) |
| Days 5–10 | Extract relevant data for access requests; initiate deletion request in GA4 Admin for erasure requests |
| Days 10–15 | BigQuery deletion query executed (for erasure requests); data extracted and reviewed |
| Days 15–20 | Legal review of data to be provided or confirmation of deletion |
| Day 25 | Response sent to data subject |
| Day 30 | GDPR deadline — must respond by this date |
DSAR log entry for analytics-related requests:
- Date received
- Type (access / erasure / portability / restriction)
- User identifier used to find GA4 data (User-ID / client_id)
- GA4 data found and provided or deleted
- BigQuery deletion query executed (Y/N)
- GA4 deletion request reference number
- Date response sent
FAQ: GA4 User Deletion and Data Portability: Handling DSARs Correctly
Can ga4 user deletion and data portability: handling dsars correctly 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 Correctly
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 Correctly 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.