How to QA Your Consent Banner with Google Tag Manager (Step-by-Step)

Hello everyone! Welcome to this week’s edition of Analytics with Ahmed. Today, we’re tackling a common oversight in web analytics: making sure your cookie consent banner actually respects user choices. Many marketers slap a consent banner on their site and call it a day – only to discover later that it might not be working as intended. In fact, I recently audited a Shopify store that thought it was compliant, but when I clicked “Reject All,” the Facebook Pixel still fired 😬. If your banner isn’t behaving, you risk privacy non-compliance, data loss, and tags firing when they shouldn’t. Let’s prevent that!

In this guide, I’ll show you how to QA (Quality Assurance) your consent banner using Google Tag Manager (GTM) and Google Consent Mode. We’ll walk through a step-by-step process to validate that your banner is truly honoring user consent decisions. By the end, you’ll be able to catch issues (like the one in the Shopify example) and ensure your website tags only fire when they’re supposed to. Let’s dive in!

Why Should You QA Your Consent Banner?

Setting up a cookie consent banner is not just a “set and forget” task. It’s crucial to test and verify that it works properly, because if it doesn’t, a lot can go wrong:

• Non-Compliance Risks: If your banner fails to stop tracking after a user opts out (e.g. fires a pixel even after “Reject All”), you could be violating privacy laws (GDPR, ePrivacy, CCPA, etc.). This can lead to legal trouble or fines, not to mention a loss of user trust.
• Data Integrity Issues: A mis-configured banner might block analytics even for users who did consent, or vice versa. Either scenario hurts your data. You might either be losing valuable analytics data (if tags are unnecessarily blocked) or collecting data improperly (if tags fire without consent).
• Tag Firing Problems: Without proper QA, you might not realize that some marketing tags (like Facebook Pixel, Google Analytics, etc.) are firing when they shouldn’t, or not firing when they should. This can break marketing attribution and skew your metrics.

Bottom line: Validating your consent banner’s behavior ensures you stay compliant and get accurate data. Now, let’s see how GTM and Google Consent Mode can help with this.

Tools in Play: Google Tag Manager + Google Consent Mode

Before we get to the steps, here’s a quick primer on what we’re using:

• Google Tag Manager (GTM): A tag management system that loads your tracking tags. GTM has a Preview Mode (Tag Assistant) which lets us see what tags and events fire on your site in real time. We’ll use this to observe consent signals and tag behavior.
• Google Consent Mode: A framework that allows tags to adjust their behavior based on user consent. It defines various consent categories (also called “consent types”) such as ad_storage (ads/marketing cookies), analytics_storage (analytics cookies), functional_storage, personalization_storage, etc. Each category can be “granted” or “denied” for a user. Consent Management Platforms (CMPs) that integrate with GTM will communicate these statuses to GTM. In short: Consent Mode is what bridges your banner choices with tag behavior.

When a user first lands on your site, GTM will record a default consent state for each category (usually configured by you or your CMP – e.g. maybe everything is denied until consent given, or sometimes everything granted until opt-out, depending on your approach). If the user then interacts with the banner (accepts, rejects, or sets preferences), GTM receives a consent update event with the new statuses. We’ll leverage these events to verify that the banner is working correctly.

Alright, let’s get into the step-by-step QA process.

Step-by-Step: How to QA Your Consent Banner Behavior

Following these steps, you can confirm if your consent banner is properly configured and find any gaps.

Step 1: Open GTM Preview and Check the Default Consent State First, activate Preview Mode in Google Tag Manager for your website. (In GTM, click the Preview button and enter your site URL – this will open your site with the Tag Assistant debug pane connected.)

Once your site is open in preview mode, do not interact with the consent banner yet. In the Tag Assistant window, look at the event stream on the left. Find the event called “Consent Default”. Click that event, then click the Consent tab in the right panel.

You should see a list of consent categories (like ad_storage, analytics_storage, etc.) and whether each is granted or denied by default. This default reflects what your banner/CMP has set for a new user. For example, some setups default everything to “granted” until the user opts out, while privacy-first setups might default to “denied” until the user opts in. Verify that this default state matches your intended policy. If your legal team said no tracking unless opted in, you’d expect to see all categories as “denied” by default. On the other hand, if you’re using an opt-out approach, you might see “granted” by default (which means you track until the user says stop). It’s important to know what baseline you’re starting from.

Why this matters: If the default state is wrong (say, you intended no cookies without consent but see “granted”), you need to adjust your banner/CMP configuration. Conversely, if everything is denied by default, you need to ensure that’ll switch to granted upon consent later.

Step 2: Interact with the Banner and Observe Consent Update Events Now it’s time to test the banner itself. On your website, use the banner’s options to give or withhold consent and see how GTM reacts:

• Test a full reject: For instance, click “Reject All” on the banner (or go into preferences and turn all consent toggles off, then save). This simulates a user opting out of all optional cookies.
• As soon as you do this, look back at the GTM Tag Assistant. You should see a new event appear in the event stream, often labeled “Consent Update”. Click the Consent Update event and then the Consent tab to inspect the new values. Ideally, if you rejected all, you’ll now see each relevant category marked as denied.
• Test a partial consent: Next, try allowing some categories but not others. For example, in many banners you might enable only “Functional” cookies or only “Performance/Analytics” cookies while rejecting others. Do this and check Tag Assistant again for another Consent Update event. In the Consent tab, you should see that only the categories corresponding to what you allowed are granted, with all others denied.

This step is all about verifying the banner is communicating user choices correctly. The GTM preview is your window into that communication. If you reject all and yet see some categories still “granted,” that’s a red flag – it means the banner or GTM integration isn’t properly denying those consents. If you allow one category, make sure the right one flips to “granted” in GTM.

Step 3: Map Banner Categories to GTM’s Consent Categories Every Consent Management Platform might label cookie categories a bit differently in the banner UI (e.g. “Marketing cookies”, “Analytics cookies”, “Functional cookies”, etc.), but under the hood they need to tie into those standard consent categories (ad_storage, analytics_storage, etc. from Google Consent Mode). It’s important to map which UI option corresponds to which technical category, so you can be sure you’re testing the right things.

How to map them? Use the partial consent test from Step 2 in a systematic way:

• Toggle one category at a time in your banner preferences, and observe which consent category in GTM turns to granted. For example, disable everything except “Performance Cookies” (or whatever one category the banner lets you enable individually), then save and check the consent state in GTM. You might find that enabling “Performance Cookies” in the banner results in analytics_storage = granted (and all others denied). That tells you “Performance” in the banner maps to Analytics storage in GTM’s terms.
• Likewise, try enabling just “Functional Cookies” and see perhaps functionality_storage (and maybe personalization_storage) turn to granted. Each CMP is a bit different; some bundle multiple technical categories under one user-facing label. The key is to identify these relationships.

Doing this quick exercise (it takes a minute or two) will give you a clear mapping of banner choices -> consent mode categories. This ensures you know, for instance, that “Marketing cookies” toggle controls ad_storage (and maybe ad_personalization) behind the scenes, or that “Analytics cookies” controls analytics_storage, etc. With this knowledge, you’ll better understand the results you see in the GTM preview and can verify nothing is overlooked.

Step 4: Verify Consent Persistence Across Pages A good consent setup should remember the user’s choice as they navigate the site. Once a visitor selects their preferences, those should persist (usually via a cookie) so that they don’t have to keep seeing the banner on every page, and so that tags remain consistently allowed or blocked according to their choice.

To test this, navigate to a new page on your website (while keeping the GTM preview active). For example, click on a different product page or a section of your site. In the Tag Assistant event stream, check the events on this new page view:

• You will likely see another Default event on the new page load. Inspect its Consent tab. It should not reset to the original defaults if the user has already made a choice. Instead, it should reflect the user’s last given consent. In practice, many CMPs will automatically apply the stored consent on each page load (sometimes you’ll see a quick Consent Update event on page load as it applies the preferences).
• Confirm that the consent statuses on this new page match what you set on the previous page. For instance, if you had declined all in Step 2, the new page’s consent state should still show all categories denied (and you ideally wouldn’t see the banner reappear). If you had allowed some categories, those should remain granted on the new page.

This test ensures that consent isn’t just working on the first page, but is persisted site-wide. If you discover that each page load reverts to default (e.g. the banner pops up again or GTM shows default consent each time), then your banner might not be storing consent properly (which could annoy users and lead to inconsistent tracking). In a proper setup, the consent is remembered and consistent throughout the user’s session (and often on subsequent visits, until the user changes it or the consent expires).

Step 5: Ensure Tags Obey Consent – Use Tag-Level Consent Settings Now that we’ve confirmed the banner sends the correct signals, we need to verify that your tags (pixels, analytics, etc.) actually listen to those signals. This is where Google Tag Manager’s consent integration is critical. Even if the consent status says “denied,” your tags will only be blocked if they’re configured to respect that status.

For each tag in GTM that deals with cookies or tracking, you should configure its consent settings:

1. In GTM, go to your Tags list and edit a tag (for example, your Facebook Pixel tag or Google Analytics tag).
2. Click on Advanced Settings, then find Consent Settings. Enable the option that says something like “Require additional consent for tag to fire” (as opposed to “No additional consent required” which is the default for old tags).
3. In the consent requirements, add the relevant consent categories that this tag needs. For instance:
4. Save and publish your GTM container changes after updating consent settings for all relevant tags (GTM also has a Consent Overview screen to help manage this in bulk).

After configuring tag-level consent rules, it’s time to test them in action using Preview Mode again:

• With GTM preview, simulate a user scenario where consent is denied for certain categories. For example, decline all or at least the category that a particular tag requires.
• Trigger the events that would normally fire your tags. For instance, if you have a Facebook Pixel tag that fires on an “Add to Cart” event, go ahead and perform an add-to-cart on your site while in preview.
• Now look in the GTM Tag Assistant. You should see that the tag attempted to fire (the trigger condition was met), but it was blocked by consent. In the debug panel’s summary for that event (e.g., the Add to Cart event), your tag will appear under a section like “Tags blocked by consent settings” (instead of the usual “Tags fired”). This is exactly what we want – GTM is preventing the tag from actually running because the user didn’t consent.

On the flip side, if the user had given consent for that category, the tag would fire normally. You can test that too: reset the consent (e.g., accept all cookies) and redo the action, and verify the tag now fires and is listed under “Tags Fired”.

By checking a denied-consent scenario vs. granted-consent scenario, you ensure that your tags behave correctly in both cases. Any tag that still fires even when its consent is denied indicates a configuration problem:

• Maybe you forgot to set its consent settings in GTM.
• Or perhaps the tag isn’t managed via GTM (e.g., hard-coded on the site) – those would require manual handling or a CMP that blocks them.
• If using Shopify or other platforms that inject tags, double-check those as well, as platform-integrated pixels might bypass GTM if not configured properly.

This step is crucial – it’s where you catch things like that Facebook Pixel firing on “Reject All.” Once you’ve done this, you’ll have confidence that no means no (tags are truly blocked when a user declines consent), and yes means yes (users who consent get the full tracking experience you intend).

Wrapping Up: Test Your Setup & Stay Compliant

Congratulations! By following the steps above, you’ve effectively performed a QA of your consent banner implementation. You’ve checked the default state, validated consent changes on interaction, mapped the consent categories, verified persistence, and ensured your tags obey the rules. This thorough approach helps you catch misconfigurations before they become big problems.

A few final pointers:

• Always test after changes: If you update your consent tool or add new tags to your site, run through these tests again. It’s a good practice to include consent banner QA in your deployment checklists.
• Consult your legal team: This guide is not legal advice. It’s about the technical implementation. Always work with your legal advisors to determine what your default consent state should be and which cookies are allowed to run by default. Different jurisdictions have different requirements, and your banner should be configured in line with those. Our job as analytics folks is to make sure the tech does what the policy says – but the policy (opt-in vs opt-out, categories, etc.) should come from legal or compliance experts.
• User experience matters: A compliant banner that annoys users (for example, by popping up on every single page due to not remembering consent) is not ideal. Make sure your banner is not only working behind the scenes, but also providing a good UX (e.g., not overly interruptive once a choice is made, and easy to revisit if the user wants to change preferences).

Lastly, if you want a more visual walkthrough of this whole process, I’ve got you covered – I’ve put together a video demonstration where I go through these steps on a live site.

Now it’s your turn: Go ahead and QA your own consent banner setup. Fire up GTM Preview and see what happens on your site. You might be surprised by what you find. Hopefully, everything works perfectly – but if not, now you know how to fix it. By ensuring your tags respect user consent, you’re protecting your visitors’ privacy and your data quality.

Thanks for reading this week’s newsletter! If you found this helpful, feel free to subscribe for more tips and tutorials, and don’t hesitate to leave a comment with your experiences or questions. Did you catch any issues when testing your consent banner? I’d love to hear about it. And of course, share this with others who might find it useful – let’s help everyone make the web a bit more privacy-friendly.

Until next time – happy analyzing! 🚀

Ahmed

#GoogleTagManager #GoogleConsentMode #GTM #GDPR #WebAnalytics #AnalyticsWithAhmed #DigitalMarketing #ShopifyCompliance