Raw triggers vs. Trigger Groups vs. Additional Consent Checks

1

As we have quite many different setups for our agency-customer-sites (e.g. WP + Stape Plugin, Shopify + Stape App, Shopware 6 + 3rd Party Extension, Custom CMS + Custom Code Snippet from Stape, and many more), I am trying to get a clearer picture of how others structure triggers in their GTM setups, especially with consent tools like Cookiebot. A few questions:

  1. Where do you draw the line between wrapping a trigger (like page_view) in a Trigger Group (paired with a consent update event like Cookiebot’s cookie_consent_update) vs. firing directly on a raw trigger? Is it purely about page load vs. interaction events, or are there other cases where you’d reach for a TG?

  2. I am never using TGs for any GA4 tags as they have the build-in-consent. Is there any (serious) case when/where I should put a GA4 tag trigger in a TG?

  3. For interaction driven (AJAX) events (add_to_cart, add_to_wishlist, form_submit, and similar), does anyone still use a Trigger Group there, or is a raw trigger plus a tag level consent check considered enough in practice?

  4. On Additional Consent Checks vs. the built-in consent field on non GA4-tags like Stape DT, Facebook, TikTok, MS Ads, and so on: does anyone have a consistent way of testing which one actually blocks reliably, or a rule for when to prefer one over the other? Or should one always use TGs for page load Events here?

  5. More generally, how do you validate any of this beyond a quick preview check and/or a look in the network tab (or browser extensions like UET Tag Helper)?

Would appreciate hearing how others have set this up, or even something like a general guideline from the people at Stape at how to tackle this, thanks in advance :slight_smile:

2

Hi Gerald,

It’s worth noting first that the consent update dataLayer push is used to make sure that the updated consent status is available when a tag fires. For example, if a dataLayer event fires before the consent update, the consent status will still be denied, assuming your default consent state is set to denied.

  1. The page_view event, as well as pixel loading, should always be set to fire on the consent update dataLayer event, so that cookies are not set earlier, also considering what I mentioned in the previous paragraph. Trigger Groups should be used for interaction events, for example view_item + consent_update. It’s worth noting that if the event does not trigger a page/DOM reload, for example add_to_cart, you should not use a Trigger Group, because the consent update may have already fired for another Trigger Group and there will not be a new one.

  2. You’re right, Trigger Groups are generally not needed for GA4 tags because GA4 has built-in consent support. You can use the regular trigger and set “No additional consent required” for the tag.

  3. As I mentioned in point 1, for such events, there is no need to use Trigger Groups because by the time the event happens, the consent update has already fired.

  4. For all platforms except Google, you should add an Additional Consent Check, for example ad_storage, and use Trigger Groups where needed, because these platforms do not have their own built-in consent mechanism. There is also another option for server-side events: you can pass the consent status through the Data Tag to sGTM and configure consent handling for the server-side tags. However, overall, the result will be the same.

  5. You can check whether the setup is correct simply in GTM Preview mode. First, go through the flow with consent granted and make sure the tags are working. Then go through the flow again after rejecting consent and make sure the tags do not fire (except GA4, which will still send requests).

Here are a few articles that may also be helpful:
Google Consent Mode V2
Consent explained: practical implementation for web and server-side tracking
Cookie banner: all-in-one guide

3

Hi Alina,

Thanks a lot for the detailed answer, that clears up most of it.

I’ve also read through the consent webinar recap, the cookie banner guide, and the Consent Mode V2 article, but I do still have a few follow up questions on point 4, specifically around the reliability of Additional Consent Checks:

  1. Does “Additional Consent Check for all non-Google platforms” hold across the board, or have you seen individual platforms (Meta, TikTok, MS Ads, Pinterest, etc.) where even the Additional Consent Check didn’t block reliably in practice?

  2. Is there a documented Stape guideline somewhere, or is this more of an experience based recommendation? If it’s documented, would be great to get a link so we can reference it internally.

  3. You mentioned passing the consent status through the Data Tag to server-side GTM as an alternative, but noted the result would be the same either way. Are there situations where that server-side approach would still be preferable, for example with a large number of tags at once, or is the Additional Consent Check on the tag itself always equivalent?