Custom HTML advertising tags in GTM have no built-in consent awareness. To fire a pixel, remarketing script, or visitor tracker only after a user accepts advertising cookies in CookieYes, you need a trigger-based setup that listens for explicit consent events, not the default “All Pages + Once per page” combination, which silently fails after a blocked firing attempt.
Table of Contents
Key takeaways
- CookieYes writes user consent choices to the
cookieyes-consentcookie; GTM reads it via a 1st Party Cookie variable - The correct trigger is a Custom Event on
cookie_consent_updatewith a condition checking thatadvertisement:yesappears in the cookie value - Combining “All Pages” with “Once per page” causes GTM to count a blocked page-load attempt as the firing slot, the tag never fires after the user clicks Accept
- Require
ad_storage,ad_user_data, andadpersonalizationin the tag’s Advanced Consent Settings as a second check layer - This approach applies to Custom HTML tags only; native Google Ads and GA4 tags have their own Consent Mode behavior
Why Custom HTML Tags Don’t Respect Consent Mode on Their Own
Custom HTML tags in GTM do not read Google Consent Mode signals. When you paste a Meta Pixel snippet, a LinkedIn Insight Tag, or any third-party remarketing script into a Custom HTML tag, that tag fires whenever its trigger fires. It has no awareness of adstorage or aduser_data states, those signals only affect native Google tags (Google Ads conversions, GA4) automatically.
According to Google’s Consent Mode documentation, consent signals like ad_storage and ad_user_data natively govern the behavior of Google’s own tags only. Third-party scripts pasted into Custom HTML tags sit outside this control layer; they fire regardless of consent state unless the trigger itself prevents it.
This is a meaningful distinction for any site operating under GDPR, CCPA, or similar frameworks. Third-party scripts added as Custom HTML can set advertising cookies the moment they execute, so the trigger firing before consent is granted is the compliance risk, not just a tracking accuracy issue.
The “Once per page” firing bug
When you add “All Pages” as a trigger and set firing options to “Once per page,” GTM evaluates the tag on every page load event. If CookieYes fires its Consent Initialization before the user has accepted, GTM may attempt to fire the tag at that point. The consent checks block it from actually running, but GTM still registers the evaluation as the single allowed firing for that page session.
The result: the user opens the banner, clicks “Accept All,” CookieYes pushes a consent update to the dataLayer, and nothing happens. The advertising script stays silent for the entire session because GTM already used the “Once per page” slot during the blocked page-load attempt.
This is not a bug that appears consistently in testing. In GTM Preview mode, the behavior can look correct if you load the preview with cookies already cleared and accept consent before any tags fire. It surfaces in production when the CookieYes banner loads and initializes before other GTM containers have had a chance to process the event queue.
Why using only a custom trigger solves it
If the tag’s only trigger is the cookie_consent_update Custom Event, GTM never evaluates the tag during page load at all. No blocked attempt, no wasted firing slot. The tag is considered for firing only when the custom event fires, which happens when CookieYes pushes a consent state change to the dataLayer. At that point, if the cookie condition and consent checks both pass, the tag executes cleanly.
Step 1: Configure CookieYes for Google Consent Mode v2
CookieYes must be set up to both initialize Google Consent Mode defaults before other tags fire, and push dataLayer events when the user’s consent state changes.
In the CookieYes dashboard, enable Google Consent Mode v2 support. This setting makes CookieYes inject the gtag('consent', 'default', {...}) call before the GTM container loads, setting default values for all consent signals.
Set the default consent state for advertising signals to denied:
ad_storage: deniedad_user_data: deniedad_personalization: denied
When a user accepts the Advertisement category, CookieYes calls gtag('consent', 'update', {...}) and flips all three to granted. It also pushes the cookie_consent_update event to the dataLayer, that is the event your GTM trigger will listen for.
CookieYes CMP tag trigger in GTM
In GTM, the CookieYes CMP tag must fire on Consent Initialization – All Pages, not on the standard “All Pages” trigger. This distinction matters: Consent Initialization fires before any other trigger type, ensuring CookieYes sets defaults before any tag can execute on page load. If you use the standard “All Pages” trigger for the CookieYes tag, consent defaults may arrive too late, and other tags could fire before GCM signals are set.
The cookieyes-consent cookie
CookieYes stores the user’s full consent decision in a first-party cookie named cookieyes-consent. A typical accepted value looks like this:
consent:yes,analytics:yes,functional:yes,advertisement:yesA rejected or partially accepted state might look like:
consent:yes,analytics:no,functional:yes,advertisement:noGTM reads this cookie string to evaluate whether the advertising condition is met.
Step 2: Create the GTM Variable
Create a new variable in GTM to read the cookieyes-consent cookie value. This variable is used in the trigger condition.
| Setting | Value |
|---|---|
| Variable type | 1st Party Cookie |
| Variable name | CookieYes Consent |
| Cookie name | cookieyes-consent |
| URI-decode cookie | No |
The variable returns the full cookie string as a plain text value. No JavaScript processing is required, the trigger condition handles substring matching.
Step 3: Create the Custom Event Trigger
This trigger listens for the event that CookieYes pushes to the dataLayer on every consent state change: initial consent load, accept, reject, or granular category update.
| Setting | Value |
|---|---|
| Trigger type | Custom Event |
| Trigger name | CookieYes: Advertisement Granted |
| Event name | cookie_consent_update |
| Fire on | Some Custom Events |
| Condition variable | {{CookieYes Consent}} |
| Condition operator | contains |
| Condition value | advertisement:yes |
The condition value is exactly advertisement:yes. Do not include the word “contains” in the value field, that is the operator selected from the dropdown, not part of the string.
This trigger fires on any consent state change where the resulting cookie value includes advertisement:yes. If the user rejects advertising cookies, the cookie will contain advertisement:no, the condition fails, and the trigger does not fire.
Not sure what your GTM container is really doing?
The “Once per page” bug is one of dozens of silent failures we find in GTM setups: tags firing before consent, pixels that stopped firing months ago, and consent signals that never reach the tags they should control. Each one is either a compliance risk or lost conversion data.
Our WordPress website audit includes a full review of your GTM container, consent flow, and every tag’s firing behavior, with a prioritized fix list you can act on the same week.
Step 4: Configure the Advertising Tag
With the variable and trigger in place, create or update your advertising tag.
Tag type and firing settings
Set the tag type to Custom HTML and paste your advertising script in the body. Under Advanced Settings, set Tag firing options to Once per page.
For the trigger, assign only the CookieYes: Advertisement Granted trigger. Do not add “All Pages” or any page-view trigger alongside it. The “Once per page” option here is safe because the trigger itself only fires after confirmed consent, there is no page-load evaluation to consume the firing slot prematurely.
Advanced Consent Settings
In the tag configuration, open Consent Settings and select “Require additional consent for tag to fire.” Add the following consent types:
ad_storagead_user_dataad_personalization
This creates a second verification layer. Even if the trigger fires (cookie condition met), the tag executes only if all three consent signals in Google Consent Mode are set to granted. If the user’s browser has an existing session where signals are still denied, or if CookieYes updates the cookie but GCM signals lag, this check prevents a premature execution.
Why both layers are necessary
The trigger condition reads the CookieYes cookie (a string value controlled by the CMP). The consent checks read the Google Consent Mode signals, a dataLayer state controlled by the GCM API. Both need to reflect that the user has accepted advertising. In most implementations they update simultaneously, but relying on only one leaves a window where the other might not yet have propagated.
If a user accepts advertising cookies, then explicitly revokes them later in the same session, the GCM signals drop back to denied. Even if the “Once per page” slot has not been used, the tag will not fire because the consent check fails.
Step 5: Test in GTM Preview
Testing requires verifying two flows: the accept flow and the reject flow.
| Step | Action | Expected result |
|---|---|---|
| 1 | Clear site cookies, open GTM Preview | No advertising tag in Tags Fired on page load |
| 2 | Load the page with the consent banner visible | cookie_consent_update fires; tag not in Tags Fired |
| 3 | Click “Reject All” | cookie_consent_update fires; tag absent from Tags Fired |
| 4 | Reload page; click “Accept All” | cookie_consent_update fires; open the event |
| 5 | Check Consent tab in GTM Preview | ad_storage, ad_userdata, ad_personalization show granted |
| 6 | Check Tags Fired in that event | Advertising tag appears here |
| 7 | Check browser Network tab | Pixel or script request visible |
| 8 | Repeat full flow with “Reject All” only | Tag absent from Network tab throughout |
Google’s official Consent Mode verification guide explains how to use the Consent tab in GTM Preview to confirm that adstorage, aduserdata, and adpersonalization updated to granted after user interaction.
Step 8 is the one most implementations skip. The tag not firing in step 6 is necessary; the tag not appearing in Network when you reject is the compliance requirement. Both must pass.
Important: This Does Not Apply to Native Google Tags
The setup described above is designed for Custom HTML tags containing third-party advertising scripts that have no native Consent Mode support.
Native Google Ads and GA4 tags behave differently. Under Advanced Consent Mode, native Google tags are permitted to fire before consent is given, they collect cookieless, modeled data and send limited pings without setting advertising cookies. This is intentional behavior that supports conversion modeling and helps recover lost attribution data.
Applying the cookie_consent_update trigger to native Google Ads or GA4 tags would suppress their pre-consent data collection entirely, switching them into Basic Consent Mode behavior. Whether that is acceptable depends on your measurement strategy, but it is a different trade-off from simply ensuring a third-party pixel fires at the right time.
If your site runs a mix of native Google tags and Custom HTML third-party scripts, configure them separately. Native tags can use standard page-view triggers with consent checks handled automatically by GCM. Custom HTML tags use the trigger setup described here.
FAQ
Does this setup work for any advertising pixel?
Yes. The configuration is platform-agnostic. It works for Meta Pixel, LinkedIn Insight Tag, Pinterest Tag, TikTok Pixel, or any proprietary remarketing script added as Custom HTML. The trigger and consent checks operate entirely at the GTM layer, the specific script content does not matter.
What if the cookie_consent_update event never appears in GTM Preview?
Check two things. First, confirm that the CookieYes CMP tag in GTM is set to fire on Consent Initialization – All Pages, not a standard page view trigger. Second, verify in the CookieYes dashboard that Google Consent Mode is enabled. If the event is missing from the Preview event stream entirely, the CookieYes tag is either absent from the container, firing on the wrong trigger, or the GCM integration is disabled in the CookieYes settings.
Should I apply this to Google Ads and GA4 tags?
No. Native Google Ads and GA4 tags have built-in Consent Mode handling. Restricting them to the cookie_consent_update trigger would disable their pre-consent cookieless pings, which is usually not the intended outcome. Configure native Google tags with standard page-view triggers and let GCM manage their consent behavior.
What is the difference between Basic and Advanced Consent Mode?
In Basic Consent Mode, tags do not fire before the user grants consent, there is no data collection before the banner is interacted with. In Advanced Consent Mode, native Google tags fire before consent but collect only anonymized, cookieless data, then switch to full tracking after consent is granted. Custom HTML tags always operate in Basic mode regardless of your GCM configuration: they fire only when triggered, and the trigger in this guide fires only after consent.
Why does the advertisement category specifically control these consent signals?
CookieYes maps its cookie categories to GCM consent types. The Advertisement category maps to ad_storage, ad_user_data, and ad_personalization. When a user accepts Advertisement, CookieYes updates all three signals to granted. Functional, Analytics, and other categories map to different signals (functionality_storage, analytics_storage) and do not affect advertising tag firing.
Wrap-up
Loading advertising Custom HTML scripts reliably after CookieYes consent requires three components working together: a CookieYes CMP tag firing on Consent Initialization, a Custom Event trigger reading the cookieyes-consent cookie for advertisement:yes, and explicit consent requirements for ad_storage, ad_user_data, and ad_personalization on the tag itself.
The most common failure is combining “All Pages” with “Once per page”, which hands GTM a firing slot during the blocked page-load attempt and leaves nothing for when the user actually consents. Removing “All Pages” from the trigger entirely is what makes the setup reliable.
If you manage WordPress sites with complex tag configurations, compliance requirements, or performance-sensitive GTM setups, our WordPress support and maintenance team handles these integrations as part of ongoing site management. A WordPress website audit can also surface hidden consent or tracking gaps across your entire GTM container. Talk to IMADO engineers about what your site needs.
