Overview
- Written for
- + Written for
- Deprecated
- + Deprecated
- Applies to
- + Applies to
Overview
Cookie Munch is a self-hosted Consent Management Platform (CMP) — a Cookiebot or CookieYes alternative you run yourself instead of renting per-domain. This page is a conceptual map of the dashboard: the handful of ideas that everything else is built from, and how they connect. If you want the fastest path to a live banner instead, jump to the 5-minute quickstart.
The organization is the container
Everything you do in the dashboard happens inside an organization. An org owns:
every property (domain) you protect,
every banner design,
the team members who have access, and
the plan/billing subscription.
When you first sign in, Cookie Munch creates a default organization for you. You can belong to more than one — the organization switcher at the top of the sidebar shows the active org's name and your role badge in it, and lets you jump between orgs or spin up a new one. Switching orgs re-scopes the entire dashboard: properties, banners, members, usage, everything you see is per-org. How many organizations you personally own is capped by your account's plan; being invited into someone else's org doesn't count against that.
A property is one domain
A property is a single domain (or app) wearing a Cookie Munch banner. Add one from Properties in the sidebar: give it a domain and pick a platform (Web, iOS, Android, AMP, or Other — this only tailors the install guidance you see, it doesn't change the embed itself). Cookie Munch derives a unique site ID, called the cbid, from the domain — this is how the banner, the config API, and the consent log all identify "which site is this." Properties are effectively unlimited on every plan (a generous 50-per-org cap); plans differentiate on usage and features instead. See Properties for verification and day-to-day management.
The banner and prior-blocking
Each property is protected by a single <script> tag (see Installing the script) that does two jobs the moment it loads:
Renders the consent banner — accept/reject/customize, with granular categories, themed to match your site.
Blocks third-party scripts before consent is given. This is "prior blocking," and it's the part a lot of banner-only tools skip. In auto mode, the embed rewrites
<script>tags on the page (changing their type so the browser won't execute them) and only unblocks each category's scripts once a visitor grants that category. Manual mode instead honors explicitdata-cookieconsentmarkup you add yourself, for cases where you want fine control over exactly what waits. The blocker also reads the legacy CookiebotCookieConsentcookie, so migrating from Cookiebot doesn't force you to re-prompt visitors who already made a choice there.
Banner appearance and behavior live in Banner Studio, which is a separate design surface from this set of guides — the short version is that a design is edited as a draft and takes effect on assigned properties only once you Publish it.
The consent ledger
Every decision a visitor makes — accept, reject, or a granular mix — is written to a consent record. These records are:
Anonymized — IP addresses are truncated before storage, not kept in full.
Hash-chained — each record incorporates a hash of the one before it, so the log is tamper-evident: altering or deleting a past entry breaks the chain and is detectable. This is what makes the log usable as compliance evidence, not just an analytics table.
You can browse and export this ledger per property from the dashboard, and it's the backing data behind analytics, audit, and DSAR (data-subject request) tooling elsewhere in the product.
Compliance frameworks
Cookie Munch speaks the standards that downstream tools and ad networks expect:
Google Consent Mode v2 — signals visitor consent state to Google tags automatically, so Analytics/Ads behave correctly without you wiring it up manually.
IAB TCF v2.2 / GPP / US Privacy — the programmatic-advertising consent strings needed for real-time-bidding compliance. This is heavier, so it's loaded lazily (only when a framework is active) rather than shipped in every page load.
Geo rules and GPC — banner behavior can vary by visitor region (e.g. an opt-in banner in the EU vs. an opt-out link in California), and the embed respects the Global Privacy Control signal where applicable.
Some of these are plan-gated — see Plans & billing for which tier unlocks what.
People and access
Within an org, teammates have one of four roles — Owner, Admin, Member, or Viewer — that determine what they can see and change. Billing, danger-zone actions, and account-level security (password, sessions, connected sign-in methods) are per-person, not per-org, and live under Settings and Account. See Organization & members and Account security.
How it fits together
A typical mental model, end to end: you create an org → add a property for each domain → install the script tag on that domain, which starts blocking trackers and showing the banner immediately → visitor choices flow into the consent ledger → your team collaborates on banner design and settings according to their role → usage against your plan is tracked continuously, and features like TCF or SSO unlock as you upgrade. Every one of those nouns has its own guide in this set — this page exists so the vocabulary is familiar before you dive into the step-by-step instructions.