How to set up Google consent mode

Google consent mode is how your Google tags learn whether a visitor has agreed to be measured. GTM4WP can send the first half of that conversation for you, the consent default, so that your Google tags know where they stand before your consent tool has said anything.

This page describes GTM4WP 2.0.0 and newer. Where the legacy 1.x versions of the plugin behaved differently, the older behavior is marked with a bold GTM4WP 1.x: lead-in.

The two commands

Consent mode works with two commands, and it is worth being clear about which one belongs to whom.

1. The default command describes the state that applies before the visitor has chosen anything. It has to run before your Google tags load, otherwise those tags start with no instruction at all.
2. The update command is sent when the visitor makes a choice, and usually also on later page loads when a stored choice is found in the browser. It comes from your consent management platform.

What GTM4WP sends and what it does not

GTM4WP sends the default command only. It never sends the update command, for the simple reason that it does not know what the visitor chose. No part of the plugin reads the state of a consent banner.

The update has to reach Google some other way. Either your consent tool talks to Google itself, or you build a tag in your Google Tag Manager container that sends the update when your consent tool reports a choice. Both routes are described further down this page.

This also gives you the rule for deciding whether to enable the option at all:

• If your consent tool sends the default command as well as the update command, leave this option off. The default is meant to run once, before any measurement. Two of them on the same page load is redundant at best, and it can overwrite the state your consent tool has just established.
• If your consent tool sends only the update command, turn this option on so that the default arrives in time.

The setup pages for the individual consent tools say which case each of them falls into. Cookiebot installed directly on your site is the common example of the second case: it sends the signals on consent submission, but setting the default is left to you.

Turning the default command on

Open the plugin settings and go to the Consent mode & consent tools section, then the Google Consent Mode group. The first checkbox, also called Google Consent Mode, activates the default command. The plugin emits nothing while it is off.

The remaining seven checkboxes set the value of one consent signal each. A checkbox that is off means the signal is denied by default, which is what you want in the European Economic Area and the United Kingdom. Ticking a checkbox makes that signal granted before the visitor has agreed to anything, so use it only for testing or for an audience where you have established that no consent is required.

Since 6 March 2024 Google requires ad_user_data and ad_personalization to arrive through consent mode for visitors from the European Economic Area and the United Kingdom. Without them, Google Ads and Google Analytics 4 will not use that traffic for audiences or for personalized advertising. Sending all seven signals costs you nothing extra and prepares you for further requirements.

GTM4WP 1.x: the same eight checkboxes are on the Integration tab, and the block they produce is identical.

What ends up on the page

With every signal left denied, this is what the plugin writes into the page:

<script data-cfasync="false" data-pagespeed-no-defer>
	if (typeof gtag == "undefined") {
		function gtag(){dataLayer.push(arguments);}
	}

	gtag("consent", "default", {
		"analytics_storage": "denied",
		"ad_storage": "denied",
		"ad_user_data": "denied",
		"ad_personalization": "denied",
		"functionality_storage": "denied",
		"security_storage": "denied",
		"personalization_storage": "denied",
	});
</script>

The plugin prints this block immediately before the container code, in the same pass over the page head, so it always runs before the browser requests gtm.js. You do not need to reorder anything in your theme for that to hold.

The gtag function is only defined here if nothing else has defined it yet, so a Google tag that you load yourself keeps its own implementation.

Sending the update command from Google Tag Manager

If your consent tool does not send the update command to Google on its own, you build it in your container. The steps are the same whichever consent tool you use, and they all start from a data layer event that announces the choice.

1. Get the choice into the data layer. Some consent tools push an event themselves. For CookieYes and for WebToffee v2.x, GTM4WP does it for you and pushes a cookie_consent_update event, described on the setup page of each tool.
2. Create one Data Layer Variable per consent category, pointing at the key that holds the choice for that category.
3. Wrap each of those in a Lookup Table variable that turns the raw value into the string granted or denied, and give the lookup table a default value of denied. The consent mode tag expects those two words, not true and false.
4. Add the Consent Mode (Google tags) tag from the community template gallery, set its command to update, and map each signal to the matching lookup table variable.
5. Trigger that tag with a Custom Event trigger listening for the event your consent tool pushes.
6. Turn on Consent Overview in the container settings. It shows which of your tags read which signals, and it is the fastest way to find a tag that nobody has configured yet.

Publish the container and check the result in preview mode. The consent tab of the preview shows the state at the start of the page and after each command, so you can confirm that a default arrived first and an update followed it.

Basic and advanced consent mode

Once the two commands are in place you have what Google calls advanced consent mode. The Google tags load on every page and adjust their behavior to the signals. When a signal is denied they set no cookies and store no identifiers, but they do send a cookieless ping, which Google uses to model the missing data.

Whether that ping is acceptable before consent is a question for your lawyers, and opinions differ across member states. If the answer is no, you need basic consent mode: the Google tags must not run at all until consent exists. You get there by giving each Google tag a required consent in its consent settings, or by adding an exception trigger, so that the tag waits for the update instead of firing on page view. GTM4WP is not involved in that decision either way, since it happens inside your container.

There is more on this question, and on where the responsibility sits, on the GDPR page.

Adjusting the default from PHP

The checkboxes give every visitor the same default. If you need the default to depend on where the visitor comes from, the plugin offers a filter that runs for each of the seven signals:

add_filter(
	'gtm4wp_overwrite_consent_mode_flag',
	function ( $flag_value, $flag ) {
		// Return true for granted, false for denied.
		// $flag is the option key, for example integrate-consent-mode-analytics.
		if ( ! my_visitor_needs_consent() ) {
			return true;
		}

		return $flag_value;
	},
	10,
	2
);

Two things are worth knowing before you rely on it. The filter runs only while the Google Consent Mode option is enabled, so it cannot switch the feature on by itself. And it decides the default only, never the update, so a visitor who is granted by default still needs a working consent banner if your rules for that audience change later.

The filter is listed together with the rest of the plugin API on the actions and filters page.

Troubleshooting

No default appears in the consent overview. Either the first checkbox is off, or a consent tool integration has suppressed it deliberately. Axeptio does that when its own Google Consent Mode v2 option is enabled, because Axeptio then sends the default itself.

The default is sent twice. Your consent tool is sending one as well. Decide which one you want and turn the other off. Keeping the one from the consent tool is usually the better choice, since it stays in step with the update command.

Tags still fire while a signal is denied. That is advanced consent mode working as designed. Consent mode adjusts what a tag stores, it does not stop the tag from running. See the section above on basic mode.

The update never arrives. Check in preview mode whether the data layer event your trigger listens for is actually pushed. If it is missing, the problem is between your consent tool and the data layer, not in the consent mode tag.