Properties (sites & domains)
- Written for
- + Written for
- Deprecated
- + Deprecated
- Applies to
- + Applies to
Properties (sites & domains)
A property is one domain (or app) protected by a Cookie Munch banner. The Properties page — sidebar → Properties — is where you add, verify, and manage every domain in your organization. This guide covers that whole lifecycle.
What's on the Properties page
Properties render as a grid of cards. Each card shows:
The domain, with the platform label underneath it (Web, iOS, Android, AMP, or Other).
The
cbid— click it to copy. This is the site's unique identifier; the embed script, the config API, and the consent log all address the property by this ID, not by its domain string.A verification badge —
VerifiedorPending.Quick links to Banner Studio (design the banner for this site) and Cookies (its auto-discovered cookie declaration table).
An Install button that opens the copy-pasteable script tag for that property.
While the list is loading, or if you have no properties yet, the page shows a skeleton or an empty state with an Add property call to action.
Adding a property
Click Add property (top right of the page, or the empty-state button) to open the dialog:
Domain — e.g.
acme.com. Type it with or without a scheme; Cookie Munch stripshttps://, lower-cases it, and trims trailing paths before storing it.Platform — Web, iOS, Android, AMP, or Other. This only tailors the install guidance you're shown; the embed tag itself doesn't change based on platform.
Click Add.
Behind the scenes, Cookie Munch derives a site ID (cbid) from your domain plus a short random suffix — e.g. acme.com becomes something like acme-com-9f3k. This is generated for you; you don't need to invent or format it yourself. If you're at your plan's property limit, the Add property button is disabled and a hint explains why — see Plans & billing. In practice this limit is generous (50 per organization on every tier); it exists as a hard ceiling rather than a real lever plans differentiate on.
Verifying ownership
A newly-added property starts Pending until you prove control of the domain. Click Verify on its card to open the verification dialog, which offers four tabs:
Method | How it works |
|---|---|
DNS | Add a TXT record at |
Meta tag | Paste a |
File | Upload a token file to a well-known path on your domain, then click Verify now. |
Auto | Explains that verification can also happen automatically once the install snippet has beaconed home from your live domain — no separate action needed here, just install the script and give it a moment. |
Each token is per-property and pre-filled in the dialog — copy it with the button next to the field rather than retyping it. Verification is checked on demand, not continuously: after making the DNS/meta/file change, come back and click Verify now again to trigger the check. If it doesn't pass, the dialog shows the reason inline so you know what to fix (e.g. record not found yet — DNS propagation can take a few minutes).
Multi-domain and subdomains
There's no special "add a subdomain" flow — a subdomain is just another domain, added as its own property with its own cbid, verification, and (optionally) its own banner design. This is deliberate: blog.acme.com and shop.acme.com may need different categories, different regional rules, or different banner copy, so keeping them as separate properties keeps that possible. If you want the same banner design across many properties, design it once and assign it to each property from Banner Studio rather than rebuilding it per domain — see the banner library for reuse patterns.
The cbid in practice
The cbid shows up in a few places you'll want to recognize it:
As
data-cbidin the install snippet (see Installing the script) — this is what ties an embed on a page back to this property's config.As the path segment in config and cookie-declaration API calls (
/config/:cbid,/api/v1/:cbid/cookies).As the identifier the consent log, analytics, and scanner all group records by.
Because so much keys off it, don't hand-edit or reuse a cbid across domains — treat it as an opaque, property-scoped ID, and copy it (via the click-to-copy button on the card) rather than retyping it.
The active property
The sidebar has a property switcher below the organization switcher, showing which property is currently "active" — the one that Banner Studio, the Cookies table, and other single-site pages operate on by default. Change it either from that dropdown, or by clicking Set active on a property's card on this page. Switching is instant (no full page reload) and is remembered across sessions on the device you're using.
Managing a property day to day
From a property card you can jump straight into:
Banner Studio — design or reassign the consent banner shown on this domain.
Cookies — the auto-discovered cookie declaration table, kept current by the cookie scanner.
Install — re-open the snippet any time (useful after a redeploy wiped your
<head>, or when onboarding a developer who needs the exact tag).
There's currently no delete/archive action surfaced on this page — properties are meant to persist for the life of the domain they represent.
Tips and gotchas
Add the property before you generate/copy the install snippet — the snippet is baked with that property's real
cbid, so grabbing one early and editing it by hand is a common source of "the banner never appears" bugs.A
Pendingbadge doesn't stop the banner from working — verification proves domain ownership for your own records and future features, it isn't a gate on the embed functioning.If you re-platform a site (e.g. move from custom HTML to a site builder), keep the same property/
cbidrather than creating a new one, so your consent history and cookie declaration carry over.
Next steps
Installing the script — the full tag reference.
Overview — how properties fit with prior-blocking and the consent ledger.
Plans & billing — property, seat, and event limits per tier.