GA4 and Health Data: Which Parameters to Avoid Sending Under DPDP and Google's Policies

A GA4 property is a database that someone outside your organisation helps to run. Whatever your tags send to it is processed on Google's infrastructure, under Google's terms, and cannot be recalled by editing a page. On an ordinary retail site that is an accepted trade. On a hospital or clinic site, the same pipeline can carry fragments of health information without anyone intending it: an appointment confirmation URL with a token, a page title with a condition name, a site-search term typed by a worried visitor.

This article is for marketing teams, analysts and developers who run analytics for Indian healthcare providers. It gives a field-by-field view of what is safe, what is risky and what must never be sent, then the technical methods for scrubbing it. It is a working checklist, not legal advice; your counsel and data protection lead own the final call on what your organisation may collect.

The three rule sets that apply

Google's Analytics requirements. Google's guidance on PII says that no data may be passed to Google that Google could use or recognise as personally identifiable information. It says both the URL path and the parameters must be free of PII, and that if your URLs, URL parameters or titles might contain PII you need to remove it. It names user-entered text in search boxes and forms, user ID overrides, custom dimensions, campaign parameters, site search terms and event dimensions as areas of risk. Separately, Google's HIPAA statement for Analytics says Google makes no representations that Analytics satisfies HIPAA and does not offer Business Associate Agreements for it. That is a US law, but it signals how Google treats the product: it is not a health-data processor, and you should not use it as one.

Google Ads personalisation rules. Health is a sensitive interest category in Google's personalised advertising policy. Advertisers promoting in these categories cannot use advertiser-curated audiences, which includes Customer Match and your own data segments. If GA4 audiences built from health-related behaviour feed Google Ads, you are building something the policy does not allow you to use.

India's DPDP Act. The Digital Personal Data Protection Act, 2023 applies to digital personal data, and the Rules were notified in November 2025 with an eighteen-month period for phased compliance. Health information about an identifiable person is personal data, and the obligations on notice, purpose and safeguards apply to what you collect through tags. Our DPDP Act for healthcare marketing article covers the Act itself; this one is about the data layer.

The practical conclusion is the same under all three: send the minimum, make sure nothing can identify a person, and do not let page content or user input describe a patient's condition.

What is safe, risky and never allowed

Some of these deserve explanation.

URLs and query strings

Healthcare sites create personal URLs without noticing. A confirmation page at /appointment/confirmed?name=Asha&phone=98…, a report page at /reports/view?id=…, a payment link, a "thank you" page that echoes the specialty. Treat any URL a logged-in or just-booked visitor can reach as suspect. The safe pattern is a fixed path such as /appointment/confirmed with details held in server session state, not in the address bar.

Page titles

GA4 reads the document title for page_title. If your CMS puts the visitor's name or the condition into the title on a results or confirmation page, that string goes into your reports. Titles on content pages that describe a condition ("Piles treatment in Gurugram") are public content and fine to record. Titles on transactional or personalised pages are not.

Site search

Internal search boxes are the most common leak. Visitors type what worries them. Google lists site search terms as an area of risk, and nothing stops a visitor typing a name or a report number. Decide whether you need the term at all. If you do, send only a bucketed category (for example search_category=doctor_name or search_category=service), classified on your side, and never the raw string.

Form fields and IDs

Do not read form values in Tag Manager variables. Send the event that the step happened, not what was entered. For identifiers, never set a hospital's patient or visit number as user_id. A random identifier created in the browser has no meaning outside your site.

Redaction methods, from weakest to strongest

1. GA4 data redaction. Admin settings can remove email-like strings and query parameters you list from web streams. Google describes this as best-effort for email addresses. It is a safety net, not a design.
2. Sanitise in the data layer. Before the Google tag runs, a custom JavaScript variable in Tag Manager rewrites page_location and page_referrer to drop query strings except an allow-list (utm_source, utm_medium, utm_campaign, utm_content, gclid), and rewrites page_title on transactional pages to a template. Allow-lists are safer than block-lists because a new parameter never leaks by default.
3. Fix the source. Remove personal data from URLs and titles at the application level. This is the only method that also helps other tools on the page.
4. Server-side filtering. If you use a server container, transformations can allow only named parameters, or exclude specific ones, before any tag sees the event. Our article on server-side tagging and consent mode covers the setup. It does not replace the earlier steps, because the original page still sends data to any other script that is loaded in the browser.
5. Do not collect. For the most sensitive flows (patient portal, results, telemedicine rooms), load no analytics tags at all.

Auditing what you already sent

Do this before changing anything, so you know the scale.

• In an Exploration, list page_location with event count for the last 28 days, and sort by distinct values. Pages that appear once each are usually personalised URLs.
• Search the list for @, long digit strings, and parameter names such as name, phone, email, mrn, uhid, token.
• Do the same for page_title, the site-search term dimension, link_text, link_url, file_name and any custom dimension you registered.
• Check whether user_id is set and from which system.
• Review Google Ads audiences linked to GA4 and remove any built on sensitive behaviour.

If you find personal data, fix the source first, then consult your counsel and data protection lead on what to do about records already collected, including whether GA4 data deletion or a property reset is appropriate. Write down the finding, the date and the fix; a record of how you handled it is part of showing safeguards.

Preventing regressions

Leaks come back with new pages. Put three controls in place.

• A tracking plan that lists every parameter and its allowed values. If it is not on the list, it is not sent.
• A release check: a developer tests every new template in Tag Manager preview and looks at page_location and page_title on the live page, including the confirmation state.
• A monthly audit that repeats the exploration above and compares with the last one. New distinct values deserve a look.

Where to start

1. Run the audit on the last 28 days of page_location, page_title and site-search terms.
2. Disable site-search term collection or bucket it.
3. Replace any query-string-based confirmation page with a fixed path.
4. Add the allow-list sanitiser variable and test it.
5. Confirm user_id is either not set or is a random identifier.
6. Review GA4-linked Google Ads audiences against the personalised advertising policy.
7. Write the tracking plan and put the release check in your deployment process.

For related reading, see healthcare remarketing strategies and compliance, healthcare marketing compliance across HIPAA, DPDP and ad rules, and the GA4 glossary entry. If you want help implementing the data layer, see our analytics and tracking service.