Prior blocking: stopping trackers before consent
- Written for
- + Written for
- Deprecated
- + Deprecated
- Applies to
- + Applies to
Prior blocking: stopping trackers before consent
Prior blocking is the difference between a cookie banner that just displays a notice and one that actually enforces it. Most cookie-consent rules (GDPR, ePrivacy, and the guidance most EU/UK DPAs publish) require that non-essential cookies and trackers never fire until the visitor has actively consented — not "fire, then delete if they say no." Cookie Munch's embed (consent.js) does this for real: it intercepts tracking scripts, iframes, and pixels before they ever touch the network, and only releases them once the matching category is granted.
This guide covers what's for: how blocking mode is chosen and configured from the dashboard, the two ways it works under the hood, and how to prove it's actually holding.
Auto mode vs. manual mode
Every property has a blocking mode, set once when the site is created and adjustable later:
Auto (the default) — Cookie Munch watches the page for scripts, iframes, images, and other resource tags as they're inserted, checks each one against a known-tracker checklist, and neutralizes anything that matches a not-yet-granted category. No markup changes needed on your existing site.
Manual — you mark tracking tags yourself with
data-cookieconsentattributes, and Cookie Munch only touches what you've explicitly flagged. This trades setup effort for exact, predictable control.
Both are configured per property, so a marketing site with lots of third-party embeds can run auto mode while a highly custom app runs manual — there's no requirement that every property in your org use the same mode.
Step by step: setting blocking mode from the dashboard
Go to Dashboard → Properties and find the site. Its cbid (site ID) is shown on the card — click it to copy, or click Install to see the full
<script>tag, which includes adata-blockingmode="auto"(or"manual") attribute. This is what ships on the page.To change the mode after install, open Dashboard → Banner Studio, open Settings on the property, and go to the Behaviour tab.
Use the Blocking mode dropdown to switch between Auto and Manual. Publish the change from Studio to push it live.
Still on the Behaviour tab:
Ignore selectors — a comma-separated list of CSS selectors (e.g.
#chat, .no-block) that auto mode should never touch. Use this for a live-chat widget or a first-party script you've already vetted, rather than switching the whole site to manual for one exception.Observe cookies — leave this on so the embed also reports cookie names it sees on real page loads back to the scanner (see the Cookie scanner guide) — it doesn't affect blocking itself, but keeps your declaration table current.
Re-ask after (0–730 days, or "never") controls how long a visitor's choice is remembered before the banner reappears.
Suppress for bots (on by default) skips showing the banner to detected crawlers so blocking doesn't interfere with indexing.
If you find yourself listing more than a handful of ignore selectors, that's usually a sign the site is unusual enough to switch to manual mode instead.
How auto mode works
The embed patches the two DOM entry points scripts and pixels actually use to get inserted (appendChild and insertBefore), plus a MutationObserver to catch anything the parser inserts declaratively (e.g. tags already present in the HTML source). Every element that comes through either path is checked against the checklist:
If it's a
<script>, itstypeattribute is rewritten totext/plainso the browser refuses to execute it.If it's another resource tag (
<iframe>,<img>,<link>, etc.), itssrcis moved todata-cookieblock-srcand removed, so the browser never requests it.Either way, the element is tagged
data-cookieconsent="<category>"so it can be found and released later.
The checklist itself starts from a bundled list of common trackers (Google Analytics, Meta Pixel, Hotjar, DoubleClick, LinkedIn Ads, and similar) grouped into statistics or marketing, and is extended by your site's own cookie scanner results once you've run a scan — so blocking gets more precise for your vendors over time. The GTM container script (googletagmanager.com/gtm.js) is deliberately never blocked outright: blocking it would break Google Consent Mode, where GTM is expected to load and self-throttle its tags instead.
Once a visitor grants a category, every neutralized element carrying that category is reactivated: scripts are recreated with type="text/javascript" (re-creating the node is what makes the browser actually run it) and other resources get their real src restored.
How manual mode works
Manual mode turns off the DOM interception entirely and instead looks for markup you've written. Two shapes:
Scripts — set type="text/plain" so the browser won't execute it, and add data-cookieconsent naming the category (or categories, comma-separated):
<script type="text/plain" data-cookieconsent="statistics,marketing"
src="https://example.com/tracker.js"></script>Non-script resources (iframes, images) — since they can't use type, rename src to data-cookieblock-src:
<iframe data-cookieblock-src="https://www.youtube.com/embed/xxxx"
data-cookieconsent="marketing" frameborder="0" allowfullscreen></iframe>Valid category values are preferences, statistics, marketing, or ignore (an explicit bypass — ignore can't be combined with the others). An element is only released once every category it lists is granted. Cookie Munch also reads the legacy CookieConsent cookie Cookiebot writes, so a site migrating off Cookiebot doesn't need to re-mark its tags or re-prompt existing visitors — their old consent choice carries over.
Testing it actually worked
Don't take the banner's word for it — verify in the browser:
Open the site in an incognito/private window (a clean consent state) with DevTools → Network open, and reload before interacting with the banner.
Confirm no requests go out to analytics/ads/embed domains before you click anything. If your tracker isn't on the bundled checklist yet, run a cookie scan first — that seeds the checklist with your site's actual third parties.
Inspect the DOM (Elements panel) for the tag in question: in auto mode you should see
type="text/plain"anddata-cookieconsent="…"on it before consent; in manual mode you should see exactly the markup you wrote.Click Accept (or grant the specific category) in the banner and watch the Network tab again — the request for that tracker should now fire, and the tag's
typeshould flip back totext/javascriptin Elements.Reject a category and refresh: the tag should stay inert and no request should go out.
Tips
Place the install
<script>tag as early as possible in<head>— it can only intercept scripts inserted after it runs.Auto mode is checklist-based, so brand-new or highly bespoke tracking snippets can occasionally slip through until a scan catches them — the Network-tab check above is ground truth, not the dashboard state.
If a third-party script depends on load order, prefer manual mode or an ignore selector over auto-blocking it — reactivation re-creates the node, which can shift timing relative to other scripts.
In auto mode, an element you've explicitly marked
data-cookieconsent="ignore"is always skipped by the interceptor — use that instead of an ignore selector when you only need to exempt one specific tag.