How blocking works, and how to edit the rules

What does blocking do?

Blocking makes the UserGuard embed hold known tracker scripts until the visitor answers. Without blocking, a consent banner only collects an answer. The trackers run whatever the visitor says, and they've already run by the time the banner paints. With blocking on, scripts in a category the visitor allows are released and run normally, and 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.

How scripts get held

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, and UserGuard activates them when their category is allowed.

The first two are automatic and use the rules below. The third is explicit, so there's no URL matching and no ambiguity about what's held.

How does a rule match?

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

We use substrings so you can read a rule and know exactly what it holds. There's no pattern syntax to get subtly wrong, and a mis-escaped character can't 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 or remove any rule, including the built-ins, 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 can't map to the necessary category. Necessary scripts always run by definition, so a rule like that would do nothing, and the editor doesn't accept rules with no effect.

The editor offers one exception, for Google's own loaders. 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 to know about

The first is failure. If the embed can't 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, and so do the tags a visitor has already opted out of. 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, while releasing author-marked ones would do something you explicitly told us not to do.

The second is 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, but the request isn't 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's nothing to preload.