Klaviyo Tracking on Shopify: Server-Side Sync vs Onsite JS

|Dan Giura
Klaviyo Tracking on Shopify: Server-Side Sync vs Onsite JS

TL;DR

Two pieces of this integration run on your storefront and they do completely different jobs. A theme loader puts Klaviyo's onsite script on the page so signup forms render and a logged-in shopper gets identified to their profile. Separately, Shopify's web pixel watches shopper activity in its sandbox and hands what it sees to our server, which posts the event to Klaviyo's Events API [2]. Nothing in that second path touches the browser's connection to Klaviyo. Placed Order goes further still: it starts from Shopify's order webhook, so no browser is involved at any point, and each order is recorded as sent so webhook retries do not write a second one. If you have read how Klaviyo's own Shopify integration splits its events, this is the part that changes when the app is in the picture: the browse events stop depending on a browser finishing its work. Klaviyo support shipped in June 2026 and needs the Plus plan at $39 a month [4].

Key Takeaways

  • Two independent pieces run on your storefront: a theme loader that places Klaviyo's onsite script, and a Shopify web pixel that reports to our server. They never talk to each other.
  • Six of the seven start in Shopify's web pixel. Placed Order starts from the order webhook and involves no browser at all.
  • The onsite klaviyo.js the app loads fires zero tracking calls. Its job is signup forms plus identifying logged-in customers.
  • If your theme already carries Klaviyo's own snippet, the app's loader stands down so the two never run side by side.
  • Placed Order is idempotent per order, so Shopify webhook retries and concurrent deliveries do not double-count a sale.
  • Browse events sent from the storefront respect Shopify's Customer Privacy API marketing consent signal. We make no consent claim for the order webhook path.
  • Klaviyo is marketing automation, not an ad pixel. It sits alongside the seven ad and analytics destinations rather than inside their conversion counts.

Two Layers, and One of Them Sends Nothing

Open the network tab on a store running this integration and you will not see browse events leaving the browser for Klaviyo. Open the page source and klaviyo.js is sitting right there. Both observations are correct, and the gap between them is the whole design.

The app runs two independent things on your storefront. One is a theme loader that places Klaviyo's onsite script on the page. The other is a Shopify web pixel, which runs in the sandbox Shopify gives apps and observes shopper activity through the platform's event subscriptions. The pixel does not call the onsite script. It reports what it sees to our server, and our server writes the event to Klaviyo through the Events API [2].

Every metric this integration writes into Klaviyo is written by a server. That is why an ad blocker that kills third-party requests in the browser does not thin out your Klaviyo browse data the way it thins out a purely onsite setup. We covered the wider version of that problem in our piece on ad blockers and server-side tracking.

Which Metrics Arrive, and Where Each One Starts

Klaviyo metric Where it starts How it reaches Klaviyo
Viewed Page Shopify web pixel Server-side
Viewed Product Shopify web pixel Server-side
Viewed Category Shopify web pixel Server-side
Product Searched Shopify web pixel Server-side
Added to Cart Shopify web pixel Server-side
Checkout Started Shopify web pixel Server-side
Placed Order Shopify order webhook Server-side

Six from the pixel, one from the webhook, seven delivered the same way. If you have built a browse abandonment flow in Klaviyo, rows two and three are the ones your trigger is reading, and rows five and six are what most cart and checkout flows key on.

There is also a merchant setting worth knowing about before you audit your metric volumes: Send Anonymous Events, which is on by default. With it on, activity from visitors the app cannot resolve to a known profile still reaches Klaviyo as anonymous profile activity, which Klaviyo can merge into a known profile once that visitor identifies themselves.

Why Does the Onsite Snippet Load At All?

Because two Klaviyo features genuinely need a script in the page, and neither is event tracking.

Signup forms are the first. Klaviyo's popups and embedded forms are rendered by klaviyo.js in the browser [1], so a store without it has no way to show them. If you have built forms in Klaviyo and they never appear on the storefront, a missing onsite script is the usual reason.

Identification is the second. When a logged-in customer loads a page, the loader tells Klaviyo which profile the browser belongs to, so form submissions and onsite behavior attach to the right person rather than starting a new anonymous record [5].

One more behavior matters more than it sounds like it should: if your theme already carries Klaviyo's own snippet, the app's loader stands down entirely and leaves that snippet alone. No setting to find. If Klaviyo is already on the page, our loader does not inject a second copy and does not call identify. That single rule is what keeps stores that installed Klaviyo years ago from ending up with two copies of the same script arguing over the same visitor.

What Does Placed Order Carry?

More than the total. The order event includes the value and currency, the item count and total quantity, the item names and line items, discount codes used and total discounts, a transaction ID, an order URL, and the buyer's IP and user agent.

Those properties are what a post-purchase flow needs in order to segment rather than just say thank you. Discount codes on the event let you split first-time coupon buyers from full-price buyers. The order URL gives your confirmation email somewhere real to point. The item names let a replenishment flow branch on what was actually bought.

Delivery is idempotent per order. The app records each order's server-side send, so Shopify's webhook retries and duplicate deliveries do not produce a second Placed Order in Klaviyo. This matters because Shopify's own documentation warns that an app might receive the same webhook more than once, and a duplicated Placed Order does not just inflate a metric, it can re-enter a customer into a flow they already completed. The mechanics of that failure mode, and why every server-side integration has to solve it, are in our article on why server-side retries double-count purchases.

Where Consent Applies, and Where We Make No Claim

Browse events sent from the storefront respect Shopify's Customer Privacy API marketing consent signal [3]. That is the accurate scope, and it covers the six pixel-originated metrics in the table above.

Placed Order arrives on a different road. It comes from the order webhook, server to server, after the sale is complete, and we make no consent claim about that path. Stating it any other way would be wrong, and this is the kind of detail that surfaces during a privacy review rather than during setup. If your policy requires transactional order data to be gated as well, that decision belongs in your Klaviyo configuration and your own legal review, not in an app claim.

How Do You Check Which Path Delivered an Event?

Three places, in the order that answers questions fastest.

In Klaviyo, open Analytics → Metrics, select the metric, and read its recent activity. If Viewed Product is climbing, the pixel path is working. If Placed Order is climbing but browse metrics are flat, the webhook path is fine and something is wrong upstream of the pixel.

In the app, the recent events stream shows Klaviyo alongside the other connected platforms, so you can watch events arrive without leaving the admin.

In Shopify, Settings → Customer events lists the app pixel and its data access status, which is where a paused pixel shows up. A paused app pixel stops the six browse metrics and leaves Placed Order running, which produces exactly the flat-browse pattern described above.

What you will not find is browser network traffic for these metrics. Merchants often check there first, do not see any, and open a support ticket about an integration that is working correctly.

Plan, Markets, and Where Klaviyo Sits in the Stack

Klaviyo is one of the nine integrations in WeltPixel Conversion Tracking and the only one that is not an ad or analytics destination. Keep it out of your ad conversion counts when you compare tracking stacks, because a marketing automation platform folded into a platform count makes two stacks look comparable when they are not.

On the current free plan, which covers GA4 only and up to 100 storefront orders a month, Klaviyo is not included. It requires Plus at $39 a month, which also carries multiple pixel instances per channel, up to 50, and per-Market routing so a store selling into several Shopify Markets can point each one at its own Klaviyo instance. Our guide to running a different pixel for each Shopify Market covers how that scoping behaves when a shopper's market cannot be determined.

The integration shipped in June 2026 and has been through the same delivery model as the rest of the app since.

FAQ

Does WeltPixel Conversion Tracking replace Klaviyo's own Shopify integration?

No. Klaviyo's integration syncs customers, orders, catalog data, and its own metrics, and you should keep it connected. This app adds server-side delivery of seven event metrics on top of that. If your theme already runs Klaviyo's onsite snippet, the app's loader stands down and leaves it in place.

Why do I see klaviyo.js in my page source if the app sends events server-side?

That script is loaded so Klaviyo signup forms can render and so logged-in customers get identified to their profile [1][5]. It fires no tracking calls of its own. The seven metrics all travel from our server to Klaviyo's Events API [2].

Will Placed Order fire twice if Shopify retries the webhook?

No. Each order's server-side send is recorded, so retries and concurrent deliveries are recognized and skipped rather than written again. That protection covers Shopify's retry window and duplicate deliveries of the same order webhook.

Which Klaviyo events respect shopper consent?

Browse events sent from the storefront respect Shopify's Customer Privacy API marketing consent signal [3]. Placed Order comes from the order webhook rather than the storefront, and we make no consent claim about that path.

Is Klaviyo available on the free plan?

No. The current free plan covers GA4 tracking for up to 100 storefront orders a month. Klaviyo, along with the other integrations, multiple pixel instances, and per-Market routing, is on the Plus plan at $39 a month [4].

If your Klaviyo flows depend on browse and cart events that a browser is not reliably delivering, install WeltPixel Conversion Tracking and let the server send them.

Sources

  1. Klaviyo onsite tracking and signup forms documentation, https://help.klaviyo.com/hc/en-us/articles/360020342232, accessed August 24, 2026
  2. Klaviyo Events API, Create Event reference, https://developers.klaviyo.com/en/reference/create_event, accessed August 24, 2026
  3. Shopify Customer Privacy API, https://shopify.dev/docs/api/customer-privacy, accessed August 24, 2026
  4. WeltPixel Conversion Tracking, Shopify App Store listing, https://apps.shopify.com/weltpixel-conversion-tracking, accessed August 24, 2026
  5. Klaviyo JavaScript API (identify), https://developers.klaviyo.com/en/docs/javascript_api, accessed August 24, 2026

Ready to upgrade your tracking?

Server-side tracking for Magento and Shopify — accurate data, better attribution, full privacy compliance.