Axeptio + GTM4WP – How to setup?

Axeptio is the one consent management platform GTM4WP loads for you. The other integrations expect the consent tool to be on the site already and only connect it to your container. With Axeptio you enter a project ID in the plugin settings and the plugin loads the Axeptio SDK itself, so no separate Axeptio plugin is needed.

This feature is new in GTM4WP 2.0.0.

Before you start

You need an Axeptio account with a published project. From that project you need two values, both available in your Axeptio dashboard: the project identifier and the name of the cookies version you want to serve.

Check first whether Axeptio is already loaded on your site by some other means, for example the Axeptio WordPress plugin or a tag in your Google Tag Manager container. Loading the SDK twice gives you two banners competing for the same consent state. Pick one route and disable the other before you continue.

The settings

Open the plugin settings, go to the Consent mode & consent tools section and the Axeptio group. There are four settings.

Enable Axeptio

The main switch. The plugin adds nothing to your pages while it is off, and nothing while it is on but the project ID is empty. Both have to be set before it writes anything.

Axeptio Project ID

Your project identifier, which the SDK receives as its clientId. This is the value that tells Axeptio which configuration to serve, so a typo here produces a site with no banner rather than an error message.

Cookies version

Axeptio calls the published configurations of a project its cookies versions, and the SDK loads one of them. As soon as a valid project ID is present, the plugin asks your Axeptio project for the list of published versions and turns this field into a dropdown.

If that list cannot be loaded, the field becomes a plain text box so that you can type the version name by hand, and a message explains what happened. The usual reasons are a project ID that does not exist, a project with nothing published yet, or a browser extension or content security policy in your WordPress admin blocking the request. Whichever you get, a version you have already saved stays selected, so a failed lookup never silently clears your setting.

Enable Google Consent Mode v2

This hands consent mode over to Axeptio completely. Axeptio then sends both commands, the default and the update, using its own vendor mapping.

Because two default commands on one page would fight each other, the plugin suppresses its own consent mode default automatically while this is on. You do not have to remember to turn the Google Consent Mode option off, and turning it on will not bring the duplicate back. If you would rather keep control of the default yourself, leave this checkbox off and set the default up as described on the Google consent mode page.

The default state handed to Axeptio denies everything and asks Google to wait half a second for an update before acting:

{
  "analytics_storage": "denied",
  "ad_storage": "denied",
  "ad_user_data": "denied",
  "ad_personalization": "denied",
  "wait_for_update": 500
}

What ends up on the page

With everything enabled, the plugin adds this to the block it already writes at the top of the page head, before the container code:

window.axeptioSettings = {
  "clientId": "your-project-id",
  "cookiesVersion": "your-cookies-version",
  "googleConsentMode": {
    "default": {
      "analytics_storage": "denied",
      "ad_storage": "denied",
      "ad_user_data": "denied",
      "ad_personalization": "denied",
      "wait_for_update": 500
    }
  }
};

window._axcb = window._axcb || [];
window._axcb.push(function(axeptio) {
  axeptio.on("cookies:complete", function(choices) {
    window.dataLayer = window.dataLayer || [];
    window.dataLayer.push({
      "event": "gtm4wp.axeptioConsentUpdate",
      "axeptioChoices": choices
    });
  });
});

The SDK itself is then loaded from static.axept.io as an async script. The cookiesVersion and googleConsentMode keys only appear when you have filled in the version and enabled consent mode v2, so a minimal setup produces a settings object with clientId alone. Where the example says dataLayer, the plugin writes the data layer variable name configured in your settings.

This is the one place where GTM4WP causes a 3rd party script to load. That is what a consent management platform is for, but it is worth knowing before you enable it, particularly if you keep a list of the external requests your site makes.

The data layer event

Whatever you do about consent mode, the plugin pushes a gtm4wp.axeptioConsentUpdate event whenever Axeptio has settled the consent state. Axeptio emits its cookies:complete event once it knows which vendors were accepted or refused, including on a return visit where the banner never appears, so this event is a reliable point to hang tags on.

The axeptioChoices key carries the choices object exactly as Axeptio produced it. It holds one entry per vendor configured in your Axeptio project, keyed by the vendor identifier you chose in the Axeptio back office, with a boolean value. It also carries a $$googleConsentMode entry describing the consent mode state Axeptio last sent.

To use it in Google Tag Manager:

1. Create a Custom Event trigger for the event name gtm4wp.axeptioConsentUpdate.
2. Create a Data Layer Variable for each vendor you care about, using the key axeptioChoices followed by a dot and the vendor identifier, for example axeptioChoices.google_analytics.
3. Use the trigger from step 1 in place of a page view trigger on tags that must not run before consent is known, and use the variables from step 2 in their firing conditions.

If consent mode v2 is enabled you do not need a consent mode tag in your container, since Axeptio is already sending both commands. The event is still useful for anything outside consent mode, for example a non-Google marketing tag that has to wait for a specific vendor.

Changing the default from PHP

The default consent state passed to Axeptio can be adjusted with a filter, for example to grant the signals for an audience where you have established that no consent is required, or to change how long Google waits for the update:

add_filter(
	'gtm4wp_axeptio_consent_mode_default',
	function ( $consent_default ) {
		$consent_default['wait_for_update'] = 1000;

		return $consent_default;
	}
);

The filter runs only while the consent mode v2 option is enabled. It is listed with the rest of the plugin API on the actions and filters page.

Troubleshooting

No banner appears and nothing is added to the page. The plugin writes nothing unless both the checkbox is on and the project ID is filled in. Check the page source for window.axeptioSettings. If it is missing, the settings are incomplete or a page cache is serving an older copy.

The settings object is there but no banner appears. The SDK is loading and rejecting the configuration. The usual cause is a project ID that does not match a published project, or a cookies version that no longer exists in the project. Reopen the cookies version field: if it offers a dropdown, the project was found and you can pick a valid version from it.

The cookies version list will not load in wp-admin. The list is fetched by your browser, not by your server, so an ad blocker, a strict content security policy or an offline admin session will stop it. Type the version name into the text box the field falls back to and the setup works exactly the same.

Two consent defaults show up in the consent overview. Something other than GTM4WP is sending one. The plugin suppresses its own as soon as consent mode v2 is enabled here, so look at your container and at any other consent plugin still active.

The gtm4wp.axeptioConsentUpdate event never fires. It depends on the SDK loading and reaching its cookies:complete event. If the banner does not appear, fix that first, since the event comes from Axeptio and not from the plugin.