How to Manage GA4 Data-Deletion Requests

A GA4 property data-deletion request removes collected text from selected event parameters over a defined period, while events can remain counted in aggregate metrics. Google also provides a User Explorer path for deleting data associated with a selected user identity. These controls solve different problems. Do not choose the broader or faster-looking option before identifying what data entered Analytics and whose request or incident requires action.

Write the property, streams, date range, event names, parameter names, identifier type, affected collection path, and approval basis. Determine whether the issue involves accidental text collection, a specific user's data, or both. Include BigQuery exports, advertising links, backups, CRM, and other systems in the wider response plan where applicable. A GA4 action is not proof that every copy in the organization's data estate was removed.

Google says a data-deletion request can erase text collected by event parameters and replace it with a deleted marker while retaining the event in overall metrics. Review the available deletion types and preview the exact scope before submission. Deleting all parameters can also remove the event name because the event name is treated as a parameter. That consequence can change report interpretation beyond the sensitive field.

Use the narrowest scope that meets the approved requirement. Check date boundaries, time zone, selected streams, event filters, and parameter names against the incident evidence. Have a second authorized reviewer confirm the request. Preserve screenshots or exported settings without the actual personal value. Do not paste the offending data into the request narrative when the parameter name and synthetic example are enough to establish scope.

For an individual deletion, identify whether GA4 activity is associated with a user ID, device or client ID, app instance ID, or a combination. Google notes that Analytics does not create the mapping between a user ID and pseudonymous identifiers for you. The organization must maintain its own approved association if it needs to find all relevant identifiers. Do not infer identity from behavior or shared devices.

User Explorer requires suitable property access, and Google warns that deleting user data is not reversible. Confirm the selected effective user identity and property with a second reviewer before submission. If changing reporting identity is necessary to locate pseudonymous IDs, record and restore the setting under change control. Keep lookup inputs and results restricted because the mapping itself can expose identity and behavioral history.

After submission, record request ID, type, creator, approval, submitted time, effective scope, status, and the date for verification. Google documents that user data stops appearing in User Explorer before permanent removal completes, so an early interface change is not the final evidence. Property deletion requests also have defined preview, cancellation, and processing behavior that should be read in the current interface before the owner closes the case.

Review reports, explorations, audiences, attribution, and linked-product expectations that may change. Keep finance and commerce systems authoritative for orders and revenue. Do not alter settled business records to make Analytics align with a deletion. Where linked systems have their own retention or deletion controls, route them through the approved owner and keep completion evidence separate rather than assuming the GA4 request propagated everywhere.

Trace the original collection path and remove the cause. That can mean eliminating personal values from URLs, constraining event parameters, correcting a tag template, updating server payloads, or stopping an unsupported import. Add a regression test with synthetic values and verify each web, app, Measurement Protocol, and import path in scope. A successful deletion followed by immediate recollection is not a resolved control.

Close the case only when the submitted request, processing status, source fix, regression test, and remaining systems are documented. Report uncertainty when a linked store or export cannot be verified. Review deletion access periodically and remove unnecessary Editors. The operational goal is a precise, authorized, auditable response that minimizes further exposure, not a broad deletion performed quickly without understanding its effect on data or obligations.

Use a deletion register that contains the case identifier, request type, authorized scope, systems contacted, non-sensitive lookup references, approvers, submission timestamps, expected verification dates, observed statuses, source fix, and unresolved dependencies. Restrict access because even the existence and timing of a deletion request can be sensitive. Do not store the personal value that triggered the request when an internal case reference is sufficient. Reconcile the register with GA4 until the documented permanent-removal window has passed and the status can be verified. If the interface or API does not expose final evidence, record that limit rather than claiming completion from an early disappearance. Periodically test the process with synthetic identities in a controlled property so the team can confirm permissions, mappings, approvals, and downstream routing before a real time-sensitive request arrives. Review open cases at a fixed cadence, escalate missed verification dates, and keep a separate list of systems that could not be checked so uncertainty remains visible to the responsible privacy owner.