Sensitive Data in Analytics and Marketing Tools: What You Must Not Collect

The short rule

Do not send health, sexual orientation, precise government IDs, biometric templates, or similar high-harm attributes into analytics and advertising tools unless you have a clear legal condition and the vendor’s own policies allow it. For most websites, the safe default is: never collect those fields in tags, pixels, CDP traits, Customer Match uploads, or session-replay pipelines.

This article maps GDPR Article 9 and ICO inference guidance, CCPA sensitive personal information limits, DPDP high-harm practice, and public Google Ads customer-data policies. Pair with GDPR special category data, CCPA SPI, minimisation, and classification.

What counts as “must not collect” in marketing stacks

GDPR special category data

Article 9 covers personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic data, biometric data for unique identification, health data, and data concerning sex life or sexual orientation. Processing is prohibited unless an Article 9(2) condition applies, plus an Article 6 basis.

The ICO is clear that inferred data can be special category data if you intend to infer a listed attribute or treat people differently based on that inference (for example targeting ads from browsing on medical sites). Profiling that assigns health, ethnicity, politics, religion, or orientation interest labels needs an Article 9 condition. IAB UK guidance on special category data in digital advertising notes that for RTB and much online advertising, explicit consent is typically the only realistic Article 9 condition, and that controllers generally should not process special category data for those purposes.

CCPA sensitive personal information

Civil Code section 1798.140 SPI includes government IDs, account credentials with access codes, precise geolocation, certain demographic and belief data, message contents (when you are not the recipient), genetic and neural data, biometrics for unique ID, and health / sex life / sexual orientation data. Using SPI for advertising profiles usually triggers the right to limit under section 1798.121 and homepage link duties under section 1798.135. Minimisation under section 1798.100 still applies. Do not feed SPI into ad audiences “because the pixel makes it easy.”

DPDP practice note

DPDP has no GDPR-style sensitive tier, but notice, consent or legitimate use, purpose limitation, and Rule 6 security still apply to all personal data. Sending diagnosis text or Aadhaar numbers into a global ad pixel creates unnecessary breach and rights risk. Keep high-harm fields out of marketing tools.

Platform policy layer (Google Ads examples)

Google’s public Ads policies on customer data and Customer Match restrict uploads and measurement tied to sensitive categories, including health or medical information (such as medical service or prescription purchases), sexual behaviour or orientation, racial or ethnic information, political affiliation, religion, trade union membership, and related sensitive interests. Customer Match and advertiser-curated audiences also face limits when promoting sensitive categories. Platform policy is not a substitute for GDPR or CCPA, but it will block or penalise many sensitive uploads even when your marketing team asks for them.

Where sensitive data sneaks into analytics and ads

• Form field scrapers and enhanced conversions: hashed emails are one thing; including “condition,” “prescription,” or “orientation” custom fields is another.
• URL and page-path capture: /cancer-treatment/... or /hiv-support/... paths sent as pageview parameters can reveal health.
• Event names and properties: completed_fertility_quiz, selected_religion=..., disability_type=....
• Session replay and heatmaps: keystroke capture on password, card, or health forms.
• Customer Match / audience uploads: CRM segments built from clinic patients or LGBTQ+ buyers.
• Server-side GTM: forwarding webhook payloads that still contain SPI columns.
• Support and chat widgets with marketing overlays: ticket text mirrored into analytics.

What you must not collect (practical deny list)

• Diagnoses, symptoms, medications, appointment types that reveal health status.
• Sexual orientation, sex-life, or fertility / dating-intent labels used for targeting.
• Religion, political opinion, trade union, or ethnicity traits used for ads or lookalikes.
• Government ID numbers, full payment credentials with security codes, biometric templates.
• Precise geolocation streams used to infer clinic or place-of-worship visits for targeting.
• Children’s data into ad personalisation pipelines.
• Free-text answers from accessibility or medical questionnaires into CDP traits.

Ordinary purchase category (“bought running shoes”) is not the same as health status. When the product itself is medical, get counsel before any remarketing design.

What you can usually keep (with ordinary PI rules)

• Coarse product interest that is not a special category or SPI inference.
• Standard ecommerce events (view item, add to cart, purchase) without sensitive custom dimensions.
• Consent-gated analytics measurement that does not encode Article 9 or SPI attributes.
• Contextual advertising based on page content without building a health profile of the visitor (still check PECR/ePrivacy cookie consent for ad tech).

Engineering controls

1. Tag inventory

• List every pixel, SDK, and server-side destination.
• Mark which ones may never receive SPI / special category keys.
• Block those keys in GTM / sGTM with allowlists, not trust-based deny lists alone.

2. Form and URL hygiene

• Exclude sensitive form CSS selectors from replay tools.
• Rewrite or drop pathnames that encode medical or orientation topics before they hit GA4/ads.
• Never put government IDs in query strings.

3. Audience building

• Ban CRM filters that equal “patient,” “HIV,” “mosque,” “party_donor,” etc., from export jobs.
• Review lookalike seed lists for sensitive proxies.
• For CCPA, keep SPI out of sale/share and honour limit-the-use signals.

4. Consent and contracts

• Ad storage and access technologies need PECR/ePrivacy-style consent where those rules apply.
• Article 9 explicit consent, if ever used for marketing, must be separate, recorded, and withdrawable; most teams should avoid this path.
• Processor terms must forbid secondary use of any accidental sensitive fields.

5. Detection

• Scan event schemas weekly for new properties (reuse discovery/classification ideas).
• Alert when payloads match health/ID regexes bound for marketing endpoints.
• Include marketing tools in breach tabletop exercises (security controls; breach response playbook).

Checklist before a campaign launch

1. Does any seed list, pixel parameter, or landing path reveal Article 9 or CCPA SPI attributes?
2. If yes, stop and redesign with contextual or non-sensitive first-party signals only.
3. Confirm CMP blocks ad tags until consent (where required).
4. Confirm Google / Meta / other platform sensitive-category policies for the ad type.
5. Document the decision in the ROPA or purpose register.

Sources

• Regulation (EU) 2016/679, Article 9; ICO guidance on what special category data is (including inferences) and rules for processing it.
• ICO direct marketing / online advertising guidance on special category data and storage and access technologies (PECR).
• IAB UK Special Category Data Guidance (digital advertising / RTB context).
• California Civil Code sections 1798.140, 1798.100, 1798.121, 1798.135.
• Google Ads Help: Customer data policies; Customer Match policy; Health in personalized advertising / restricted targeting materials (public Ads policy pages).
• Digital Personal Data Protection Act, 2023 (purpose, notice, security) for India-facing sites.

Disclaimer

This article was prepared by Imran using publicly available information. It is for general education only and is not legal advice. Do not rely on it alone when implementing cookie compliance, DSAR handling, consent flows, sensitive-data controls, breach response, or other privacy and data-protection measures. Consult your own legal counsel for advice that fits your business, jurisdictions, and systems.

Last updated on 29 September 2026