Key Takeaways
- Klaviyo's own documentation states that "based on your Customer Privacy settings in Shopify, Klaviyo may not track onsite events for visitors to your Shopify store in the EU, EEA, UK and Switzerland, unless they have provided consent" — the gate is built into the integration, not bolted on by your consent tool.
- Five Shopify behavioural events sit behind that gate: Active on Site, Viewed Product, Viewed Collection, Submitted Search and Added to Cart. Viewed Product is the event browse-abandonment flows are built on.
- The EDPB's Guidelines 2/2023, adopted on 7 October 2024, place JavaScript-driven access inside Article 5(3) of the ePrivacy Directive at paragraph 33 — so the analysis does not turn on how you label the cookie.
- Klaviyo's own OneTrust guide warns that consent tools "can block cookies but also cause Klaviyo forms to stop working altogether, even forms that do not require tracking."
- Our position: the browse-abandonment revenue that disappears when the gate closes is not a bug to route around. It is a measurement of how much of that tracking was running without consent.
Introduction
Your Klaviyo dashboard has gone quiet. Active on Site events that ran all last quarter have flatlined, the browse-abandonment flow that reliably earned its keep is triggering for almost nobody, and nothing in your theme changed except the cookie banner you finally configured properly.
Nothing is broken. The gate you asked for is closed, and it is doing what you asked.
This is the least-documented consequence of consent-gating an email platform's onsite script, and it is where a lot of otherwise careful EU and UK merchants quietly reverse course. This guide covers what actually stops working when Klaviyo's tracking is genuinely gated on Shopify, what keeps working, how to configure the gate, and why un-gating the script to recover the numbers is the wrong fix.
This is informational content, not legal advice.
Does Klaviyo's Onsite Tracking Need Cookie Consent?
Yes, for EU, EEA, UK and Swiss visitors. Klaviyo's help documentation states that "based on your Customer Privacy settings in Shopify, Klaviyo may not track onsite events for visitors to your Shopify store in the EU, EEA, UK and Switzerland, unless they have provided consent." The gate itself is Shopify's Customer Privacy API.
Klaviyo wired that gate up in early 2023. In a product announcement dated 2 February 2023, Klaviyo's stephen.trumble wrote that "Klaviyo is now integrated with Shopify's Customer Privacy API so we can adhere to the Customer Privacy settings you have selected in your Shopify account," naming Active on Site, Viewed Product and Added to Cart as the affected events and the EU, EEA, UK and Switzerland as the affected regions.
That change did not arrive unprompted. On 16 December 2022 a merchant posting as THahn raised it on Klaviyo's community: "The Shopify Klaviyo App sets the __kla_id cookie before a user gives consent. If a user denies cookies and the Customer Privacy API is triggered to update the user's consent state, the Klaviyo App ignores the user's preference." Klaviyo escalated it to engineering, and on 10 February 2023 Klaviyo's David To closed the thread: "Klaviyo will adhere to the Customer Privacy settings you've enabled per the Shopify's Customer Privacy API." That is settled history rather than current behaviour — the point is that the gate exists because merchants asked for it.
Why the script is in scope before it sets a cookie
The obligation attaches to the script, not to the cookie. The EDPB Guidelines 2/2023 on the Technical Scope of Art. 5(3) of the ePrivacy Directive, Version 2.0, adopted on 7 October 2024, note at paragraph 1 that "Article 5(3) ePD does not exclusively apply to cookies, but also to 'similar technologies'."
The Board is more specific at paragraph 33: "Additional examples would include JavaScript code, where the accessing entity instructs the browser of the user to send asynchronous requests with the targeted information. Such access clearly falls within the scope of Article 5(3) ePD, as the accessing entity explicitly instructs the terminal equipment to send the information." At paragraph 51 it adds that for "dynamically constructed tracking pixels, it is the distribution of the applicative logic (usually a JavaScript code) that constitutes the instruction."
Our practical read of the EDPB's position: the popular workaround of reclassifying an email platform's cookies as strictly necessary so the banner stops blocking them does not survive this reasoning, because the reasoning never depended on the cookie. It is worth noting that Klaviyo's own OneTrust guide categorises all three __kla_id entries — on static-tracking.klaviyo.com, on static.klaviyo.com, and the first-party cookie on your own domain — as "Targeting Cookies". The vendor's own categorisation is not the one a "strictly necessary" label would need.
The same distinction runs through Shopify's own consent plumbing, which we cover in more depth in our guide to the Shopify web pixels consent deadline.
What Actually Breaks When the Gate Closes
Five behavioural events depend on the gate. Klaviyo lists them as "Active on Site," "Viewed Product," "Viewed Collection," "Submitted Search," and "Added to Cart" — the raw material for browse-abandonment, back-in-stock and onsite-behaviour segmentation. Without consent, for a visitor in the covered regions, Klaviyo documents that it may not record them.
| Surface | What Klaviyo documents | Where that leaves you |
|---|---|---|
| Active on Site | Occurs "whenever an identifiable browser visits your website" | No site-visit signal for that visitor |
| Viewed Product | Records "whenever an identifiable person views a product page on your website" | Browse-abandonment triggers do not fire |
| Viewed Collection, Submitted Search, Added to Cart | Named among the five Shopify behavioural events | Onsite-behaviour segments thin out |
__kla_id cookie | Tracks and identifies visitors "through an auto-generated ID"; lasts "up to 2 years" once identified, which Apple's Intelligent Tracking Prevention may cap to 7 days on Safari and iOS | No persistent identity carried across sessions |
| Embedded forms | Consent tools "can block cookies but also cause Klaviyo forms to stop working altogether, even forms that do not require tracking" | Sign-up forms may not render at all |
Read the first two rows closely, because the load-bearing word in both is identifiable. Even with consent granted, Klaviyo's Byrne C explained on 28 November 2025 that the pixel identifies a visitor only after a specific action, listing four: "Subscribing via a sign-up form; Clicking a link in a Klaviyo email that leads to your website; Submitting a Klaviyo form; Logged into your website, if you have installed custom tracking for logged in users." Consent opens the gate. It does not conjure an identity that was never established.
The forms problem Klaviyo documents itself
The most awkward row in that table is the last one, and Klaviyo puts it in writing. Its OneTrust configuration guide, last updated 6 August 2025, warns that these tools "can block cookies but also cause Klaviyo forms to stop working altogether, even forms that do not require tracking." A merchant who blocks the tracking domain to respect a refusal can lose the sign-up form that would have collected consent in the first place.
Merchants have been asking about exactly this for over a year. On 20 November 2024 a merchant posting as smeyvaert wrote: "When cookie consent is not given, the forms are not shown, so we need help on how to configure cookiebot to make klaviyo cookies necessary." A Klaviyo community manager replied on 26 November 2024 without a fix, referring the question to community champions. A second merchant confirmed the same problem on 30 January 2025. On 5 March 2026 — nearly sixteen months after the original post — a third merchant, MaxOnyourline, reported the answer they had received: "Same problem here. Answer from support: 'just start using OneTrust'." Klaviyo publishes a CMP-specific configuration guide for OneTrust; we found no equivalent Cookiebot guide when researching this article.
Our recommendation for merchants in that position: treat the forms question as a design decision to make before you deploy the gate, not a regression to discover afterwards. If your consent platform blocks at the domain level, expect the forms to travel with the tracking, and plan a consent-independent capture path — a native theme form, or a form served outside the blocked domain — rather than reclassifying the cookies to get the pop-up back. The trade-off is real: you will maintain a second form. It is smaller than the trade-off on the other side.
What Still Works Without Consent
More than the empty dashboard suggests. Transactional and order-driven data continues to reach Klaviyo through Shopify's server-side integration, which is a different mechanism from the browser script. Klaviyo's Byrne C put it plainly on 28 November 2025: "If a person places an order on Shopify, their information will be sent to Klaviyo, even if they didn't consent to marketing, and they'll be marked as 'Never Subscribed'."
Keep the two apart, because they raise different questions. The onsite script is terminal-equipment access under Article 5(3) ePD, which is the subject of the EDPB guidance above; the same analysis catches session replay and heatmap tools, which the CNIL's draft recommendation treats as trackers requiring consent because a publisher could run its service without them. An order record flowing server-to-server is not — it is an ordinary processing question about your lawful basis and your records, not about the visitor's browser.
Klaviyo's suggested handling for those profiles is segmentation: in its words, you can "ensure that 'Never Subscribed' profiles never receive emails from creating a segment" that excludes them. That is sound as far as it goes, and it is a send-side control rather than a lawful-basis answer. A profile arriving in your account without marketing consent still needs a documented reason to be there and a documented retention rule — which is a records problem, and the reason we treat proof of consent as a record, not a checkbox.
One more surface worth separating: in-email open tracking is a different pixel with its own consent analysis, covered in email tracking pixels and GDPR consent.
How to Configure Klaviyo Consent Gating on Shopify
Work in this order. Step 1 is first for a reason most guides skip.
- Enable Shopify's Customer Privacy API, and confirm it is actually available. Shopify's own reference states: "If the Customer Privacy API isn't available, then tracking and data emission can proceed." The gate fails open. An app embed that looks correctly installed will happily track a visitor who refused, if nothing told it a refusal existed.
- Check your region configuration. Shopify documents that "for regions that are configured to require consent, non-essential purposes are not allowed by default until consent is given. For other regions, the default behavior is to allow all processing purposes." Consent-first is conditional on that configuration, not a global default.
- Wire your consent platform to
setTrackingConsent, and only on a real interaction. Shopify is explicit: "Recording customer consent should only be done on a visitor interaction (such as a visitor accepting or declining via a cookie banner), and never done automatically on behalf of the visitor." - Test the refusal, not the acceptance. Decline in your banner, then run
window.Shopify.customerPrivacy.userCanBeTracked()in the browser console and confirm it returnsfalse. Note thatcurrentVisitorConsent()distinguishes three states —'yes','no', and an empty string for a visitor who has not yet decided — so an undecided visitor is not the same as a refusing one. - Decide the forms question deliberately, per the section above, before the gate goes live.
- Write down which consent purpose you mapped Klaviyo to and why. The mapping is a decision you will be asked to justify, and reconstructing it later from a CMP dashboard is harder than recording it now.
Step 4 is the one that catches real misconfigurations. In April 2024 a merchant reported that after a theme change, "none of the Active on site events etc. are being received by Klavyio" — while "the snippet shows up in the source code". The resolution, posted on 15 April 2024, came from Klaviyo support running exactly that console check — in the merchant's words, "the return was false, which leads to that Klaviyo will not track onsite events for the user, independent of the Klaviyo snippets and codes installed". That merchant had skipped their consent platform's step for enabling the Customer Privacy API. Their diagnosis was a specific consent field left false — take that as one merchant's instance rather than a documented rule about which purpose Klaviyo checks, because Klaviyo's own documentation says only "unless they have provided consent."
Common Mistakes
1. Quietly un-gating the script to recover the numbers. The worst of the five, and the most understandable. Browse-abandonment revenue drops, someone connects it to the banner change, and the tracking domain quietly moves back to the allowed list. Our position is that this reads the evidence exactly backwards: the drop is the measurement of how much of that tracking had been running without a lawful basis, so removing the gate does not recover revenue you were entitled to — it restores an exposure you had just finished closing. The honest lever is the consent rate, which is a banner-design and value-exchange problem, and a much more defensible place to spend the effort.
2. Reclassifying Klaviyo's cookies as strictly necessary. The tempting fix in the Cookiebot thread above — make the cookies necessary so nothing blocks them. Against the EDPB's paragraph 33 reasoning the label does not help, because the script is the thing in scope. Klaviyo's own OneTrust guide categorising __kla_id as a Targeting Cookie is an awkward document to have in the file if a regulator ever asks why yours is marked essential.
3. Assuming a visible app embed means tracking is running. The April 2024 thread is the counter-example: the snippet was in the page source and the events were not arriving. Presence in the DOM says nothing about the gate's state.
4. Moving the script into a tag manager and calling it solved. One merchant did exactly that in November 2025 to fire it only on consent, and reported that it "broke our Item Viewed metric tracking." Relocating a script changes what it can see. Test the events after the move, not just the consent behaviour.
5. Treating email-marketing consent as covering onsite tracking. They run through different machinery, which the platform behaviour makes visible: a shopper who refused marketing still lands in Klaviyo as a "Never Subscribed" profile via the order integration, while the onsite events are gated separately through Shopify's Customer Privacy API. Two mechanisms, two decisions, two records. The broader discipline of one lawful basis per processing activity is set out in our complete guide to GDPR compliance.
How PrivacyForge Helps
The hard part of consent-gating a marketing platform is rarely the switch. It is knowing which purpose you mapped each tool to, when that decision was made, and being able to show it — the thing nobody can reconstruct from a CMP dashboard six months later.
PrivacyForge's consent management records the decision alongside the consent: which purpose, which version of the notice, when, and what changed since. Its data mapping treats each connected app as its own processing activity with a named lawful basis, so a marketing platform pulling browsing behaviour is a documented flow rather than a line item someone remembers installing. None of that decides your purpose mapping for you. It makes the mapping you chose durable, and durable is what "demonstrate compliance" actually asks for.
Frequently Asked Questions
Does Klaviyo need cookie consent in the EU?
Yes, for visitors in the covered regions. Klaviyo's documentation states that "based on your Customer Privacy settings in Shopify, Klaviyo may not track onsite events for visitors to your Shopify store in the EU, EEA, UK and Switzerland, unless they have provided consent." The gate runs through Shopify's Customer Privacy API, which Klaviyo integrated with in February 2023.
Why did my Klaviyo Active on Site events stop working?
Most often because the consent gate is closed. Run window.Shopify.customerPrivacy.userCanBeTracked() in the browser console: if it returns false, Klaviyo will not record onsite events for that visitor. A merchant hit exactly this in April 2024 after a theme change, with the Klaviyo snippet still present in the page source, and resolved it by completing their consent platform's Customer Privacy API setup.
Can I mark Klaviyo's cookies as strictly necessary?
We would not. The EDPB's Guidelines 2/2023 place JavaScript-driven access inside Article 5(3) ePD at paragraph 33, so the analysis attaches to the script rather than to the label on its cookie. Klaviyo's own OneTrust configuration guide categorises its three __kla_id entries as "Targeting Cookies", which is difficult to reconcile with an essential classification.
Does blocking Klaviyo's cookies stop my sign-up forms from showing?
It can. Klaviyo's OneTrust guide warns that consent tools "can block cookies but also cause Klaviyo forms to stop working altogether, even forms that do not require tracking." Merchants reported this with Cookiebot from November 2024 through March 2026 without a documented fix in the thread. Plan a consent-independent capture path before deploying domain-level blocking.
Does a customer's order still reach Klaviyo if they refused marketing consent?
Yes. Klaviyo stated in November 2025 that "if a person places an order on Shopify, their information will be sent to Klaviyo, even if they didn't consent to marketing, and they'll be marked as 'Never Subscribed'." That is a server-side flow, not terminal-equipment access, so it raises a lawful-basis and records question rather than a cookie-consent one.
Conclusion
Consent-gating an email platform's onsite script does something uncomfortable: it shows you, in your own dashboard, how much of your behavioural data depended on visitors never being asked. The quiet numbers are the point, not the problem.
So treat the gate as load-bearing infrastructure. Enable the Customer Privacy API and verify it is available, test refusal rather than acceptance, decide the forms question before it decides itself, and record which purpose you mapped the platform to. Then spend the effort you would have spent un-gating the script on the consent rate instead, which is the only lever that recovers the data legitimately.
If you want the mapping and its evidence in one place rather than spread across a CMP, an app dashboard and someone's memory, see how PrivacyForge handles consent records and data mapping.
Sources
- Getting started with Klaviyo onsite tracking — Klaviyo Help Center
- How to enable onsite tracking for Shopify — Klaviyo Help Center
- Understanding cookies in Klaviyo — Klaviyo Help Center
- How to configure OneTrust with Klaviyo's cookies — Klaviyo Help Center
- An update on Klaviyo tracking for Shopify merchants — Klaviyo Community, 2 February 2023
- Privacy issue in Shopify Klaviyo Integration — Klaviyo Community, December 2022
- Active On Site events not working, Shopify App Embed Integration — Klaviyo Community, April 2024
- Cookiebot blocking embedded form — Klaviyo Community, November 2024 to March 2026
- How do handle data consent with the Klaviyo app embed — Klaviyo Community, November 2025
- Customer Privacy API — Shopify.dev
- Guidelines 2/2023 on Technical Scope of Art. 5(3) of ePrivacy Directive, Version 2.0 — EDPB