What it tells Google

Consentio does not block Google’s tags. It tells them what they are allowed to do, and they behave accordingly. This page is exactly what it says, and how to confirm it arrived.

💬 Four words you will see

Your four categories are the choice a visitor sees. Google’s seven signals are what the tags understand. Consentio translates one into the other, and the table below is the whole translation.

📡 The two messages, in full

Before the visitor answers — sent by the script tag, or by the Tag Manager template:

gtag('consent', 'default', {
  ad_storage: 'denied',
  ad_user_data: 'denied',
  ad_personalization: 'denied',
  analytics_storage: 'denied',
  functionality_storage: 'denied',
  personalization_storage: 'denied',
  security_storage: 'granted',
  wait_for_update: 500          // present only when there is no stored answer
});
gtag('set', 'ads_data_redaction', true);   // true whenever ad_storage is denied

When the visitor accepts all, or saves their choices:

gtag('consent', 'update', { /* all seven signals, again */ });
gtag('set', 'ads_data_redaction', false);

Two rules behind that, both worth knowing if something looks wrong:

• All seven are named every single time. Leave one out of an update and Google keeps its old value — which is exactly how a permission someone just withdrew stays granted. So nothing is ever omitted.
• wait_for_update is only sent to someone who has not answered yet. It tells tags to hold on briefly for an answer. Sending it to a returning visitor would delay tags waiting for a banner that is never going to appear.
• ads_data_redaction goes with every message, true whenever ad_storage is denied, so revoking marketing turns redaction back on rather than leaving it where the last message put it.

🔀 Categories map to signals

This mapping is fixed and you cannot change it. That is deliberate: it is what lets the correct first message be sent before any of your settings have been downloaded.

Denied wins. A signal is granted only when every category feeding it is granted, and a signal nothing feeds stays denied. So if a visitor allows one of the two categories behind personalization_storage, it stays denied.

🔍 How to check it

In the console, on any page running the banner:

window.dataLayer.filter(e => e[0] === 'consent')

Two things to look for. The first consent entry should be default, and it should come before anything your tag manager pushed — scroll up in window.dataLayer and check what is above it. Then answer the banner and run it again: a second entry appears, consent update, naming all seven signals.

In Tag Assistant, which is the only way to see the ordering properly on the Tag Manager route:

1. Preview the container and load your page.
2. Open the very first event in the left-hand list — Consent Initialization or Container Loaded.
3. Look at the Consent tab. On-page Default should be filled in, with security_storage granted and the rest denied for a visitor who has not answered.
4. Click through to the tags that fired on that event. None of them should be a tag you meant to hold back.

If the default is missing or arrives late, the cause is ordering, not configuration — troubleshooting lists the ways that happens.

⚠️ This does not stop other scripts running

Worth being blunt about, because it catches people out. These messages tell Google’s own tags what they may store and send. Any other script you loaded will do whatever it was always going to do — it has never heard of Consentio.

In Tag Manager, that is what the container’s own consent settings are for: a tag can be told to wait for a particular signal before it fires.

A script you pasted into the page, on either route, is held back by marking it: type="text/plain" and data-consentio naming the category it needs, and Consentio runs it once that category is granted. Hold a script until consent shows the tag before and after. For anything a tag cannot say, events carry the same moment as JavaScript:

document.addEventListener('consentio:consent-update', (event) => {
  if (event.detail.statistics_performance === 'granted') {
    // now load the thing
  }
});

🔗 url_passthrough, if you ask for it

Google’s third flag beside wait_for_update and ads_data_redaction. With ad_storage denied, it carries the ad-click id (gclid, dclid) across your own pages in the URL instead of a cookie, so a Google Ads click still counts for a visitor who refused. It only matters to a site running Google Ads, and it puts a click id into every internal link — which is why it is off unless you turn it on.

Turn it on with data-url-passthrough="true" on the loader tag, or "urlPassthrough": true in the settings file on the Tag Manager route. Either way it goes out as a set, straight after the default:

['set', 'url_passthrough', true]

🚫 What Consentio does not send

One thing Google’s consent API takes and Consentio leaves alone: a default that depends on the visitor’s country. Google’s default command takes a region list, so a site can grant by default outside the EU. Consentio denies everywhere it runs. If you need a granted default for some regions, that is a decision to make in the container’s own consent settings, after the tag — Consentio will not push one.