The problems
If Klaviyo didn't see checkout, the flow is fiction.
Refunds still get post-purchase. Failed payments never start a flow. A theme update can make cart emails go dark.
What this actually is
You run the brand. A refund that still gets "thanks for your order" is one leak on the storefront. If that's the one costing money, we start here.
Klaviyo can only automate what the store emits. Setup, in practice, meant installing the app and pasting a snippet once. Then a theme update. Then a checkout change. The app still says connected. Checkout never fires. Cart fires on the wrong click. Viewed Product fires twice.
The theme sees the storefront. Checkout is separate. A custom pixel is not automatically cleaner than the app embed. The app embed is not automatically cleaner than a snippet in the theme. What matters is one path per event, named for the thing that happened, still there after the last publish.
Returns, failed payments, restocks often never hit the browser. Those need a Flow custom event, or the sequence is fiction. If the emails don't match what actually happened, they're a story about a store that doesn't exist.
Added to Cart stopped after a theme update
Added to Cart stopped after a theme update because a theme publish wiped the snippet. The app still says connected. Put the snippet back once, not twice. The storefront scan cannot see Klaviyo.
checkout_completed not firing
checkout_completed not firing usually means the theme never saw checkout. A custom pixel is not the checkout pixel. We're not an Elevar alternative. The scan cannot see Klaviyo.
Why the usual vendor misses it
Checkout is the part everyone drops. Theme work stops at the cart. The Klaviyo shop starts at the metric. A Klaviyo health check doesn't find it. They will tell you volume looks low. They will not add the checkout piece. They will not fix a theme that double-sends Viewed Product. A freelancer will paste the snippet they used last time and leave.
We don't sell a GTM product. We're not an Elevar alternative. We fix the store so Klaviyo sees checkout. If you already have a data layer tool, we still own the theme it sits on.
What we do on the store
- One listener per event. App embed or snippet, not both.
- Checkout events on checkout, not on a cart drawer.
- Stop the page from firing the same view twice.
- Put back what a theme update wiped, without a second copy of the script.
- Tell Klaviyo about returns, failed payments, restocks when the storefront never sees them.
If Shopify Email and Klaviyo both send the cart, that's a sibling problem: duplicate cart emails. We are not a Klaviyo agency. Email marketing is an offer. We can write the flows and campaigns once the store is telling the truth. If they already have a Klaviyo shop for a campaign calendar, we sit beside them.
We fix the store so Klaviyo sees checkout
The storefront scan cannot see Klaviyo. That's on purpose. We don't pretend a public page is your email account. Contact us if the mismatch is the leak.
For guidance on which email platform to use at your revenue band (Shopify Email vs Klaviyo), see the email systems stack. This page is store-side event tracking. That page is which tool.
Straight answers.
Klaviyo can only send on what the store tells it. If checkout never fires, the flow never starts. If cart fires too often, people get emails for things they didn't do. The app can still say connected.