Domains

1. Domains → Add domain. Paste the site address. A full URL is fine: the scheme, path and www. are stripped and the panel shows you what will actually be stored.
2. Pick the primary region. This records which regime the site serves; the banner’s own geo behaviour is set separately under Targeting.
3. Choose how you will install the tag. This decides what the Install screen shows you afterwards: a snippet, the WordPress plugin, the Tag Manager template or the Shopify steps. You can change it later.
4. Choose a verification method, then press Add domain.

Subdomains. app.example.com and example.com are separate domains here, each with its own banner and logs. A visitor’s decision is stored on the root domain, so subdomains of one site share it.

Script tag

Two blocks pasted into <head> of every page, as high as possible: the Consent Mode default first, then the tag. Works on any site or framework.

WordPress

Our plugin, downloaded from the Install screen and uploaded under Plugins → Add New → Upload Plugin. You paste the Site ID into its settings; it prints the tag ahead of other plugins.

Google Tag Manager

Our gallery template with the Site ID, fired on Consent Initialization — All Pages; or a Custom HTML tag with the snippet on the same trigger.

Shopify

The snippet in theme.liquid inside <head>. Decisions are also forwarded to Shopify’s own consent API automatically.

Wix

The snippet under Settings → Custom Code, in the head, on all pages. Needs a paid Wix plan with a connected domain. Decisions are forwarded to Wix’s own consent policy automatically, so Wix’s built-in analytics and marketing tools follow them; turn Wix’s own cookie banner off.

Change the route any time from the Install screen: the pills at the top switch the instructions and save the choice on the domain.

Press Install tag on a domain’s row. The screen always shows the Site ID on its own line with a copy button, then the steps for your install route. For the script route that is the snippet below, which already carries the Site ID as data-site.

<script>
window.dataLayer=window.dataLayer||[];function gtag(){dataLayer.push(arguments)}
gtag('consent','default',{ad_storage:'denied',ad_user_data:'denied',ad_personalization:'denied',analytics_storage:'denied',wait_for_update:500});
</script>
<script async src="https://cdn.cmpstack.io/cmpstack.js"
  data-site="YOUR-SITE-ID" data-api="https://api.cmpstack.io"></script>

Two blocks, in this order. The first sets Google Consent Mode to denied before anything else loads. It matters for the one case the tag cannot help with: if the tag itself cannot be fetched, nothing of ours runs, and without this line your Google tags would fire as though no banner existed. With it they stay off until the banner arrives. It protects Google tags only: Meta, TikTok and other tags read no Consent Mode signal, and the tag blocks those itself.

Where it goes on each route. The WordPress plugin prints it for you, and the Google Tag Manager template sets the same default itself when it fires on Consent Initialization — All Pages. On every other route, paste it from Install tag, which also says where on that platform it cannot reach: Shopify checkout pages, which load no theme code, and tools that Wix’s Marketing Integrations load. Those follow the platform’s own consent setting, which the tag sets from every decision.

Consent tag

Install the tag first. Verification fetches the site and looks for a tag carrying this domain's Site ID. Works on every framework.

DNS TXT

Add the TXT record shown on the Verify screen at your DNS provider. Can take up to a few hours to propagate.

Meta tag

Add the <meta> tag shown to the page’s <head>. Some frameworks render head tags late; use the consent tag instead if it fails.

File upload

Host the file shown at /.well-known/ on the site.

Press Verify on the row. A domain is Pending until a check succeeds, Verified after, and Error when the last check failed; the reason is shown on the row so you know what to fix before pressing Verify again.

Domains → Manage groups creates named groups with a colour. Assign a domain from its row menu, then filter the list by group. Groups change nothing about the banner or the logs; they are for finding things.

Each plan covers a set number of domains. A domain is a root domain, its www, and up to two further subdomains — example.com, www.example.com, shop.example.com and blog.example.com count as one, each with its own banner, logs and score. A third subdomain counts as another domain; www never counts. The Domains list groups hostnames under their root, with a heading such as “4 hostnames · counts as 1 of 10 domains on your plan”; each row says what it is billed as, and the stats strip shows billed domains against your plan.

If a workspace holds more than its plan covers, for example after a downgrade, the domains it has held longest stay live and the rest are marked past the allowance: their banners are unpublished and cannot be published again until you upgrade or remove a domain you added earlier. An extra subdomain goes before a root does.

1. On the domain’s row choose Transfer, enter the destination workspace’s address and an email of one of its owners or admins.
2. They receive an email with an accept link. Until they act, the transfer is pending and you can cancel it from Domain transfers at the bottom of the Domains page.
3. On accept, the domain moves in one step: its banner, consent logs, scans and cookies all go with it, and it keeps the same Site ID, so nothing on the site changes.

A CSV export of the consent log is attached to the acceptance email, so the sending workspace keeps a copy of the record it is handing over. The destination’s plan allowance applies from the moment it lands.

A scan does not just load your home page. It follows your links, visits several pages, and on each one runs three separate passes: before any choice has been made, as a visitor who rejected and as a visitor who accepted. Comparing those three is what lets us say whether your banner is actually holding anything back, rather than only listing the cookies that appeared.

What each pass records. Every request the page makes, and everything it stores — cookies, local and session storage, and IndexedDB databases — by name only. Values are never read, so a scan never holds anything that belongs to one of your visitors.

On a domain where your banner is published, the last two passes are run by recording the decision before the page loads, exactly as it would be for someone who chose last week — not by clicking the buttons. That is both more reliable and closer to what most of your visitors actually are: returning people whose choice is already made. Where no banner has been published yet, the scanner looks for the controls and presses them, and says so on the run if it could not find them.

Open Scans on a domain row to see the schedule line — how often, how many pages, how long a run may take, and when the next one is due — followed by every recent run and what each pass saw.

How long it takes, and how to follow it. Three passes a page is real work: allow up to about ninety seconds per page, so a five-page plan is a few minutes and a fifty-page one can run most of an hour. The schedule line states the ceiling before you start anything, and the toast you get on pressing Run scan repeats it for that run. Most scans finish in well under it.

Your plan’s pages are per period, not per press. The plan gives each domain a number of pages a month (or a week), and Run scan spends the same pages the schedule does. Pages are counted as visited, so a small site can be scanned more than once, and a run that failed on our side costs nothing. The schedule line shows how many are used; once they are, Run scan says when it is available again, and the scheduled runs carry on as usual. A plan with more pages raises it.

While a run is going, the domain row shows Scanning, with the page it has reached — and the Scans drawer shows the same as a progress bar. Both update on their own; there is nothing to refresh. You do not have to wait on the screen. A finished run appears in your notifications straight away, and the email that goes with it is digested by default — scanning fifty domains should not mean fifty emails. If you would rather hear about each one as it lands, change A cookie scan finishes to immediate under Settings › Notifications.

When we could not look. Some sites refuse a crawler — a bot challenge, a firewall, a wall of 403s. That run is marked could not look, in its own colour, with the reason. It is not a clean result: nothing was checked. Two things usually fix it — allow our scanner’s addresses through your firewall or WAF, or exempt the cmpstack/1.0 user agent from the challenge. The Scans drawer lists the addresses on the blocked run, and cmpstack.io/scanner explains the crawler to whoever runs the firewall — it is also the page our user agent links to.

When we could not operate the banner. A page where the crawler could not find a reject control is listed separately, with the reason. We reached the page but established no state, so nothing about enforcement was proved there — again, not the same as clean.

Deep scans. Agency and above can nominate a few domains for a monthly deep run that visits far more pages than the routine one. Tick Deep scan this domain in the Scans drawer; the drawer shows how many nominations your plan allows and how many are in use. The deep run takes the place of that week’s routine run, so a domain is never crawled twice for one answer, and the weekly routine runs carry on in between. The Scans drawer shows both schedules and says when the next run is the deep one.

The Cookies drawer still shows what the last scan found: each cookie, who sets it, and its category. Cookies the scanner does not recognise are listed as unclassified, so you can decide where they belong. Scans are queued and run in the background; Professional and above are scanned with priority.

A scan tells you what a page did. The enforcement report tells you what that proves: whether anything ran before the visitor agreed, whether pressing reject actually stopped it, and whether the vendors you gated are firing when they should. Open it from Enforcement report on a domain row.

Five kinds of finding. Two of them are good news, and they are shown as such rather than left out:

• Consent state mismatch — the page told a vendor consent was granted when nobody had granted it, or kept saying denied after accept. Ranked above everything else: a leak is something forgotten, this is something asserted.
• Leak — a vendor contacted before consent that carried an identifier or a cookie, or that has no consent-denied mode at all, so being contacted is itself the problem.
• Failed to fire — a vendor your blocking rules name that never ran, even after accept. Usually an over-broad rule, and the one that costs you measurement you were entitled to.
• Fired correctly — absent before consent, present after. The gate works, demonstrated rather than assumed.
• Compliant denied ping — a consent-aware vendor contacted before consent that declared consent denied and carried nobody. This is Google Consent Mode working as intended. It is not a leak, and blocking it outright would lose you modelled conversions for no privacy gain.

Every finding quotes its evidence. Expand one to see the actual requests it rests on — the URL, whether it carried an identifier or a cookie, and the vendor’s own consent signal where it sent one. A finding without that is an accusation, and this is a document you may forward.

By page or by vendor. Group by above the list sorts findings under the page they were seen on — what to fix where — or under the vendor — whom to ask. The biggest group comes first.

Dashboard and email. The Enforcement tile on the dashboard counts what changed this week, and Open report goes straight to the report that found something. You are emailed when something appears or comes back — not when a report is merely produced, and not when something is fixed. A product that emails after every scan is one whose mail you filter away, which costs it the alerts that matter.

The PDF. PDF downloads the report as a document: cover, summary, every finding with the requests it cites, and a page explaining how it was measured — because whoever you send it to was not in the room, and their first question is how we know. It contains no visitor data: the scanner records cookie names, never values.

Portfolio answers the question you have across every client at once: where is the trouble. One row per domain, grouped under its client, with domains that belong to no client collected at the bottom.

Score

The same 0–100 compliance score as the Compliance screen, in the same colours: green from 90, amber from 70, red below.

Leaks

Leaks found by the most recent scan that could actually operate the banner. A dash means the domain has never been assessed — unknown, not zero.

Last scan

When the domain was last scanned, and a note if that scan could not decide or was blocked.

Banner

Live if a banner is published; Unpublished if visitors are seeing none.

Consent (7d)

Banner decisions over banners shown in the last seven days — the same figure as the Dashboard's consent rate for that domain.

Trend (14d)

Two weeks of that rate, one point a day. The line breaks on days nothing was shown rather than dropping to zero.

Filters and sorting. Search by hostname, pick a client, narrow to a score band, or show only domains with leaks or without a published banner. The number beside each filter is how many rows it would show. Click a column heading to sort; each column opens with the worst rows first — lowest score, most leaks, oldest scan, lowest consent. Domains with nothing to report in that column always sort to the end, whichever way you sort.

Saved views. Set the filters you want, then use Saved views to name them. Views are yours alone — colleagues do not see them, and you cannot see theirs. The filters are also kept in the page address, so you can bookmark a view or send the link to someone.

Keyboard. / jumps to search. In the table, ↑ and ↓ (or j and k) move between domains, Page Up and Page Down jump ten, Home and End go to the ends, and Enter opens that domain’s enforcement report.