Why categories and not cookies
Consent has to be informed and specific, but a list of forty cookie names is difficult to turn into a meaningful decision. Grouping technologies by purpose is a common interface pattern: describe each purpose clearly, let the visitor decide per purpose, and keep the underlying cookie-level detail available.
The cookie-level detail still has to exist (that is what a cookie declaration is for), but it belongs in the reference material, not in the decision.
The five that ship
| Category | What belongs in it |
|---|---|
| Necessary | Storage or access that is actually necessary for transmission, security, a requested service, or remembering the privacy choice. The product keeps this category active, so each item needs a purpose-specific necessity test. |
| Functional | Remembered choices, support and convenience tools. |
| Analytics | Measurement of usage, reliability and performance. |
| Marketing | Advertising, remarketing and campaign attribution. |
| Media | Embedded video, maps and third-party players. |
Category is the purpose, not the vendor’s label
The scanner classifies by the observed vendor and the technology’s usual purpose rather than simply repeating a vendor label. Profiling for ad targeting belongs in marketing even if a supplier also calls it analytics; session replay is reported as analytics but still deserves a more detailed data and masking review than a basic page-view counter.
When to add a custom purpose
Custom purposes carry their own stable keys and their own stored decisions, and granting one grants nothing else. They are the right answer when a use genuinely does not fit: a personalisation engine, a research panel, a partner integration a visitor should be able to refuse separately.
They are the wrong answer when the goal is to make a category sound more palatable. Splitting marketing into six friendly-sounding purposes increases the clicks required to refuse, which is the definition of the problem regulators are looking for.
Common questions
Can the necessary category be refused?
Not in this product: the category is reserved for technology genuinely required to provide security, transmission or a service the visitor requested. Do not use the label to turn an optional tool into a non-refusable one. Some laws also recognise other narrow exceptions, such as certain UK statistical uses, and those need their own documented treatment rather than being relabelled as necessary.
What happens to a category after it is removed?
Existing published categories keep working and can be removed; decisions already recorded against them stay readable. Removing a category is a privacy-relevant change, so it produces a new configuration version.
Sources and verification
Verified on . Product-behaviour statements were checked against the current implementation and tests. The links below are the verification basis recorded for this article. They support the stated facts, not a legal conclusion for every site or configuration; recheck changing vendor behaviour before relying on it in production.
- Regulation (EU) 2016/679 (GDPR)
Legislation
Checked
- ICO: guidance on storage and access technologies
Regulator guidance
Checked
- StrongPrivacy documentation
Product documentation
Checked
See what your own site is loading
A browser scan reports the requests and storage it observed during the sampled journey. Use configured workspace scans to compare the states and pages that matter to your implementation.