--- title: "How we classify trackers" url: "https://consenttheater.org/methodology" description: "How ConsentTheater classifies cookies and domains by category and consent burden under GDPR, what each label means, and where the data comes from." --- Methodology # How we classify trackers Last updated 2026-04-25 Every entry in our catalogue carries a **category** and a **consent burden**. This page explains what each label means, how we assign them, and how to challenge a tag if you think it's wrong. We do not assign verdicts to whole websites — that work belongs to supervisory authorities and courts. ## Consent burden Consent burden is our short answer to the question: _how much explicit consent does this tracker need under EU/GDPR rules before it may be loaded?_ It describes the **tracker**, not whether any specific site is compliant. Two trackers with the same burden can land a site in very different places depending on context, legal basis, and how consent is collected. Strict consent Cross-site profiling, ad-tech retargeting, fingerprinting, full-session recording. These build a durable identity for the visitor across properties. They **always** need prior, informed, freely-given consent — there is no realistic legitimate-interest argument for them under [GDPR Art. 6](/law/gdpr/art-6/) or the [ePrivacy Directive Art. 5(3)](/law/eprivacy/art-5/). Consent required Standard analytics, marketing automation, social-login SDKs, CRM enrichment. The personal-data footprint is smaller than strict-consent trackers, but under nearly all current EU readings these still need **opt-in consent** before being loaded. Contested Privacy-aware or aggregate analytics, A/B testing without cross-site linkage, and tracking-adjacent functional cookies. Some authorities — France's CNIL, certain [DSK orientation papers](https://www.datenschutzkonferenz-online.de/orientierungshilfen.html), and the [UK ICO](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/) — accept these under legitimate interest in narrow conditions; others treat them as consent-required. **Default to consent-required** unless you have a documented legal-basis analysis. Minimal Functional and convenience — theme preference, language, CSRF tokens, shopping-cart state, anti-fraud session tokens. Strictly necessary for the service the user explicitly asked for. **Usually exempt from consent** under the [ePrivacy Directive Art. 5(3)](/law/eprivacy/art-5/) "strictly necessary" carve-out, provided the scope stays genuinely functional. ## Categories Category describes _what the tracker does_. It correlates with consent burden but doesn't determine it: an analytics tracker can land anywhere from Contested to Strict consent depending on whether identifiers cross sites and sessions. `advertising` Ad-serving, ad personalisation, ad-click attribution, retargeting. Almost always strict-consent. `analytics` Page-view and event measurement. Burden depends on whether identifiers cross sites and sessions. `marketing` Email tracking, CRM enrichment, lead capture, sales intelligence. Personal-data heavy. `social` Embedded share buttons, social logins, comment widgets. Frequently load third-party profile cookies even before interaction. `session_recording` Records keystrokes, clicks, scroll behaviour, or full pixel-level session replay. Inherently strict-consent. `fingerprinting` Canvas, WebGL, audio-context, font-enumeration, device-sensor fingerprinting — techniques that identify a browser without cookies. `data_leak` Transmits data (often email, phone, form-field values) to a third party in ways the user hasn't authorised. Frequently unintentional on the site operator's part. `tag_manager` Injects other scripts at runtime. Burden depends entirely on what ends up being loaded inside the container. `consent` Consent-management platforms (CMPs) themselves. Reported so operators can verify their CMP is configured correctly. `security` Bot detection, fraud prevention, CAPTCHA. Often necessary, but can carry significant personal-data fingerprinting as a side effect. `functional` Language preference, UI state, shopping-cart session — things the site needs to work. ## How tags are assigned Each entry is reviewed against three questions: 1. What does the vendor's own documentation say the tool is for? 2. What does the tool actually do on the wire — cookies set, domains called, identifiers persisted? 3. How does that map onto the GDPR consent requirement ([Art. 6](/law/gdpr/art-6/) lawfulness, [Art. 7](/law/gdpr/art-7/) conditions for consent) and the [ePrivacy Directive Art. 5(3)](/law/eprivacy/art-5/) "strictly necessary" test? Tags are conservative: **when in doubt, treat as consent-required**. A borderline contested/required entry will be marked Consent required until vendor evidence shifts it. ## Where the data lives The full catalogue — every entry, its category, its consent burden, its description and documentation link — is maintained as an open-source package called the _Playbill_. It is distributed on npm as [@consenttheater/playbill](https://www.npmjs.com/package/@consenttheater/playbill), and its source lives at [github.com/ConsentTheater/playbill](https://github.com/ConsentTheater/playbill). Every classification is traceable to a specific commit. If you disagree with a tag, you can open an issue or a pull request against that repository — include the vendor documentation or wire evidence that supports the correction, and we'll review. ## Primary sources Inline references on this page link to [our own plain-language renderings](/law/) of the relevant articles, each of which carries the verbatim official text alongside and links back to the canonical source on eur-lex.europa.eu. Below is the full list of sources we consult while maintaining the catalogue. * [GDPR — Regulation (EU) 2016/679](https://eur-lex.europa.eu/eli/reg/2016/679/oj) (canonical full text on eur-lex) * [ePrivacy Directive 2002/58/EC](https://eur-lex.europa.eu/eli/dir/2002/58/oj) (canonical full text on eur-lex) * [EDPB Guidelines 05/2020 on consent under GDPR](https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-052020-consent-under-regulation-2016679_en) * [DSK Orientierungshilfen](https://www.datenschutzkonferenz-online.de/orientierungshilfen.html) (German DPA conference orientation papers, DE) * [ICO — UK GDPR guidance and resources](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/) and [ICO — PECR cookies and similar technologies](https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guide-to-pecr/cookies-and-similar-technologies/) (United Kingdom) * CNIL — guidance on cookies and trackers (consult the CNIL website search; specific URLs change between versions of the guidelines) The articles above are the EU versions; the [UK GDPR & PECR mapping](/law/uk-gdpr-and-pecr/) covers how the same provisions apply to UK websites under ICO supervision. ## Caveats * **This is not legal advice.** A GDPR compliance determination for a specific site depends on consent implementation, legal basis, data-subject rights, and the site's specific context. Consult a qualified DPO or lawyer. * **The catalogue is a snapshot.** Vendors change their tools and cookies over time. We re-audit on a rolling basis, but any given entry may lag behind the vendor's current implementation. * **Context changes everything.** A cookie tagged Contested in isolation can effectively become Strict consent if combined with other identifiers or loaded on a sensitive site (healthcare, minors). Use the tag as a starting point, not a final answer. * **Unknown ≠ safe.** A cookie or domain that returns "no match" on this site hasn't been audited by us — it is not a clean bill of health.