Klaviyo for WooCommerce: The Sync Step Most Teams Miss

What Klaviyo for WooCommerce actually involves

Shopify stores connect Klaviyo through a native app: install it, authorise it, and order, checkout, and browsing events start flowing within minutes. WooCommerce has no equivalent. Because WooCommerce is a WordPress plugin running on hosting you control, Klaviyo talks to it through a sync plugin and a set of webhooks rather than a first-party integration built into a platform’s app store. That difference is not cosmetic — it changes which events you can trust, how checkout abandonment gets tracked, and where the sync quietly breaks without anyone noticing for weeks.

If you’re moving to Klaviyo for woocommerce from a Shopify mental model, expect three things to be genuinely different: setup takes longer because you’re configuring a plugin and a webhook endpoint instead of clicking “connect,” some events that were automatic on Shopify need a tracking snippet placed correctly on a self-hosted checkout, and consent capture is your responsibility rather than something Shopify’s checkout partly handles for you. None of that makes woocommerce klaviyo unworkable. It makes the setup order matter more than it does on Shopify, and it means one setting — covered in the step most teams get wrong, below — decides whether your abandonment flows ever fire.

This article is aimed at operators running WooCommerce at $3M–$30M in revenue, usually on WooCommerce Subscriptions or a similar paid extension stack, not a bare WooCommerce install processing a handful of orders a month. A store under $3M in revenue can follow the same sync steps, but the flow build that follows is overkill for that order volume; start with order and welcome flows only.

What you need before you connect Klaviyo to WooCommerce

Before you touch a plugin, confirm four things, because each one causes a support ticket later if it’s missing at the start.

Admin access to both systems. You need WordPress admin access to install and configure the sync plugin, and a Klaviyo account with API key permissions — not just a marketing-user login. Some agencies set up the Klaviyo side without ever getting WordPress access, which means the connection has to be finished by someone else later, often incorrectly.

A caching strategy you understand. Most WooCommerce stores at this revenue range run a caching plugin, a CDN, or both, for page speed. Full-page caching is the single most common cause of broken event tracking on WooCommerce, because a cached checkout page can serve a version of the page from before the Klaviyo tracking snippet loaded. Know what’s caching your checkout and cart pages before you start, because you’ll need to add exclusions.

A decision on historical data. Decide whether you want your existing order history imported into Klaviyo before flows go live, or whether you’re starting fresh from the connection date. A historical import changes what your welcome and win-back segments look like on day one, and it’s easier to plan for than to redo after flows are already sending.

Clarity on consent status today. If you’ve been collecting email addresses through WooCommerce without an explicit marketing opt-in — a common state for stores that added Klaviyo after launch — you need to know that before you import contacts, not after. Importing a list without consent status attached means every contact defaults to unconfirmed, which limits what you can legally send them until they take an action that counts as consent.

How to connect Klaviyo and WooCommerce step by step

Step 1: Install a WooCommerce-Klaviyo sync plugin

Install a plugin built to sync WooCommerce and Klaviyo from the WordPress plugin directory or through Klaviyo’s own integrations page — check Klaviyo’s current documentation for the plugin it recommends, since the specific one changes as WooCommerce’s plugin ecosystem updates. Activate it on a staging site first if you have one, because a sync plugin that conflicts with your theme or another plugin is much cheaper to find there than on a live store mid-sale.

Step 2: Generate API keys and connect the webhook

Generate a Klaviyo private API key with the permissions the plugin’s setup screen asks for, and paste it into the plugin’s connection settings inside WordPress. This step also registers one or more webhook endpoints — WooCommerce pushing event data to Klaviyo as it happens, rather than Klaviyo polling for changes. Confirm in your WordPress error log or the plugin’s own activity log that the webhook registered successfully; a silent failure here means nothing syncs and there’s no error message pointing you at why.

Step 3: Map WooCommerce events to Klaviyo metrics

Most sync plugins map WooCommerce actions — order placed, order fulfilled, order refunded, customer registered — to Klaviyo metrics automatically, but check the mapping screen rather than assuming it’s complete. This is where teams on a heavily customised checkout (multiple payment gateways, a custom order status for backorders, a wholesale tier) find gaps: a custom order status might not be mapped to any Klaviyo event by default, which means orders in that status never trigger a flow.

Step 4: Turn on checkout abandonment tracking

Enable Klaviyo’s tracking snippet across your site, and confirm it loads on the cart and checkout pages specifically, not just the homepage and product pages. On WooCommerce this snippet needs to fire an identify call as soon as a shopper enters an email address at checkout — before they submit the order — for an abandonment flow to have anything to send to. This is the step that most commonly fails silently, covered in detail below.

Step 5: Add consent fields to checkout

Add explicit marketing consent checkboxes to your WooCommerce checkout form — one for email, a separate one for SMS if you’re collecting phone numbers for Klaviyo SMS — and confirm the plugin passes that consent status through to the Klaviyo profile on order placement. A checkout that collects an email address without ever asking for consent means every resulting profile is a suppressed or unconfirmed contact in Klaviyo, not a subscriber you can email.

Step 6: Test and verify the sync

Place a real test order, abandon a checkout deliberately without completing payment, and check both instances in Klaviyo’s metrics log within the hour. Confirm the order event carries the correct order value, items, and currency, and confirm the abandoned checkout event created or updated a profile with the email you entered. Don’t rely on flow performance dashboards to verify this — check the raw event log first, because a flow can show zero sends for two entirely different reasons: no one triggered it, or the trigger event never arrived.

Which events fire reliably, and which don’t

Order placed, order fulfilled, and order refunded are the most dependable events in a WooCommerce-to-Klaviyo sync, because they’re generated server-side by WooCommerce itself and pushed through the webhook regardless of what a shopper’s browser does. If your webhook is live and mapped correctly, these will fire consistently, including for shoppers running an ad blocker that would otherwise strip client-side tracking scripts.

Product viewed and added-to-cart events are less dependable, because they depend on the Klaviyo tracking snippet executing in the shopper’s browser on every relevant page. A theme that lazy-loads product pages, a page builder that renders content after the initial page load, or a caching setup serving a stale page can all cause these events to under-report. If your product-viewed volume in Klaviyo looks low relative to your actual site traffic, check whether the snippet is present on every product page template your theme uses, not just the default one.

Checkout started and checkout abandoned are the events most specific to this platform pairing, and the ones worth treating with the most scepticism until you’ve verified them directly. Unlike Shopify, where checkout is a hosted, uncustomisable Shopify-owned page that the platform instruments by default, WooCommerce checkout is a page on your own site, built from your theme and whatever checkout plugins you run. That flexibility is also the risk: anything that changes how that page loads — a new checkout plugin, a theme update, a caching rule — can silently break the identify call the abandonment flow depends on.

The step most teams get wrong

The single most common failure in a WooCommerce-to-Klaviyo setup is a caching or optimisation rule that excludes the checkout page from dynamic content but doesn’t know to make an exception for the Klaviyo tracking script. Page caching exists to serve a static, fast copy of a page instead of regenerating it on every visit — sensible for a product page, dangerous for checkout, where the whole point of the tracking snippet is to run live and capture the exact shopper currently on the page.

When this goes wrong, it doesn’t throw an error. The checkout page loads fine, the order still completes fine if the shopper finishes buying, and nothing in your WooCommerce admin looks broken. What happens is quieter: a shopper enters their email, doesn’t finish the purchase, and Klaviyo never receives the identify call that would have started the checkout-abandonment flow. The flow shows zero triggers, and because nothing errors, it’s easy to assume the flow itself is misconfigured rather than the event feeding it. Teams spend hours rebuilding flow logic that was never the problem.

Check this directly rather than inferring it from flow performance: open your caching plugin’s page-level exclusion or cache-bypass settings, and confirm the checkout page — and ideally the cart page too — is excluded from full-page caching, not just marked “dynamic” in a way that only affects pricing. Then load the checkout page in a private browser window and confirm, using your browser’s network tab or Klaviyo’s own tracking preview if it offers one, that the Klaviyo script tag is present in the page source you actually received, not just in the theme file you’d expect it to come from. If it isn’t there, the exclusion isn’t working yet, whatever the plugin’s settings screen claims.

How to verify the sync is working

Verification on WooCommerce needs to happen at two levels, because a plugin reporting “connected” tells you the API keys are valid, not that events are actually arriving.

At the connection level, check the plugin’s own sync log or activity feed inside WordPress for recent successful webhook deliveries, and check that the timestamp on the most recent one is recent — not from the day you first installed it. A webhook that worked once during setup and then silently stopped is a common failure mode after a WordPress or plugin update changes something the sync plugin depended on.

At the event level, go into Klaviyo’s metrics section and look at the raw event volume for Placed Order, Checkout Started, and any custom events over the last seven days, compared against your actual order count for the same period from WooCommerce’s own order list. A material gap between the two — Klaviyo showing noticeably fewer Placed Order events than WooCommerce shows completed orders — points at either a webhook delivery problem or an order status your plugin isn’t mapped to.

Run this check monthly, not just at setup. A plugin update, a theme change, or a new payment gateway added later are all points where the sync can quietly regress, and the cost of catching it a month late is a month of flows that should have sent and didn’t.

How checkout abandonment differs from Shopify’s

On Shopify, checkout is a single, platform-owned page that every store uses, which is part of why Shopify’s Klaviyo app can capture abandoned-checkout data so reliably: there’s one checkout implementation to instrument. On WooCommerce, checkout is built from your theme and whatever checkout-page plugin or builder you’re running, which means there’s no single implementation Klaviyo’s tooling can guarantee will work — it depends on your specific setup firing the tracking snippet correctly.

The practical consequence is that a checkout-abandonment flow on WooCommerce needs its trigger event verified store by store, not assumed to work the way it would on a template Shopify store. It also means that if you rebuild your checkout — a new checkout plugin, a move to a different theme, a redesign — the abandonment flow’s trigger is one of the things you need to re-verify, not just the visual design.

WooCommerce’s own cart abandonment is also weaker than Shopify’s for one specific reason: WooCommerce doesn’t natively track an abandoned cart the way Shopify does for a logged-in or cookie-identified shopper who never reaches checkout. Most of what gets called “abandoned cart” in a WooCommerce Klaviyo setup is really abandoned checkout — a shopper who entered an email at checkout and left before paying. If you want to also catch shoppers who added an item but never started checkout at all, that depends on your tracking snippet capturing an identified add-to-cart event, which needs the shopper to already have an email on file from a previous visit, account, or the checkout attempt itself.

Consent fields under GDPR on a WooCommerce checkout

WooCommerce’s default checkout customer base skews more EU-exposed than the average Shopify store, partly because WooCommerce is popular with European small and mid-sized retailers running on WordPress hosting already used for the rest of their site. That makes consent capture at checkout a bigger part of getting this integration right than it would be for a US-only Shopify store, not an afterthought bolted on after flows are live.

Klaviyo records email and SMS consent as separate fields on a profile, so a single checkbox covering both marketing channels doesn’t give you a defensible record of consent for each one individually. Add distinct checkboxes for email marketing and SMS marketing if you collect phone numbers, and confirm your sync plugin passes the state of each checkbox through to Klaviyo as a distinct consent field on the profile, rather than a single opted-in flag.

What counts as valid consent, how long a consent record needs to be retained, and what a double opt-in needs to look like for your specific markets are all questions for counsel, not for a plugin’s default settings. Confirm the specifics of GDPR consent requirements — and any other regional requirement relevant to where your customers are — with someone qualified to advise on it before you rely on a checkout checkbox as your record of consent.

Klaviyo’s own benchmark data, drawn from more than 183,000 brands on the platform, puts 41% of email revenue on average from automated flows rather than one-off campaigns (Klaviyo, vendor-reported) — which is the practical reason getting the sync right matters more than it might first appear. A broken checkout-abandonment trigger or an unmapped order status doesn’t just cost you one flow; it costs you a meaningful share of what email is supposed to generate for the business.

What breaks at scale on WooCommerce specifically

As order volume grows, two WooCommerce-specific issues tend to surface that don’t show up in a low-volume test. The first is webhook delivery under load: WordPress hosting that’s fine for a handful of orders an hour can start dropping or delaying webhook deliveries during a sale spike if the hosting environment isn’t sized for the concurrent request volume. If you notice sync gaps clustering around your highest-traffic hours, talk to your host about webhook and outbound request handling, not just page load speed.

Plugin conflicts introduced by unrelated updates are the second issue. WooCommerce itself, your theme, and your sync plugin are maintained by different teams on different release schedules, and an update to any one of them can change behaviour the others depended on. A checkout-page redesign from a theme update, for instance, can move where in the page template the Klaviyo snippet loads relative to the checkout form, breaking the timing of the identify call without changing anything in the sync plugin’s own settings. Test the sync again after any theme, checkout plugin, or major WooCommerce update — not just after changes to the Klaviyo connection itself.

Getting the sync right the first time, and re-verifying it after every change that could touch checkout, is a lifecycle flows problem before it’s a technical one: a flow can only be as good as the event data reaching it, and on WooCommerce that data path runs through more moving parts than it does on Shopify. Pointerflow’s lifecycle flows work starts from checking exactly this — what’s actually reaching Klaviyo versus what a dashboard implies is reaching it — before touching flow copy or timing. If you want a sense of what a fixed sync is worth in flow revenue before you commit time to it, the flow revenue calculator gives a working estimate, and the setup process described here is the kind of groundwork covered in more depth for scaling brands moving off a patchwork of plugins and onto a sync they can actually verify.