Conversion tracking for WooCommerce, done right

WooCommerce gives you full control of your store, which is exactly why its tracking breaks in ways Shopify's never does. You have plugins stacked on plugins, a caching layer trying to make everything fast, and a checkout you can edit but probably should not. Here is what actually goes wrong on WooCommerce, and what a clean setup looks like.

Why WooCommerce is its own special case

Because it is WordPress, nothing is locked down. That freedom is the problem: every tracking plugin assumes it is the only one, your caching and optimisation plugins rewrite the page after the fact, and a theme update can quietly change the order-received template your purchase event depends on. Most WooCommerce tracking issues are not one broken tag, they are several plugins fighting over the same event.

The five things we see break on WooCommerce

1. Purchase fires two or three times

A Google integration, a Meta pixel plugin and a hand-pasted snippet each fire their own purchase on the thank-you page. The same order is counted several times, your ROAS looks unreal, and reported revenue climbs further above what WooCommerce actually took.

2. Caching serves a stale page and the event never fires

Page cache and optimisation plugins are built to speed up your store, but they can serve a cached order-received page or defer and strip the inline script that populates your data layer. The purchase silently never fires, and because sales keep landing in WooCommerce nobody notices GA4 has gone quiet.

3. Everything is browser-side, so iOS and ad blockers eat it

If your Meta and Google events only fire in the visitor's browser, a large share of iOS and ad-blocked buyers are never counted. Server-side tracking or the Conversions API sends the sale from your server instead, so those buyers come back into view and your ad platforms stop optimising blind.

4. Consent plugins block tags instead of gating them properly

WordPress consent plugins are easy to install and hard to wire up. Very often they simply block your tags in the UK and EU rather than passing accept and decline into Google Consent Mode, so you lose a chunk of measurable revenue and are still not properly compliant.

5. Thin order data breaks your reports and audiences

Events fire but arrive without item IDs, categories, value or a unique transaction ID, because the plugin was never mapped to your product data. That breaks dynamic remarketing, catalogue matching and deduplication, and makes your ecommerce reports close to meaningless.

What a clean WooCommerce setup looks like

Done properly, one plugin or container owns tracking, and everything else is switched off so nothing double-fires. A single correct purchase event fires from the order-received page with full product and value data and a unique transaction ID, survives your caching layer, and flows to GA4, Meta and Google both in the browser and server-side, deduplicated. Consent Mode keeps you compliant without throwing measurable revenue away. When that is in place, GA4 and WooCommerce land within a few percent of each other and stay there.

Common WooCommerce tracking questions

Why does my WooCommerce purchase event fire twice?

Almost always because more than one plugin is tracking the same order. Pick one to own the purchase event and turn the others' tracking off, and the double count disappears.

Why did tracking stop after a caching or theme update?

A cached order-received page, a stripped inline script, or a changed thank-you template all stop the purchase firing while sales keep happening. It is the most common reason WooCommerce tracking "just stopped".

Do I need server-side tracking?

If iOS and ad-blocked buyers are a real share of your sales, yes. Server-side or the Conversions API sends the purchase from your server so those buyers are counted.

Datahound are analytics and ad-tracking specialists. We fix broken GA4, Meta CAPI and server-side tracking for WooCommerce and other ecommerce platforms. See pricing · Back to datahound.agency