Consent and tracker control for every website
Know what's tracking. Control what runs.
DotCensus discovers the cookies and tracking technologies your site loads, shows the right consent experience, controls which services may run, and records every visitor choice as evidence — from one privacy control layer.
What is your website loading right now?
Enter your domain for a free privacy scan: cookies, third-party trackers, unknown technologies, and anything that runs before a visitor has made a choice.
The gap nobody measures
A banner is only one part of consent.
A website can display a perfectly correct dialogue while analytics, pixels and embeds have already started behind it. The banner records a refusal; the requests go out anyway. Nobody notices, because the only way to notice is to test the refusal — and almost nobody does.
DotCensus connects the visible choice to the technical behaviour underneath it, then keeps checking that the two still agree.
- Site sessionNecessaryAllowed
- Google AnalyticsAnalyticsHeld
- Meta PixelMarketingHeld
- YouTube embedMarketingGated
- Unknown scriptUnclassifiedReview
How it works
Discover, consent, control, prove.
Four verbs, in the order they have to happen. Most cookie tools do the second one.
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.
The platform
Eight modules over one consent engine.
Each one carries its current state — available, beta or planned — because a privacy vendor that overstates its own status has lost the only thing it sells.
Scan & Tracker Intelligence
See the cookies, trackers, storage and services actually running on your site.
Learn moreConsent Experience
Branded, accessible consent and preference experiences that belong on your site.
Learn moreControl & Blocking
Hold, gate or release services according to the visitor's actual choice.
Learn moreSignals & Advertising
Translate one visitor choice into the signals connected platforms understand.
Learn moreConsent Ledger
Versioned evidence of what was shown, what was chosen and what was enforced.
Learn morePolicies & Jurisdictions
Serve different consent models and disclosures from one versioned policy engine.
Learn morePrivacy Health
Continuously test whether the site's real behaviour still matches its configuration.
Learn moreDeveloper & Platform
SDK, API, webhooks, CMS integrations and native website-builder support.
Learn moreDon't just configure consent. Test that it works.
DotCensus visits your site in fresh, refused and accepted states and compares what actually happens with what you configured. A tag added by a campaign three months ago becomes a finding instead of institutional memory.
- Non-essential analytics before consentPass
- Marketing tags after Reject allPass
- Unknown third-party scriptReview
- Preference centre reachablePass
- Google consent state updatesPass
- Policy inventory synchronizedPass
Health reports whether the site behaves the way it is configured. It is not a compliance certification, and nothing in the product labels it as one.
Discover
Find what the team forgot was there.
Modern sites inherit tracking from themes, plugins, tag managers, marketing tools, embeds, old experiments and whoever had access last year. A scan loads the site the way a visitor does and records what each service does in all three states.
The column that matters is the middle one.
| 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.
This video is provided by YouTube and would set cookies on your device.
Allowing marketing content loads it now and remembers the choice. A blank space would have been easier to build and worse to encounter.
Allow and load videoThe choice matters only if the website obeys it.
Known scripts are held until their category is allowed. Embeds that phone home on load — video, maps, chat, scheduling — are replaced with a placeholder that says what loading it will do, and loads it when the visitor agrees.
In a framework or a website builder, the service is simply never emitted until it is permitted. Nothing to intercept is better than intercepting well.
Two ways to use it
One consent engine. Any website — or built into your platform.
The same Consent Core, policy model, ledger and signal adapters serve both. The second one is the interesting one.
Add DotCensus to an existing website
One runtime integration, a scan that discovers the current stack, automatic and explicit blocking, and the CMS, tag-manager and framework paths a real site already uses.
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.
Build privacy in from the start
A website builder knows exactly which analytics, embeds and marketing services it inserted. Let the components declare it, and consent is compiled with the site instead of retrofitted onto it.
- 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.
Every other CMP has to discover a website after it exists. A platform that generates the site has that information up front — and currently throws it away.
Privacy by configuration
Every service gets a purpose, a rule and a signal mapping.
The Consent Manifest is the contract between what the scan found and what the runtime enforces: for each service, its vendor, category, execution mode, storage and the signals it maps to — versioned, so a receipt made under it stays readable.
{
"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.
Communicate
One visitor choice. Every connected signal updated.
Adapters over one internal consent state, so an external standard moving does not mean rebuilding your consent model. Each one shows what is true today.
DotCensus is not currently a Google-certified CMP and is not registered under IAB TCF. The standards status page carries the live state of each one, and is the page we update rather than the marketing copy.
- receipt_id
- rcpt_7f3c9a12
- timestamp
- 2026-09-21T09:14:22Z
- region
- EEA
- policy_pack_version
- eea-optin@4
- banner_version
- banner@12
- manifest_version
- manifest@31
- granted
- necessary, analytics
- denied
- marketing
- browser_signal
- none detected
- proof_hash
- sha256:9b41…c7e2
The three version fields are the point: they let this decision be read correctly years after the banner, the policy and the site have all changed.
Prove
Reconstruct the choice, not just the boolean.
“Consent: true” is not evidence of anything. A receipt names the banner that was shown, the policy in force, the service inventory it covered and what was granted — so a decision from two redesigns ago still means something.
And it does it without building a visitor profile, which would be a strange asset for a privacy product to accumulate.
Who it is for
From one website to a fleet of them.
The same engine, reached through whichever door fits: a dashboard, a CMS plugin, an API or a platform integration.
Why trust it
Claims you can check against the product.
No customer logos, no accuracy percentages and no compliance badges: the product is in early access, and a privacy vendor caught inventing proof has nothing left to sell.
Discovery and enforcement share a brain
The signature set that names a service in the scan is the one that holds it at runtime, so the inventory and the blocking cannot disagree.
The refusal path is tested
Anyone can check that tags fire after acceptance. Privacy Health checks the state nobody looks at — what still runs after someone says no.
Evidence points at versions
A receipt names the banner, policy and manifest it was made under, so it still means something after the site changes.
Minimal by construction
A pseudonymous subject key, no durable visitor profile, and no raw IP retained as a default — a privacy product that quietly builds a tracking asset is the wrong shape.
Security & data
A privacy platform should collect as little as it can.
The uncomfortable question for any consent vendor is what it collects about your visitors. The answer here is: a pseudonymous key, the decision, and the versions needed to read it later.
Data minimization
Pseudonymous subject keys rather than durable visitor identifiers, and no raw IP kept by default — where an address is needed for routing or abuse control, its retention and transformation are disclosed.
Separated planes
Customer configuration, visitor consent evidence and scanner artifacts are separate stores. A scanner worker cannot reach the control plane's database.
Scanner isolation
Scans run in isolated browser workers with SSRF protection, blocked internal address ranges, download limits and cleanup after each job.
Tenant isolation
Every record belongs to a tenant, and authorization is evaluated per object — for pages, exports and API access alike.
Versioned configuration
Published policies, banners and manifests are immutable, with an audit trail of who changed what and when.
Configurable retention
Receipt and scan-artifact retention is a setting, because evidence has a longer useful life than a log line and a shorter one than forever.
Questions
Including the ones we are expected to overclaim on.
Certification status, whether software can make you compliant, and what happens to visitor IP addresses.
It discovers the cookies and tracking technologies a website loads, collects and manages visitor choices, controls which services may run, communicates privacy signals to connected tools, and keeps evidence of those decisions.
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