Shopify-branded events (Added to Cart, Checkout Started) not tracking for visitors identified via Klaviyo forms only logged-in customers tracked, despite profile syncing enabled
Solved
Shopify-branded events (Added to Cart, Checkout Started) not tracking for visitors identified via Klaviyo forms only logged-in customers tracked, despite profile syncing enabled
I've hit a wall with Shopify pixel event tracking and I've exhausted
everything in the docs, so I'd appreciate input from the community or Klaviyo
staff.
The issue:
None of the Shopify-branded behavioral events (Added to Cart, Checkout
Started, Viewed Collection, Submitted Search) track for visitors who were
identified by submitting a Klaviyo popup form. The only visitors who get these
events are those logged into a Shopify customer account or who entered their
email at checkout.
The Klaviyo cookie itself is working: those same popup-identified profiles
show Active on Site and Form submitted by profile events immediately. So
Klaviyo knows exactly who they are — the Shopify-branded events just never
associate with them.
What I've already verified (before anyone sends the checklist 🙂):
- Integration connected to the correct store; app embed on; klaviyo.js
confirmed loading in page source
- Onsite tracking → Track behavioral events enabled; the Shopify-branded
metrics all exist in my Metrics list, so the pixel has fired successfully
before
- Sync settings → To Shopify: "Sync profiles, profile data, and custom
properties from Klaviyo to Shopify" is enabled, scope All profiles, email
subscription status included
- Sync settings → From Shopify: email subscriber sync enabled with a list
selected
- Double opt-in disabled
- Controlled side-by-side test: same browser, same product — logged-in session
tracks Added to Cart / Checkout Started fine; a fresh session identified via
the popup form tracks nothing
Why I'm confused:
The migration guide ("How to migrate to our automatic Added to Cart event for
Shopify") lists "Submits a Klaviyo form (requires profile syncing enabled)" as
one of the ways a visitor becomes identified for these events. I meet that
requirement exactly, and it doesn't happen.
My questions:
1. Is this expected behavior due to Shopify's sandboxed web pixels — i.e.,
identity can realistically only come from Shopify's side (login / checkout /
Shopify forms)?
2. If so, is the recommended path still installing the legacy Added to Cart
snippet so form-identified (cookied) visitors are covered?
3. If it's not expected, what would make the Klaviyo-form identification path
work with the pixel?
Thanks in advance!
Best answer by GabbyEsposito
@kimao Thanks so much for outlining everything you’ve already tested. That level of detail is really helpful and you’re thinking about this exactly the right way.
From how things work today, there are a couple of key pieces to validate with this specific “Klaviyo popup → Shopify pixel events” flow.
1. Confirm the profile sync path from Klaviyo → Shopify
You’re right to focus on this line from the migration guide:
“Submits a Klaviyo form. You must have enabled syncing profiles from Klaviyo to Shopify for this to work.”
The missing link we see most often is not the toggle itself, but whether the popup submit is actually turning into a Shopify customer.
Could you try this controlled test?
In Klaviyo → Integrations → Shopify → Sync settings → To Shopify:
Make sure “Sync profiles and profile data from Klaviyo to Shopify” is enabled.
Confirm the scope is All profiles, not just ones that already exist in Shopify.
In a fresh browser, submit your Klaviyo popup with a brand‑new test email (never used on this store).
Check Shopify admin → Customers:
Does that exact email appear as a customer record?
If the email does not show up as a Shopify customer, then Shopify’s pixel has no customer identity to attach those Added to Cart / Viewed Collection / Submitted Search events to, which would produce exactly what you’re seeing: Klaviyo cookie events work; Shopify‑branded ones don’t attach.
If the email does appear as a customer and the rest of your settings are as you described, then this starts to look more like an issue we should escalate (see below).
2. Run one more “happy‑path” test end‑to‑end
Just to fully isolate where things are breaking, I’d recommend this sequence with a single test address:
Confirm:
Shopify integration is connected.
In Klaviyo → Integrations → Shopify → Onsite tracking:
“Track behavioral events” is enabled.
In Shopify → Online Store → Themes → Customize → App embeds:
The Klaviyo app embed is on for your live theme.
In a fresh browser:
Submit the Klaviyo popup with a brand‑new test email.
Confirm:
Klaviyo profile exists and shows Form Submitted / Active on Site.
Shopify customer exists for that same email.
In the same session:
View a collection.
Use the site search.
Add a product to cart.
Back in Klaviyo, check that test profile for:
Shopify‑branded Viewed Collection / Submitted Search / Added to Cart events (Shopify icon, not the gear).
If all of the above checks out (including the Shopify customer record) and those Shopify‑branded events still never show, that’s no longer expected based on our docs, we’d want Support to dig into logs for your specific account/store combo.
3. How this ties to your sandboxing / identity questions
To your questions directly:
“Is this expected behavior due to Shopify’s sandboxed web pixels?”
It is expected that the Klaviyo cookie by itself doesn’t identify someone for Shopify‑branded events.
It is not expected that a customer who:
submits a Klaviyo form, and
is synced from Klaviyo → Shopify as a customer would never get those Shopify‑branded events. That path is explicitly documented as supported.
“Should I still use the legacy Added to Cart snippet?”
The newer automatic, Shopify‑branded Added to Cart is the recommended event going forward and is actively maintained.
That said, Klaviyo has not deprecated the legacy theme snippet. It is perfectly valid (and still documented) to keep or re‑install the snippet in addition to the automatic event if you want:
Guaranteed Added to Cart coverage for anyone with a Klaviyo cookie, even if Shopify pixel identity is weaker.
The tradeoff is that you’ll have two different Added to Cart metrics and will want to be intentional about which one powers each flow/segment/report.
If you’re comfortable sharing some of those test details back here (you can obfuscate the email), folks in the Community may also help sanity‑check before you go through a full Support ticket.
@kimao Thanks so much for outlining everything you’ve already tested. That level of detail is really helpful and you’re thinking about this exactly the right way.
From how things work today, there are a couple of key pieces to validate with this specific “Klaviyo popup → Shopify pixel events” flow.
1. Confirm the profile sync path from Klaviyo → Shopify
You’re right to focus on this line from the migration guide:
“Submits a Klaviyo form. You must have enabled syncing profiles from Klaviyo to Shopify for this to work.”
The missing link we see most often is not the toggle itself, but whether the popup submit is actually turning into a Shopify customer.
Could you try this controlled test?
In Klaviyo → Integrations → Shopify → Sync settings → To Shopify:
Make sure “Sync profiles and profile data from Klaviyo to Shopify” is enabled.
Confirm the scope is All profiles, not just ones that already exist in Shopify.
In a fresh browser, submit your Klaviyo popup with a brand‑new test email (never used on this store).
Check Shopify admin → Customers:
Does that exact email appear as a customer record?
If the email does not show up as a Shopify customer, then Shopify’s pixel has no customer identity to attach those Added to Cart / Viewed Collection / Submitted Search events to, which would produce exactly what you’re seeing: Klaviyo cookie events work; Shopify‑branded ones don’t attach.
If the email does appear as a customer and the rest of your settings are as you described, then this starts to look more like an issue we should escalate (see below).
2. Run one more “happy‑path” test end‑to‑end
Just to fully isolate where things are breaking, I’d recommend this sequence with a single test address:
Confirm:
Shopify integration is connected.
In Klaviyo → Integrations → Shopify → Onsite tracking:
“Track behavioral events” is enabled.
In Shopify → Online Store → Themes → Customize → App embeds:
The Klaviyo app embed is on for your live theme.
In a fresh browser:
Submit the Klaviyo popup with a brand‑new test email.
Confirm:
Klaviyo profile exists and shows Form Submitted / Active on Site.
Shopify customer exists for that same email.
In the same session:
View a collection.
Use the site search.
Add a product to cart.
Back in Klaviyo, check that test profile for:
Shopify‑branded Viewed Collection / Submitted Search / Added to Cart events (Shopify icon, not the gear).
If all of the above checks out (including the Shopify customer record) and those Shopify‑branded events still never show, that’s no longer expected based on our docs, we’d want Support to dig into logs for your specific account/store combo.
3. How this ties to your sandboxing / identity questions
To your questions directly:
“Is this expected behavior due to Shopify’s sandboxed web pixels?”
It is expected that the Klaviyo cookie by itself doesn’t identify someone for Shopify‑branded events.
It is not expected that a customer who:
submits a Klaviyo form, and
is synced from Klaviyo → Shopify as a customer would never get those Shopify‑branded events. That path is explicitly documented as supported.
“Should I still use the legacy Added to Cart snippet?”
The newer automatic, Shopify‑branded Added to Cart is the recommended event going forward and is actively maintained.
That said, Klaviyo has not deprecated the legacy theme snippet. It is perfectly valid (and still documented) to keep or re‑install the snippet in addition to the automatic event if you want:
Guaranteed Added to Cart coverage for anyone with a Klaviyo cookie, even if Shopify pixel identity is weaker.
The tradeoff is that you’ll have two different Added to Cart metrics and will want to be intentional about which one powers each flow/segment/report.
If you’re comfortable sharing some of those test details back here (you can obfuscate the email), folks in the Community may also help sanity‑check before you go through a full Support ticket.
