How blocking works, and how to edit the rules

What blocking does

A consent banner without blocking is a survey. The visitor answers, and the trackers run anyway. They already ran before the banner painted. With blocking on, the UserGuard embed holds known tracker scripts until the visitor answers. Scripts in a category the visitor allows are released and run normally. Scripts in a declined category stay held.

The rest of this article covers how the hold works, how the matching rules are written, and the two places where the mechanism has limits you should know about.

Three mechanisms, because scripts arrive three ways

A tracker can reach a page as a tag hardcoded in the HTML, as a tag another script injects, or as a tag you wrote yourself. Each path needs its own interception:

• A MutationObserver watches the document as it parses and neuters matching script tags hardcoded in the HTML before they execute.
• A createElement interception catches dynamically injected tags (the tag-manager pattern) and stops them before any network request is made.
• You can mark your own scripts with type="text/plain" data-ug-category="analytics" (or marketing, or functional). The browser ignores them; UserGuard activates them when their category is allowed.

The first two are automatic, driven by the rules below. The third is explicit: no URL matching, no ambiguity about what is held.

How a rule matches

A rule is a plain substring matched against the script URL. No regex, no globs. googletagmanager.com holds every script loaded from that host until its category is allowed. First match wins: when two rules could match the same URL, the earlier one decides the category.

Substrings are deliberately dumb. You can read a rule and know exactly what it holds. There is no pattern syntax to get subtly wrong, and no way for a mis-escaped character to silently match nothing.

Editing the rules

The Blocking tab lists your rules. Twenty-two built-ins cover the usual trackers: Google Analytics, Google Tag Manager, Meta, LinkedIn, TikTok, Hotjar, Clarity, HubSpot, Intercom, DoubleClick, and the rest of the familiar names. You can add your own rules, edit any rule, remove any rule, built-ins included, and re-add a built-in you removed.

Two guardrails apply:

• Patterns under 4 characters are rejected. A substring like js matches your own bundles, and a rule that holds your whole site is worse than no rule.
• Rules cannot map to the necessary category. Necessary scripts always run. That is what the category means, so the rule would do nothing, and the editor does not accept rules with no effect.

Google's own loaders are the one exception the editor offers: Advanced consent mode, under Behavior, lets them run before a choice with Google Consent Mode holding their cookies instead. See Google Consent Mode, basic and advanced.

Two limits, stated plainly

First, failure. If the embed cannot reach UserGuard's config, auto-blocked scripts are released and your site returns to its status quo: the behavior it had before UserGuard was installed. Author-marked scripts stay held. The asymmetry is deliberate: you marked those tags yourself, and firing your marketing scripts because our service hiccuped would be a compliance violation we caused. Releasing auto-blocked scripts restores what your site already did. Releasing author-marked ones would do something you explicitly told us not to do.

Second, preload. For a tag hardcoded in the HTML, the browser's preload scanner can start the network request before the observer reaches the tag. Execution is reliably stopped; the request is not always. If the request itself matters for a particular script, mark the tag yourself. A type="text/plain" tag is never a script to the browser, so there is nothing to preload.