Free scan
Klaviyo / email tracking · troubleshooting

Klaviyo identifies shoppers before they consent

Klaviyo's onsite tracking is not just analytics — it is profile building. The script sets a cookie identifying the browser, and when a visitor arrives from a Klaviyo email or completes a form, that browser is linked to a real person and everything it did before is attached to them retroactively.

The short answer

Two behaviors do most of the work. First, the onsite script sets a __kla_id cookie on load, so browsing is being recorded against a profile before anyone has agreed to anything. Second, a click from a Klaviyo email carries an identifier in the URL, which the script uses to resolve that browser to a known profile — meaning a visitor who never filled in a form on this visit is nonetheless identified.

Neither is a defect; it is what the product does, and it is why the tool is effective. The question is timing: whether it runs before the visitor answers your banner.

Last reviewed: September 1, 2026Diagnostic + fix checklistGeneral information, not legal advice

What it looks like

Fresh incognito window, DevTools → Network, banner untouched. An ungated install loads static.klaviyo.com/onsite/js/klaviyo.js (with your public API key in the URL) and then talks to a.klaviyo.com. Application → Cookies shows __kla_id set on first paint.

The clearer demonstration: click a link in one of your own marketing emails, land on the site, and check the cookie again. It now carries an identified profile — and the sessions recorded before that click can be attributed to the same person.

DevTools → Network — fresh incognito, banner untouched:
GET static.klaviyo.com/onsite/js/klaviyo.js?company_id=… ← onsite script loads with the page
Cookie: __kla_id=… ← profile identifier set on first paint
(arriving from an email link) ← browser resolves to a named profile

Verify it yourself in five minutes

Three passes: cold visitor, identified visitor, and the install inventory. The middle one is the pass most teams have never run.

  1. Cold visit. Fresh incognito window, DevTools → Network, banner untouched. Filter for klaviyo. If klaviyo.js loads and requests go to a.klaviyo.com, tracking started before consent.
  2. Check storage. Application → Cookies → your domain. Is __kla_id present before you clicked anything on the banner? Note its expiry.
  3. Identified visit. In a second incognito window, click a link from one of your own Klaviyo emails. Look at the URL for a tracking parameter, then check the cookie and the requests. This is the identity-attach path, and it is worth seeing once with your own eyes.
  4. Inventory the installs. On Shopify, Klaviyo is usually injected by the app integration rather than sitting in your theme, so check the app's onsite-tracking setting as well as the theme. Elsewhere, search the rendered page source for klaviyo.js and check your GTM container.
  5. Check the forms. Klaviyo signup forms and popups are served by the same script. If the script is gated, decide deliberately whether your email capture forms still appear for non-consenting visitors.
  6. Compare against your privacy policy. Does it disclose profile-level onsite tracking and email-click identification? Many ecommerce policies describe cookies generically and never mention identity attachment.

What a healthy result looks like: A gated install contacts no Klaviyo domain and sets no __kla_id until the visitor accepts. After acceptance, everything works normally.

Why it happens

1. The platform app installs it outside your control

On Shopify and similar platforms the Klaviyo integration injects the onsite script itself. It never passes through your theme, so a consent tool that only manages theme code has no chance to gate it.

2. Onsite tracking is on by default

The integration's onsite-tracking toggle is enabled as part of a standard setup, because it is what makes browse-abandonment and product-viewed flows work. Nobody framed it as a consent decision at the time.

3. The CMP has it categorized as functional

Email tools frequently land in "functional" or "necessary" buckets because they are associated with transactional messaging. A script that builds a behavioral profile and attaches an identity is hard to defend in either category.

4. Forms and tracking are the same script

Teams that try to gate Klaviyo sometimes discover their signup popups disappear too, revert the change, and leave the tracking ungated. That is a real tradeoff, and it needs a deliberate answer rather than a rollback.

The risk context

California's Invasion of Privacy Act (CIPA), Penal Code § 631, prohibits intercepting a communication without the consent of all parties. Since 2022, plaintiff firms have applied that decades-old wiretapping statute to websites — arguing that building a behavioral profile of a shopper and linking it to a real identity when they arrive from an email before the visitor consents is an intercepted communication. Statutory damages under § 637.2 run up to $5,000 per violation, and plaintiffs argue each affected visitor session is a separate count, which is why even small sites receive demand letters. Similar all-party-consent statutes in Pennsylvania (WESCA), Florida (FSCA), and Massachusetts have produced parallel filings.

Ecommerce sites carry a second consideration alongside the timing question: shopping behavior tied to an identified person is exactly the kind of profile California's consumer-privacy rules give consumers rights over, including notice at collection and the right to opt out of sharing for cross-context behavioral advertising.

To be precise about what a network log can tell you: a tracker firing before consent is a technical finding — it establishes when a script transmitted data, not whether any law was broken. But timing is exactly what these claims are built on, which is why fixing the timing is the practical response.

How to fix it

What this is called

Terminology bridge

Klaviyo calls it onsite tracking; the general pattern is identity resolution — linking an anonymous browser to a known profile, here via an email click. The flows it powers are browse abandonment and cart abandonment. In consent language the script belongs to the analytics/marketing category, never to strictly necessary. On Shopify, the supported mechanism for scripts to check consent before tracking is the Customer Privacy API.

What a scan can and can't tell you

A scan shows that Klaviyo's script loaded and that a profile cookie was set, with timing relative to the banner. It cannot see what is inside your Klaviyo account, what data your flows use, or whether any of it is lawful in your jurisdiction — and this page is general information, not legal advice. The timing, though, is entirely in your hands, and it is the part an automated scanner on the other side would look at.

Sources

  1. Klaviyo: JavaScript API for identification and trackingdevelopers.klaviyo.com
  2. Shopify: Customer Privacy APIshopify.dev
  3. California Civil Code § 1798.100 — notice at collectionleginfo.legislature.ca.gov
  4. California Civil Code § 1798.140 — definitions of sell, share, and consentleginfo.legislature.ca.gov

Check your own site

RegSentry loads your site in a real browser, records when each third-party tracker first contacts its server, and flags everything that fires before consent — with the fix for each one. Continuous monitoring re-runs it and emails you when something new appears.

Free real-browser scan

See every pre-consent tracker on your site — free, 30 seconds, no signup.

Real browser scan, no signup to run it. You see a summary of the findings; the full report with every tracker unlocks with your email.

Common questions

Does Klaviyo track visitors before they consent?
By default the onsite script loads with the page, sets a __kla_id profile cookie, and begins recording browsing against a profile — before any banner interaction. It is not a defect; it is what onsite tracking does. Gating it requires the platform's consent API, your consent platform's script handling, or a consent-required tag.
How does Klaviyo know who an anonymous shopper is?
A click from a Klaviyo email carries an identifier in the URL, and the onsite script uses it to resolve that browser to a known profile. From that point the browsing recorded against the anonymous cookie is attributed to a named person, including activity from before the click.
Can I gate Klaviyo without losing my signup forms?
Klaviyo's forms and its onsite tracking come from the same script, so blocking one blocks the other. The workable answers are to serve forms from a path that does not start profile tracking, or to treat form submission as the consent moment and gate everything else behind the banner. Decide it deliberately rather than reverting the gate.

Keep reading

Compliance for ecommerce storesMeta Pixel fires before consentI can't edit the head on my website builderReport: the state of website trackingFree cookie consent checker