If a GA4 report contains a customer’s email address, name or enquiry details, start by finding how that information reached Analytics. Hiding the report column will not repair the collection route.
For a UK business, the practical job has three parts: stop the unwanted data being sent, prove the customer journey still works, then deal with information already collected. Keep your website developer and the person responsible for analytics involved in the same repair.
First, contain the affected tracking route
Google’s guidance on avoiding personally identifiable information identifies URLs, page titles and user-entered information as potential collection routes. It also warns against putting identifying details into campaign parameters or custom dimensions.
Record the affected property, page, event and parameter name. Note when the problem was discovered and any recent form, plugin or tracking changes. Keep examples within your restricted investigation process; use masked evidence in ordinary project tickets.
If collection is continuing, ask your developer to pause the offending analytics tag or remove its unsafe parameter while they investigate. Where the source is unclear, agree temporary containment with the analytics owner. Record the resulting measurement gap so it is not mistaken for a sudden fall in enquiries.
Keep the enquiry form and its delivery to your inbox or CRM working. The customer should still be able to contact you while measurement is repaired.
Find the exact field carrying the information
Do not assume that a form submission event contains every answer entered into the form. Google’s enhanced measurement reference lists form identifiers, names, destinations and submit-button text. It also documents page URLs, outbound-link URLs and search terms collected by other measurement options.
Use those documented fields as starting points, then inspect your own implementation:
| Where the detail appears | What to investigate |
|---|---|
| Page address or title | A personalised confirmation page, account page or redirect that includes customer details. |
| Search term | A visitor entering an email address or other identifying detail into your website search. |
| Link URL or form destination | A personalised link or submission address carrying information in its query string. |
| Custom event parameter or user property | A tag, plugin or integration mapping a form answer into analytics. |
For example, a hypothetical confirmation address such as /thank-you/?email=sample%40example.com should prompt a review of the URL construction and tracking. Use synthetic examples when reproducing the fault.
Repair what the website sends
Keep customer details out of measurement fields
Ask for a field-by-field review of the affected tag. For an enquiry-completion event, define the information the business actually needs: perhaps the form type and service selected. Keep the customer’s message and contact details in the system used to respond to them.
Give the developer a short list of approved analytics fields. Request removal of mappings that copy whole form objects, unrestricted text or personalised page titles. This is more useful than asking them to make the tracking “privacy friendly” without defining the expected output.
If a thank-you page contains customer details in its address, review why they are there. Prefer a confirmation journey that does not need them in the URL. Check the whole route, including redirects and subsequent navigation, rather than cleaning only the final page-view event.
Check integrations as well as browser tags
List every sender involved: the website plugin, Google Tag Manager container, custom code and any backend or CRM integration. Ask which component creates each affected field. Fixing one tag is incomplete if another integration sends the same information.
Keep the repair specific. Removing every event or campaign parameter can leave the business unable to judge its marketing without establishing what caused the problem.
Use GA4 redaction as an additional safeguard
Google’s current data-redaction documentation describes a client-side safeguard for web streams. Email detection works on a best-effort basis, and you can specify URL query parameters whose values should be redacted. It does not cover Measurement Protocol or Data Import, and it does not inspect HTTP headers.
An Editor or above can open Admin → Data collection and modification → Data streams, select the web stream and choose Redact data in the Events section. Review email redaction and add the relevant query-parameter names, such as email_address or firstname. Use the built-in preview with synthetic values.
Treat this as protection against accidental collection. It is not a general detector for names, phone numbers or enquiry text, and switching it on does not clean up historical records.
Keep the configured parameter list with the tracking specification. Review it when developers introduce new forms or personalised journeys, rather than assuming a setting made once covers every future change.
Distinguish supported user-provided data from an accidental leak
There is a separate, supported user-provided data collection feature. Google’s documentation describes consented first-party data, specific configuration and SHA256 hashing. That is different from an email address appearing openly in a page URL or custom reporting field.
If your agency says a customer-data field is intentional, ask them to identify the feature, destination and implementation method. Do not accept “enhanced conversions” as an explanation for an unrelated parameter. Equally, avoid dismantling a deliberately configured integration before establishing which route is responsible.
Test the repair through a real customer journey
Use a controlled test enquiry with synthetic details. Repeat the affected journey on mobile and desktop, including any confirmation page and the next page visited. Keep the site’s intended consent behaviour in place.
Google’s DebugView guide explains how to enable debugging for your own device and inspect individual events and their parameters. It also notes that privacy controls or a lack of analytics consent can prevent events appearing. An empty DebugView alone does not prove that an unsafe field has been removed.
Ask your developer to check the outgoing analytics requests as well as the received test events. For backend senders, request a separate payload check; a browser-only test will not examine that integration.
- Confirm that the synthetic contact details are absent from ordinary analytics fields and URLs.
- Confirm that the intended enquiry event still arrives with its approved parameters.
- Confirm that the actual enquiry reaches the correct inbox or CRM.
- Repeat after the production deployment, using the deployed tracking configuration.
Plan historical deletion around the affected field
Google’s data-deletion guidance explains that requests remove text from supported parameters; they do not simply erase whole events from every metric. Automatically collected parameters require the broad “Delete all parameters on all events” option, and some fields, including link_url and search_term, are excluded. Do not assume a narrowly targeted deletion is available for every discovery.
An Editor should check the exact field, supported deletion type and date range before scheduling. Google provides a seven-day cancellation window. Processing can take 7–63 days, and data must be more than 12 days old to be deleted. Completed deletion is irreversible; it can also affect attribution and conversion reporting.
Have the analytics owner review the scope and preview. If the affected field is unsupported, involve Google support rather than assuming a broader request will solve it. Separately review any exports, shared reports or downstream stores that received the information.
Leave a clear tracking specification behind
The useful handover is a record of the source, containment, deployed repair, test evidence and any outstanding historical cleanup. Assign an owner and a follow-up date for deletion requests that remain in progress.
Then document what each enquiry event should contain. Our guide to connecting enquiries with sales in conversion reporting can help define the commercial outcomes worth measuring.
If your reporting is receiving customer details, BuzzBoost can help review the website and tracking together. Explore our analytics and reporting services, or contact us with the affected journey and the field you have found, using masked examples.
Featured image: AI-generated editorial artwork, not a photograph of a real BuzzBoost office, client or result.
