How to Configure GA4 Data Redaction

Inventory page locations, referrers, form destinations, link URLs, video URLs, custom event parameters, ecommerce fields, and server-side events. Search for query keys such as email, name, phone, address, order lookup, reset token, and account identifiers. Use synthetic examples, not copied customer URLs. A privacy review should identify both the field name and the code or platform that puts the value into the browser or analytics payload.

Google advises against sending personally identifiable information to Analytics. The preferred control is to stop generating or collecting it upstream. Replace sensitive URL parameters with non-personal opaque state, remove unnecessary form values, and constrain tag variables. Data redaction helps catch defined patterns after client-side event processing, but it should not become the only barrier between customer identity and analytics collection.

Open the relevant web data stream and configure Redact data. Google permits email-address redaction and a list of URL query parameter names. Build the parameter list from the inventory rather than guessing common keys. Normalize case and platform variants, then assign an owner for additions and removals. Review every production stream because a setting on one property or stream does not automatically protect another.

Google states that new properties have email redaction enabled by default, while older properties may require it to be turned on. Verify the live setting instead of relying on property age. Record the property, stream, option values, query keys, editor, approval, and effective time. Do not include a real email address or secret token in the change ticket or screenshot.

Use the built-in preview with synthetic email-like text and each governed query parameter. Test percent-encoded values, Unicode keys when relevant, repeated keys, empty values, mixed case, and a URL with required campaign parameters. Google notes that percent-encoded parameters can be interpreted and that email pattern matching can also redact innocent text that resembles an address. Review both privacy protection and measurement damage.

Then run a safe browser test through the actual site and inspect DebugView and collection requests. Confirm sensitive values are absent and permitted campaign, product, and page fields remain usable. Keep a before-and-after sample with synthetic values only. A passing preview does not prove that Measurement Protocol, server tagging, imported data, or a different stream is protected, so test each collection path separately.

Google says data redaction is available for web streams, runs client side, and does not evaluate HTTP header values. It also does not prevent personal information arriving through Measurement Protocol or Data Import. Map those uncovered paths to their own validation and minimization controls. A clean browser page_view cannot certify a server event, app stream, offline upload, or raw proxy log.

Review tagging templates, server endpoints, data-layer pushes, form analytics, URL builders, redirects, and exports. Add schema allowlists and reject unexpected identity fields before transmission. Keep analytics identifiers distinct from customer contact records. If the business needs a join for an approved use case, perform it in the authorized environment with access, retention, and deletion controls rather than putting customer identity into Analytics event parameters.

Create regression tests for sensitive query keys and known form paths, and rerun them after checkout, account, campaign, and tag changes. Monitor newly observed parameter names without storing their sensitive values. Review redaction settings and upstream fixes on a fixed cadence. If a new leak is detected, stop the affected collection when safe, preserve minimal evidence, correct the source, and follow the approved incident and deletion process.

Track streams reviewed, paths tested, sensitive keys governed, defects removed upstream, and unresolved collection paths. Do not publish counts that contain personal values or infer legal compliance from a technical toggle. Data redaction is one verifiable control inside a broader privacy program. Its success condition is reduced accidental transmission with clear coverage limits, not a promise that every possible identifier has been detected.

Maintain a privacy-focused analytics contract that lists allowed event names and parameters for each journey. Reject or strip fields outside that contract before they enter the tag or server endpoint. Pair automated checks with periodic manual review because new forms, search features, support widgets, and campaign links can introduce query keys without changing the core analytics code. When a test finds a leak, preserve only the minimum synthetic reproduction and deployment version. Do not repeat the real value across logs, screenshots, or issue trackers while investigating. After the upstream fix and stream redaction are live, verify a clean collection request, DebugView event, page-location value, and relevant downstream report. Record which paths remain outside the feature's coverage. This turns redaction from a one-time settings exercise into an operating control that can be tested, explained, and corrected. Require privacy review for new URL parameters and form integrations, and add the approved query-key inventory to release checks so known sensitive names fail before a new production page begins collecting traffic.