What Klaviyo Onsite Tracking Collects

The Klaviyo Onsite snippet (loaded from static.klaviyo.com/onsite/js/klaviyo.js) initializes a global _learnq queue and identifies visitors with a Klaviyo-owned cookie called __kla_id. Once installed it automatically reports pageview events, captures form interactions, fires the Active On Site event that drives Klaviyo's Browse Abandonment flow, and ties anonymous browsing behavior to a known subscriber profile the moment the visitor logs in or submits a form with an email address. Subsequent events — Viewed Product, Added to Cart, Started Checkout, Placed Order — fire through the same identity infrastructure and inherit the same cookie-based attribution.

For the GDPR analysis the cookie is non-essential, the data leaving the page is personal data because it is tied to a persistent identifier, and Klaviyo is established in the United States, which makes the transfer subject to the EU-US Data Privacy Framework. All three conditions push Klaviyo Onsite tracking firmly into "requires prior consent" territory in the EU, the UK, the EEA, and Brazil under the LGPD. In California the same processing falls under the CPRA's opt-out-of-sharing-for-cross-context-behavioral-advertising right, which Klaviyo's sharing with downstream paid-media destinations triggers.

The Three Tracking Surfaces You Have to Gate

A Klaviyo install is not one tracking surface, it is three, and they need to be treated separately in a CMP integration.

The Onsite tracking script

This is the main behavioral tracker — the script that sets __kla_id and drives the active-on-site event stream. It is the surface most teams remember to gate and the one most regulator-visible in audit. Block it by default and load it only when the visitor accepts the marketing category.

Klaviyo Forms and signup popups

Klaviyo Forms is a separate library that powers email and SMS signup popups, embedded forms, and gated content unlocks. It is hosted on the same domain but loaded as a separate script. Forms can fire impression and submission events independent of the main Onsite tracker, so gating only Onsite while leaving Forms loading is a common partial-compliance pattern that still leaks identifying data.

SMS opt-in collection

SMS signups have their own consent requirement under the TCPA in the US and under sector-specific rules in the EU, and Klaviyo's SMS forms collect phone numbers along with checkbox-confirmed consent. The consent collected here is for the SMS messaging itself, separate from cookie consent. A correctly configured stack records both: cookie consent in the CMP, SMS consent in the Klaviyo subscriber profile.

Native Klaviyo Privacy Controls

Klaviyo exposes several native privacy primitives. As with most marketing platforms they assume that a consent decision exists and is being passed in. They do not collect consent themselves.

The consent property on identify calls

When you call klaviyo.identify() or klaviyo.track(), you can attach a consent payload that records the lawful basis for marketing communications. This is the right primitive for passing the CMP's decision into Klaviyo's subscriber profile.

Profile-level consent fields

The subscriber profile has dedicated fields for email consent, SMS consent, and consent source. Updates to these fields propagate to Klaviyo's segmentation engine so flows respect the recorded state.

The Privacy & Consent settings panel

Klaviyo's admin UI has a Privacy & Consent section that controls some default behaviors — for example, whether the Active On Site event fires for visitors without recorded consent. The default is permissive; tightening these settings is a useful belt-and-suspenders layer on top of the CMP-level gating.

Step-by-Step CMP Integration

The reliable architecture is to gate all three Klaviyo tracking surfaces behind the CMP and use the consent properties on Klaviyo identify and track calls to keep the platform's subscriber records in sync with the recorded consent state.

1. Remove the default Onsite snippet from the head

Klaviyo provides a one-line snippet that installers typically paste into the document head. Remove it. Replace it with a placeholder script element whose type attribute is text/plain and whose data-category attribute identifies it as marketing. Your CMP will rewrite the type back to text/javascript when the visitor accepts the marketing category.

2. Defer Klaviyo Forms loading

The Forms library loads independently of Onsite. Apply the same placeholder pattern to its script element so it does not initialize before consent. After consent is granted, both Onsite and Forms can initialize together; queued events flush automatically.

3. Separate SMS consent from cookie consent

SMS opt-in collection runs through Klaviyo Forms but the consent collected (the explicit checkbox for SMS marketing) is a separate legal artifact from cookie consent. The CMP banner records the cookie decision; the form checkbox records the SMS decision. Do not bundle them — bundled consent is invalid under both the GDPR and the TCPA.

4. Propagate consent into the Klaviyo profile

When a known subscriber accepts or revokes consent on your site, the CMP should call the Klaviyo API to update the profile's consent fields. The Klaviyo Profiles API supports a partial-update call that writes email consent, SMS consent, and consent timestamp without overwriting the rest of the profile. Most modern CMPs have a Klaviyo connector that handles this end-to-end.

5. Wire Consent Mode v2 if you run Google tags alongside

Most Klaviyo-using stores also run Google Ads and GA4. Your CMP must publish the v2 consent signals — ad_storage, analytics_storage, ad_user_data, ad_personalization — into the dataLayer before any Google tag fires. Klaviyo does not consume these signals natively, but Google does, and an inconsistency between Klaviyo and Google will show up as a measurable revenue gap in attribution reporting.

Common Pitfalls

Four integration mistakes show up repeatedly in audits of Klaviyo deployments.

Treating Forms as "just a popup"

Some teams gate Onsite under marketing but leave Forms loading on initial render, reasoning that "a popup is just a UI element". The Forms library fires impression events to Klaviyo for every popup that displays, which is identifying behavioral data forwarded to a US ad-tech vendor — the exact pattern a CMP is supposed to prevent.

Bundling cookie and SMS consent

A single checkbox that says "I agree to cookies and to receive marketing SMS" is invalid for both. Cookie consent must be specific to cookies; SMS consent must be specific to SMS. Use separate controls.

Letting third-party paid-media connectors fire on revoked profiles

Klaviyo can push audiences to Google Ads, Meta, TikTok, and other ad networks via its integrations. If a subscriber revokes consent, the audience push needs to drop them — not just stop adding them. Configure Klaviyo's audience-sync settings to honor consent-state changes in real time, not just at initial sync.

Forgetting the historical data question

When a visitor accepts consent for the first time, your stack should not retroactively associate their pre-consent anonymous behavior with their new profile. The CMP and Klaviyo should agree that pre-consent browsing data is not personal data tied to the now-identified profile. Some Klaviyo flows assume this association by default — review the relevant flow triggers.

Audit Checklist

Six concrete questions to answer for any Klaviyo deployment touching EU, UK, Brazilian, or California traffic.

• Does Onsite wait for consent? Open the storefront in a private window with strict tracking protection and confirm no static.klaviyo.com requests fire before banner acceptance.
• Does Forms wait for consent? Confirm that popup impression events do not fire before the marketing category is accepted.
• Are cookie consent and SMS consent separate? Confirm the cookie banner does not also collect SMS consent, and that SMS opt-in forms record their own explicit checkbox.
• Does the Klaviyo profile reflect CMP state? Confirm the CMP writes consent decisions to the profile's consent fields via the Klaviyo API.
• Do audience syncs honor revocations? Confirm that revoking consent removes the subscriber from downstream paid-media audiences, not just from future syncs.
• Is pre-consent browsing kept anonymous? Confirm flow triggers do not retroactively associate pre-consent behavior with newly identified profiles.

Where Klaviyo Fits in a Consent-First Stack

Klaviyo sits at the intersection of e-commerce attribution and direct marketing communications, which means it touches both the cookie-consent regime (GDPR/ePrivacy, CCPA/CPRA) and the marketing-communications regime (CAN-SPAM, TCPA, GDPR Article 6/7 for messaging). The right architecture treats these as two distinct consent surfaces — both routed through a single CMP that owns the source of truth, with Klaviyo's native consent fields kept in sync via API. Stores that get this right preserve the abandoned-cart, browse-abandonment, and segmentation behavior that makes Klaviyo commercially valuable while reducing audit exposure to a fraction of what a default install carries. The engineering work is straightforward; the discipline is in not letting the marketing team treat Forms as exempt from the same rules as the Onsite tracker.