What it is
Klaviyo does two jobs on a storefront. It renders signup forms and popups, which a visitor arguably needs for the site to work as intended, and it tracks browsing behaviour to feed segmentation and flows, which is marketing by any definition.
Blocking Klaviyo outright therefore removes a visible feature. Allowing it outright turns behavioural marketing on without consent. The catalogue splits the hosts so a scan reports the two separately, and the adapter does the same at runtime.
What a scan matches
A verification scan drives a real browser and records the outbound requests observed during its configured journeys, so Klaviyo is identified by request hosts and paths rather than by source-code claims. Requests on unvisited paths, after unperformed interactions or solely on the server remain outside that observation.
- static.klaviyo.com: onsite forms, classified as functional
- static-tracking.klaviyo.com and a.klaviyo.com: behavioural tracking, classified as advertising
Cookies are classified by name before domain because many analytics and advertising tags write first-party cookies through the page, which places a vendor-related identifier on your domain. Matching known names helps attribute those values without assuming that every first-party cookie came from your own application.
| Cookie | What it is for |
|---|---|
| __kla_id | The Klaviyo profile identifier used for behavioural tracking |
| _kla_* | Related Klaviyo tracking state |
Controlling it with consent
The adapter loads the onsite forms with Klaviyo’s documented `__kla_off` tracking opt-out set synchronously before the loader, so forms work while behavioural tracking does not. When marketing is allowed, the adapter-owned opt-out cookie is removed. On withdrawal the tracking opt-out is restored while the forms remain available.
Use the public site ID, never a private API key. Remove independently installed Klaviyo scripts first, and review first-party identification features in your account: cookies on other domains, identity workers and app-side tracking all need account-specific validation.
This one has a first-class adapter
Enter the identifier in the property’s technology list and the runtime applies that adapter’s control strategy. Depending on the vendor, that means withholding the loader, establishing denied defaults, or loading a functional surface with tracking opted out; the article above describes the exact behavior. Remove copies installed in a theme, plugin, app or tag manager first, or another installation can remain outside that control.
What breaks if it is refused: behavioural segmentation and browse-abandonment flows for refusing visitors. Signup forms keep working, which is the point of the split.
Verifying it
The specific proof to obtain: with marketing off, a form still opens and submits, and no behavioural tracking fires. Then repeat allow, revoke and reload against your actual account rather than a test one.
- Before a choice: optional tracking endpoints and optional identifiers are absent; any intentionally loaded necessary or functional surface matches the control model described above
- After rejecting optional categories: optional activity remains absent and the refusal persists across a reload
- After granting the relevant category: the expected loader or embed appears and the feature behaves normally
- After withdrawing: new optional activity stops; where the vendor supports a consent signal, verify that the signal is sent as well as checking network behavior
Common questions
Can I keep Klaviyo forms working without marketing consent?
Yes, and that is what the adapter is built to do. Forms load with the tracking opt-out set before the script, so the visible feature survives a refusal of behavioural tracking.
What about Klaviyo identification from an email click?
Identity that arrives from a link parameter or a server-side integration is outside what a page-level runtime controls. It needs validating against your own account configuration.
Sources and verification
Verified on . Product-behaviour statements were checked against the current implementation and tests. The links below are the verification basis recorded for this article. They support the stated facts, not a legal conclusion for every site or configuration; recheck changing vendor behaviour before relying on it in production.
- Klaviyo: cookies and web tracking
Vendor documentation
Checked
See what your own site is loading
A browser scan reports the requests and storage it observed during the sampled journey. Use configured workspace scans to compare the states and pages that matter to your implementation.