How it works
Discover, consent, control, prove.
Four verbs in the order they have to happen. A cookie banner is the second one; the other three are where consent either works or quietly does not.
Discover
Inventory the cookies, storage, scripts, trackers and third-party services a page actually loads — including the ones added by a plugin, a campaign or a tag manager.
Consent
Present the choices your configured policy requires for that visitor's region, in your brand, in their language, operable by keyboard and screen reader.
Control
Hold, gate or release each service according to the current state — the part a banner on its own does not do.
Prove
Keep the banner, policy, inventory and receipt versions needed to reconstruct a decision long after the site has changed.
Path one
Add DotCensus to a website that already exists.
The ordinary case: a site with history, tools nobody fully remembers adding, and no appetite for a rebuild.
Add your website
Create the site and run the first scan. You get an inventory before you configure anything.
Review what was found
Confirm categories and vendors, and deal with anything that came back unknown.
Choose the experience
Regional policy behaviour, banner styling, languages and which integrations are in play.
Install DotCensus
Runtime script, tag manager, CMS integration or framework SDK — whichever your site already uses.
Verify
Privacy Health runs the site in fresh, refused and accepted states and reports what actually happened.
Stay current
Scheduled scans surface new trackers and drift, and update the inventory the disclosure is generated from.
The step people skip
Verification is not optional, it is the product.
Configuration tells you what should happen. A scan in three states tells you what does. The gap between those two is where every unpleasant discovery lives — and it widens quietly, because nothing on the site announces a new tag.
So DotCensus treats the refusal path as a first-class test rather than something you hope somebody checks before an audit.
| Service | Before choice | Rejected | Accepted |
|---|---|---|---|
| Site sessionNecessary | Fires | Fires | Fires |
| Google AnalyticsAnalytics | Held | Held | Fires |
| Meta PixelMarketing | Held | Held | Fires |
| YouTube embedMarketing | Held | Held | Fires |
| Unknown scriptNeeds review | Fires | Fires | Fires |
The last two rows are the interesting ones: an embed that is gated rather than blocked, and a script nobody has classified — which fires in every state precisely because no rule covers it.
Privacy by construction.
A standalone CMP has to discover a website after it exists. A platform that generates the site knows what it inserted — every analytics tool, every embed, every marketing integration — and can compile consent with the site instead of retrofitting it.
When someone tells an AI builder “add Google Analytics and a Meta Pixel”, the right outcome is not two script tags. It is two registered services, mapped purposes, an updated manifest, updated disclosure text and a verification scan after publish.
- 1Components declare their impactAnalytics, forms, embeds and marketing integrations carry vendor, purposes, storage and load mode as metadata.
- 2A manifest is generatedThe build compiles those declarations into a Consent Manifest — the site knows its services before it is published.
- 3Loading is gatedComponents initialize only when the Consent Core permits them. Nothing to intercept.
- 4The published site is scanned anywayCustom code and external tags never went through the builder, so verification still runs.
{
"service": "google-analytics",
"vendor": "Google",
"category": "analytics",
"execution": "after-consent",
"storage": ["cookies"],
"signals": ["analytics_storage"]
}One entry per service: who it belongs to, what it is for, when it may execute, what it stores and which signals it maps to. Illustrative — the public schema is published when the API is stable, not before.
What both paths produce
One manifest, whichever way you arrived.
Scanned and confirmed, or declared by components at build time — either way the result is the same structure: the services, their purposes, their execution rules and their signal mappings, versioned so the evidence stays readable.
That is what makes the two integration paths one product rather than two.
Know what runs before you ask visitors to trust it.
Start with a scan of what your website loads today. The list is usually longer than the team expects, and that is the useful part.
No code to install for a scan Public pages only DotCensus runs on DotCensus