A Practical Guide to gdpr sensitive personal data

In practice, gDPR sensitive personal data rules can apply to web tracking when browsing behavior reveals protected characteristics. A cookie ID by itself may look technical. A cookie ID connected to visits about cancer treatment, union organizing, religious services, fertility care, or political campaigns can become much more sensitive.

GDPR calls these "special categories of personal data." Article 9 covers data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic data, biometric data used for identification, health data, and data concerning sex life or sexual orientation (GDPR Article 9).

Why Web Analytics Can Create Sensitive Data

Web analytics often records:

• Page URLs.
• Search terms.
• Referrers.
• Campaign parameters.
• Cookie or device IDs.
• IP-derived location.
• Click and conversion events.
• Account IDs or email hashes in some implementations.

On an ordinary product page, that may be low risk. On a mental health clinic website, a reproductive health resource, a political campaign site, a religious community site, or an employment dispute page, the same data can reveal sensitive information about the visitor.

The risk increases when analytics data is linked across pages, sessions, accounts, or third-party platforms.

The Meta/Bundeskartellamt Warning

The Court of Justice of the European Union addressed special category concerns in the Meta Platforms v Bundeskartellamt judgment. The court found that visiting websites or apps related to special category topics can reveal sensitive data, and that processing such data can fall under Article 9 depending on the circumstances (CJEU case C-252/21).

The practical lesson is not limited to social networks. If tracking systems collect page-level behavior that reveals sensitive interests, organisations need to treat that data with heightened care.

Examples for Analytics Teams

High-risk examples:

• A health clinic sends page URLs about specific conditions to a third-party analytics vendor.
• A nonprofit tracks visitors to domestic violence resources with persistent IDs.
• A political campaign shares event attendance pages with ad platforms.
• A union organizing site retargets visitors based on viewed pages.
• A mental health app records therapy-topic pageviews in a general marketing stack.

Lower-risk examples:

• Aggregate page counts with no persistent identifiers.
• Server-side logs with short retention and IP minimisation.
• Event counts that avoid sensitive page titles or query strings.
• Country-level reporting without user-level histories.

Context matters. The same analytics event can be harmless on a generic blog and sensitive on a healthcare page.

Compliance Implications

Special category processing is generally prohibited unless an Article 9 exception applies, such as explicit consent or another specific legal basis. Ordinary consent for analytics cookies may not be enough if the processing involves sensitive data and third-party profiling.

Teams may also need:

• A data protection impact assessment.
• Stronger access controls.
• Shorter retention.
• Vendor restrictions.
• Explicit consent where appropriate.
• A ban on advertising use.
• Careful privacy disclosures.
• Review of international transfers.

For health-related sites in the United States, HIPAA may also apply if the organisation is a covered entity or business associate. HHS has issued guidance and enforcement attention around online tracking technologies used by HIPAA-regulated entities (HHS online tracking technologies guidance). Important 2024 caveat: HHS notes that a federal court vacated the bulletin to the extent it treated an IP address plus a visit to certain unauthenticated public health pages as automatically triggering HIPAA obligations. That does not remove risk for portals, appointment, intake, payment, authenticated, or PHI-disclosing workflows.

Practical Risk Reduction

Use a sensitive-context analytics checklist:

1. Identify pages that reveal health, religion, politics, sexuality, union status, children, or other sensitive topics.
2. Disable advertising pixels on those pages.
3. Avoid session replay and heatmaps on sensitive flows.
4. Strip query strings before analytics collection.
5. Do not send page titles that include sensitive terms if aggregate categories will do.
6. Avoid persistent identifiers where possible.
7. Keep reports aggregate.
8. Restrict access.
9. Shorten raw-data retention.
10. Review vendors and subprocessors.

Privacy-First Measurement

Privacy-first analytics is especially valuable in sensitive contexts. A clinic, nonprofit, advocacy group, or public service can often answer operational questions without tracking identifiable journeys.

Useful low-risk metrics include:

• Total visits to a resource category.
• Referrer domains in aggregate.
• Device class for usability checks.
• Search terms only when anonymised and reviewed.
• Conversion counts for non-sensitive actions.

If a question cannot be answered without collecting sensitive behavior, ask whether the question is worth the risk. In many cases, a less detailed metric, survey, or server-side operational record is safer and more respectful.

Red Flags in Event Design

Review event names and properties before launch. Events such as depression_quiz_started, union_contact_form_submitted, or pregnancy_help_clicked may be useful internally, but they can expose sensitive meaning if sent to general analytics or advertising tools.

Use neutral categories where possible, restrict access, and keep sensitive analytics out of third-party ad ecosystems. In sensitive contexts, "more granular" is often not better.

Safer Naming Examples

Event naming can reduce risk without making reports useless. Instead of sending pregnancy_options_page_viewed, send resource_category_viewed with a broad category visible only in aggregate. Instead of therapy_for_grief_video_75_percent, send video_progress with a non-sensitive content ID that only a restricted internal table can interpret.

The same principle applies to URLs. Avoid paths and query strings that expose diagnosis, legal status, or personal concerns when a simpler page structure will do. If sensitive words must appear for usability or SEO, configure analytics to strip the path or report at a broader category level. The goal is not to hide the service from users; it is to avoid broadcasting sensitive meaning to general-purpose analytics systems.

Sensitive-Context Review

Before tracking sensitive pages, document the page category, event names, URL behavior, identifiers, vendors, retention, access controls, and whether Article 9 or another sector law could apply. Then test the page in a clean browser profile and inspect network calls, cookies, storage, and server-side events.

If analytics still sends condition names, sensitive search terms, persistent IDs, or advertising calls from sensitive pages, the issue is not wording in the privacy notice. The data design needs to be narrowed.