The symptom

The cookie banner is in place, the CMP shows a clean consent rate, and Google Ads and GA4 both stop firing the moment a visitor declines, exactly as they should. Then someone checks the browser's cookie jar on a fresh, fully-declined session and finds __kla_id sitting there anyway, already holding an anonymous id for a visitor who never agreed to anything.

The instinct is to assume this is a Klaviyo problem, or a Klaviyo settings toggle nobody found yet. It is neither. Klaviyo's onsite tracking snippet was, in almost every agency setup, installed inside the same Google Tag Manager container as the Google tags, and the assumption that "the container respects consent now" quietly stopped being true the moment a non-Google tag was added to it.

Search "klaviyo consent mode" and most of what comes back is Klaviyo's own help center explaining email and SMS opt-in language, or a CMP vendor selling a plugin. Neither answers the actual question an agency has: does Klaviyo check Google's consent signals on its own, or does someone have to wire that by hand.

Why it happens

Onsite tracking and email consent are two different fields, and only one of them is documented for GDPR

Klaviyo's own compliance guidance is thorough on one thing and silent on another. Its GDPR-compliant consent article covers subscribe forms, pre-ticked boxes, and granular channel consent in detail, but it does not mention the tracking snippet, Google Tag Manager, or a cookie banner anywhere. A visitor ticking "email me" at checkout has agreed to receive email. That checkbox says nothing about whether the __kla_id cookie may be set on every page they visit beforehand, because that is a separate consent question under a separate law.

Klaviyo's own cookie documentation is explicit that the tracking cookie is not exempt from that question: it describes the cookie as collecting "behavioral data that is not required for your site to function." Source: Klaviyo Help Center. Under the EU's actual cookie law, the ePrivacy Directive, storing anything in a visitor's browser needs prior consent unless it is "strictly necessary in order for the provider of an information society service explicitly requested by the subscriber or user to provide the service," per Article 5(3) of Directive 2002/58/EC, as amended. Klaviyo's own description of the cookie places it outside that exemption.

How the tag actually gets installed, and what that install type means for consent

Klaviyo's own installation guide for onsite tracking has agencies build the snippet as a Custom HTML tag inside Google Tag Manager, triggered on every page for the general "Active on Site" event and again on product pages for "Viewed Product." That is a deliberate, documented Klaviyo recommendation, not a shortcut an agency invented.

Google's own documentation on how consent mode works inside Tag Manager draws a sharp line here. Tags with what Google calls built-in consent checks, meaning the tag template itself changes behaviour based on the visitor's consent state, exist for "specific Google tags" such as Google Ads, Google Analytics and Floodlight. Everything else, in Google's own words, has "no built-in consent," and for those tags "additional consent is the only consent mechanism available, and without it, the tag fires unconditionally regardless of the visitor's consent choice." Source: Google Tag Manager Help, Tag Manager consent mode support. A Custom HTML tag, which is exactly what Klaviyo's own instructions ask for, is squarely in that second group.

A CMP that correctly publishes ad_storage, analytics_storage, ad_user_data and ad_personalization into the data layer, feeding a container where the Google tags are wired up correctly, has done nothing to the Klaviyo tag unless someone has separately opened that tag's own Additional Consent Checks setting and required one of those signals before it fires. Nothing in the CMP, the banner, or Klaviyo's dashboard does that step automatically. It is a per-tag setting inside the Tag Manager workspace, and it has to be set once, by hand, on that tag specifically.

Klaviyo does have an opt-out cookie, it just is not wired to any of this on its own

Klaviyo documents a manual override: setting document.cookie = "__kla_off=true" stops the tracking script from running. Source: Klaviyo Help Center. That is a hook a developer can call, not a listener that checks Google's consent state on its own. Someone still has to write the line that fires it when the CMP reports a denial, or gate the whole tag with GTM's own consent setting instead. On Shopify stores specifically, Klaviyo's integration with Shopify's own Customer Privacy API changes this picture again, blocking onsite events for EU, EEA, UK and Swiss visitors without consent, but that behaviour is specific to the Shopify integration and does not apply to a standalone GTM install on a non-Shopify site.

What good looks like

Treat every non-Google tag in the container the same way you would treat a Google tag, not as an exception. Klaviyo is the one this article is about because of the search demand behind it, but the same gap exists for any Custom HTML tag, a chat widget, a heatmap script, a review platform's tracking pixel, sitting in the same container and assumed to be covered by consent mode when it structurally cannot be.

The fix is small and specific: open the Klaviyo tag's own settings in Tag Manager, set Additional Consent Checks to "Require additional consent," and require the same consent type the banner already collects for behavioural tracking. That turns an assumption into a configuration that can be tested, by loading the site, declining the banner, and confirming __kla_id never gets set.

This is exactly the kind of gap that survives a surface-level consent audit, because the Google tags all look correctly gated and nobody thinks to check the tag that is not from Google. Closing it for every tag in a client's container, not only the obvious ones, is part of what Archon Consent wires when it sets up a client's consent mapping.

FAQ

Does Klaviyo support Google consent mode natively?

No. Klaviyo has no built-in integration that reads Google's consent signals. Its onsite tracking snippet is typically installed as a Custom HTML tag in Google Tag Manager, and Google's own documentation confirms that tag type has no built-in consent logic. Someone has to configure the consent requirement on that specific tag for it to respect a visitor's banner choice.

If our CMP already sends consent signals into the data layer, is Klaviyo automatically covered?

No. The CMP publishing ad_storage, analytics_storage, ad_user_data and ad_personalization into the data layer only affects tags that either have built-in consent checks or have been manually configured with an Additional Consent Check. A Klaviyo Custom HTML tag with no consent setting fires regardless.

Does the __kla_off cookie solve this automatically?

Not on its own. __kla_off is a manual switch Klaviyo documents for developers to call in code. It does not listen to a visitor's consent choice by itself, someone has to write the logic that sets it when the CMP reports a denial, or gate the tag directly in Tag Manager instead, which is the more reliable route since it does not depend on custom code surviving a future site rebuild.

Is this different on Shopify?

Yes, partially. Klaviyo's Shopify integration can block onsite tracking for EU, EEA, UK and Swiss visitors without consent, through Shopify's own Customer Privacy API. That behaviour is specific to the Shopify integration path and does not apply if Klaviyo's tracking is installed through a standalone Google Tag Manager container, which is the more common setup for non-Shopify sites and for agencies managing many client accounts on different platforms.

Does gating the tag on consent break Klaviyo's marketing automations?

No. Email and SMS sending is driven by the subscriber's channel consent on their Klaviyo profile, a separate field from the onsite tracking cookie. Gating the browser-side tracking tag changes what browsing behaviour Klaviyo can attribute to an anonymous or newly identified visitor before consent, it does not touch whether an already-subscribed contact receives email or SMS.

If you cannot currently say which non-Google tags in a client's container are actually gated by consent, a free tracking audit checks the container tag by tag.