Getting started
From a first scan to an implementation you have actually tested.
The order matters more than the tooling. This is the sequence we would follow on your site, and most of it is useful whether or not you end up using DotCensus.
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 order that matters
Five things people do in the wrong sequence.
Each of these costs a day when it is done backwards, and the last one costs considerably more when it is skipped.
- 01
Start with the scan, not the banner
Configuring categories before you know what the site loads means guessing at the mapping. Ten minutes of scanning saves an afternoon of re-categorizing.
- 02
Deal with the unknowns first
Unclassified third parties are where the uncomfortable findings are, and they are the ones no rule covers — so they keep firing in every state until somebody decides what they are.
- 03
Install the runtime as early as you can
Most consent failures are ordering failures. If the runtime loads after the tag manager, the tags it was supposed to govern have already gone.
- 04
Test the refusal path before you celebrate
Accepting and watching tags fire proves nothing. Refusing and watching them stay silent is the only test that tells you whether any of it works.
- 05
Put a scan on a schedule
A correct implementation decays: plugins update, campaigns add pixels, developers ship embeds. Nothing on the site announces it, so the only defence is looking regularly.
What a verified result looks like
Three states, and the middle one is the test.
| 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.
Further detail lives in the documentation and the guides.
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