CookieYes + GTM4WP – How to setup?

CookieYes announces consent choices to the page through its own browser events. Google Tag Manager cannot listen for those directly, since a Custom Event trigger only reacts to the data layer. The CookieYes bridge in GTM4WP closes that gap: it listens for the CookieYes events and republishes them as a data layer event your container can trigger on.

This feature is new in GTM4WP 2.0.0. It is marked experimental and is off by default.

Before you start

One prerequisite decides whether this feature can work at all, and it has nothing to do with GTM4WP. CookieYes documents that these event listeners do not work with the CookieYes WordPress plugin unless that plugin is connected to the CookieYes web app. Connected, the events fire and the bridge works. Not connected, no event is ever dispatched, so the bridge sits there and nothing reaches the data layer.

If you are not sure which state your site is in, check the CookieYes plugin screen for a connected account before you spend time on the container setup.

Turning the bridge on

Open the plugin settings, go to the Consent mode & consent tools section and the CookieYes group, then enable CookieYes consent bridge. There is nothing else to configure.

The bridge adds a few lines of JavaScript to the block GTM4WP already writes at the top of the page head. It sends no request anywhere, it stores nothing, and it reads the consent payload out of the browser event rather than from the server, so nothing about the visitor passes through WordPress.

What arrives in the data layer

The bridge listens for the two events CookieYes documents, and pushes a cookie_consent_update event for each of them. That is the same event name the WebToffee integration uses, so a container built for one recognizes the other.

The payload under consent_data is whatever CookieYes put in the event. The two events do not carry the same shape, so a variable built for one of them reads nothing from the other, and any variable you build has to handle both.

When the visitor makes a choice

CookieYes dispatches cookieyes_consent_update when the visitor interacts with the banner. Its payload is two lists of category names:

dataLayer.push({
  event: "cookie_consent_update",
  consent_data: {
    accepted: ["necessary", "analytics", "advertisement"],
    rejected: ["functional", "performance", "other"]
  }
});

When a stored choice is found

CookieYes dispatches cookieyes_banner_load on every page load. The bridge ignores it unless isUserActionCompleted is true, so a visitor who has not decided yet produces no event. When a stored choice is found, the payload is an object with one boolean per category:

dataLayer.push({
  event: "cookie_consent_update",
  consent_data: {
    activeLaw: "gdpr",
    categories: {
      necessary: true,
      functional: false,
      analytics: false,
      performance: false,
      advertisement: false
    },
    isUserActionCompleted: true,
    consentID: "bFl2eFJBN05VS21WNWk5enpRNTNEZ3hxR0dDc3VmcFM",
    languageCode: "en"
  }
});

Both shapes come from CookieYes unchanged. The category names are the ones CookieYes uses internally, which are necessary, functional, analytics, performance and advertisement. Renaming a category in the CookieYes interface changes what the visitor reads on the banner, not what arrives here.

Setting up Google Tag Manager

Because the two payloads differ, a variable that has to work on both a first visit and a return visit needs to look in both places. The simplest way to do that is one Custom JavaScript variable per consent category:

function() {
  var data = {{DLV - consent_data}} || {};

  // Return visit: cookieyes_banner_load carries a categories object.
  if (data.categories) {
    return data.categories.analytics ? "granted" : "denied";
  }

  // The visitor has just chosen: cookieyes_consent_update carries lists.
  if (data.accepted) {
    return data.accepted.indexOf("analytics") > -1 ? "granted" : "denied";
  }

  return "denied";
}

Create a Data Layer Variable named DLV – consent_data pointing at the key consent_data, then one copy of the variable above per category, replacing analytics with the category you need. Returning the words granted and denied means the result can be handed straight to a consent mode tag. Defaulting to denied at the end matters: an unexpected payload should never read as consent.

From there the setup is the generic one:

1. Create a Custom Event trigger for the event name cookie_consent_update.
2. Add the Consent Mode (Google tags) tag from the community template gallery, set its command to update, and map each signal to the matching variable.
3. Fire that tag on the trigger from step 1.
4. Keep the plugin’s Google Consent Mode option on, with every signal denied, so that a default exists before CookieYes has said anything. The bridge provides the update only. See how to set up Google consent mode.

If CookieYes is already sending consent mode signals to Google through its own Google consent mode feature, you do not need the tag from step 2 and you should turn the plugin’s consent mode default off. In that case the bridge is still useful, but for a different purpose: it gives you an event to sequence your non-Google tags on.

What the bridge does not do

The bridge reports consent. It does not hold anything back while consent is missing. GTM4WP pushes the events belonging to its other features, the e-commerce events in particular, when they happen rather than when consent arrives, so on a first visit a view_item event can reach the data layer before the visitor has touched the banner.

That ordering is not a problem to solve with buffering. Consent mode is what stops a tag from acting on data it may not use, and it does that regardless of the order in which things reached the data layer. Deferring the pushes instead would only move the problem and would lose events for visitors who never answer the banner.

Troubleshooting

No cookie_consent_update event ever appears. Start with the web app connection described at the top of this page, since that is the most common cause. After that, open the browser console and run the snippet below on a page where the banner is present. If it never logs anything, CookieYes is not dispatching the events and the problem is upstream of GTM4WP.

document.addEventListener("cookieyes_banner_load", function (e) {
  console.log("banner_load", e.detail);
});
document.addEventListener("cookieyes_consent_update", function (e) {
  console.log("consent_update", e.detail);
});

The event fires on a return visit but not on the first choice, or the other way round. That is the two payload shapes. Check that your variable handles both, as in the example above.

Nothing happens on a page load even though a choice was made earlier. The bridge deliberately skips the banner load event while isUserActionCompleted is false. Confirm the value in the console snippet above.

The variable returns undefined in preview mode. Data layer variables are read at the moment the trigger fires. Make sure your consent mode tag fires on the cookie_consent_update trigger and not on a page view trigger, where consent_data does not exist yet.