Full Answer

Klaviyo has two ways to learn about a customer's behaviour. The onsite JavaScript snippet watches the browser, and the server-side APIs accept events posted directly from your backend. The snippet is easy but lossy: ad blockers, privacy browsers, and consent gating all suppress it, which is the usual reason Klaviyo's order count comes in below WooCommerce's actual orders.

Server-side tracking sends the events from where the data is authoritative. When a WooCommerce order is placed, your server calls Klaviyo's Events API with a Placed Order event, the line items, value, and the customer profile keyed on email. The same pattern covers Started Checkout, Viewed Product, and custom events the snippet can't reliably emit. Because the call originates server-side, it isn't subject to the browser blocking that drops snippet events, so your flows trigger on the real customer actions rather than a sampled subset.

The payoff is in the automations that depend on accuracy. An abandoned-cart or post-purchase flow built on snippet data fires for only the customers who were trackable; built on server events it fires for everyone who actually qualified. You can wire this with Klaviyo's APIs directly or route it through a server-side pipeline alongside your other destinations, but the core idea is the same: let the server, not the browser, tell Klaviyo what happened.