WooCommerce conversion tracking: the plugin-sprawl problem and how to fix it

WooCommerce tracking usually breaks for one reason: plugin sprawl. Three plugins each install their own GA4 tag, two of them also fire a purchase event, and none of them agree on what the order value includes. The fix is not a better plugin — it is picking exactly one source of truth for the dataLayer, removing everything else, and verifying the purchase event against the order total in WooCommerce itself.

Why WooCommerce specifically gets messy

WordPress is a plugin ecosystem, and every marketing plugin wants to own your tracking. A typical store accumulates:

• A general SEO or marketing plugin with "Google Analytics integration" toggled on.
• A dedicated GA4 or GTM plugin.
• A Meta or Google Ads plugin that also injects its own base pixel.
• A theme with a settings field for a measurement ID, filled in two years ago by a developer nobody remembers.
• A hardcoded snippet in the child theme's header.php.

Each of these works in isolation. Together they produce duplicate pageviews, duplicate purchases, and a dataLayer that changes shape depending on which plugin loaded last. Because WooCommerce is self-hosted, nothing forces coordination — this is the "single GA4 property" audit check failing on a live store, and it is by far the most common WooCommerce finding.

Step 1: Find out what you actually have

Before installing anything, inventory what is already running.

1. Open your storefront, view source, and search for G- and AW- and GTM-. Count distinct IDs and count repeats of the same ID. Both matter.
2. Search for fbq( and ttq. to find advertising pixels.
3. Then repeat on a product page and on the order-received page — plugins often inject differently per template.
4. List every active plugin with a tracking or analytics feature, including ones whose main purpose is something else.

You will usually find at least one tag you did not know about. That is the point of the exercise.

Step 2: Pick one source of truth

There are three defensible architectures. Pick one; do not blend them.

Approach	Good for	Cost
One GTM plugin + your own container	Stores that run multiple ad platforms	Most control, needs GTM knowledge
One dedicated GA4/ecommerce plugin	Single-channel stores that just need GA4 right	Least effort, least flexibility
Hardcoded in a child theme	Developer-maintained stores with strict CSP	Full control, every change is a deploy

For most stores running more than one ad platform, a single well-maintained GTM plugin that pushes a proper ecommerce dataLayer is the best trade — you get one clean data source and can add vendors without touching WordPress again. What GTM actually is if you are deciding.

Whichever you pick, disable the analytics features of every other plugin. Not uninstall necessarily — many are doing other useful jobs — just turn off their tracking toggles, one at a time, checking the page source after each.

Step 3: Get the ecommerce dataLayer right

WooCommerce has server-rendered templates and AJAX cart interactions, which is where the detail matters:

• view_item on the product page, with the real SKU, name, category, and price.
• add_to_cart on the AJAX add, not on the page load of the cart. This is the event most commonly wired to the wrong trigger, because plugin-based implementations often fire it on cart page view instead.
• begin_checkout on the checkout page.
• purchase on the order-received page, once.

The purchase event is where money gets misreported. Decide explicitly what the value should represent, and check it against the WooCommerce order:

• Does value include tax? Shipping? Most stores should send revenue consistent with how they report it internally, and be consistent forever after.
• Does it use the customer's currency or the store's base currency, in a multi-currency store?
• Are discounts and coupons deducted?
• Does transaction_id equal the WooCommerce order number, so refunds can be matched later? Handling refunds and returns in GA4 depends on this.

Step 4: The order-received page problem

WooCommerce's thank-you page is reachable by refresh. Refresh it three times and a naive implementation fires three purchase events with the same transaction ID.

GA4 does deduplicate on transaction_id to a degree, but do not rely on it as your only defence — and other platforms are less forgiving. Two robust patterns:

1. Server-side flag. Mark the order as "conversion tracked" when the event is emitted, and do not emit again for that order.
2. Session storage guard. Record the transaction ID in the browser's session storage and skip the push if it has already been sent. Weaker, but easy.

Duplicate transactions in GA4 covers the diagnosis when it is already happening.

Step 5: Consent, if you serve the EU or UK

WordPress consent plugins vary enormously in quality. What you need is one that sets Consent Mode v2 defaults before any tag loads and updates them on the visitor's choice — including ad_user_data and ad_personalization, not just the two v1 signals.

Test both directions: tags must not fire before consent, and must fire after it. Half-tested consent implementations that block everything permanently are extremely common on WooCommerce, and they present as "our European traffic doesn't convert".

Step 6: Verify against WooCommerce, not against itself

The only meaningful test is reconciliation. Place a real test order and compare, for that single order:

• GA4 purchase event: one occurrence, correct value, correct transaction ID.
• Google Ads: one conversion, correct value.
• Meta: one purchase, deduplicated if you also run the Conversions API.
• WooCommerce order total: the number all of the above should agree with.

Then check a full day: WooCommerce order count versus GA4 purchase count. A gap under about 5% is normal from consent and blockers. Over 20% means something is wrong. A GA4 count higher than WooCommerce means duplicates.

For ongoing coverage, the WooCommerce setup guide covers the install path, and scheduled synthetic journeys can walk the funnel automatically so a plugin update does not silently take tracking down for a month.

FAQ

Which WooCommerce tracking plugin is best?

Less important than the rule: run exactly one. Any actively maintained plugin that pushes a proper GA4 ecommerce dataLayer will outperform three good plugins fighting each other.

Why does my WooCommerce revenue in GA4 not match my orders?

The three usual causes are duplicate purchase events from the refreshable thank-you page, a value that includes or excludes tax and shipping differently from your WooCommerce reports, and orders placed through channels the tracking never sees. Reconcile a single order first, then a full day.

Do I need GTM for WooCommerce?

No, but it helps once you run more than one advertising platform. With GTM you add the next vendor in the container instead of installing another plugin — which is how the sprawl problem started.

Will a plugin update break my tracking?

It can, and it does — a plugin update, a theme update, or a WooCommerce major release are the three most common causes of silent tracking loss on WordPress. Re-verify after each, or monitor continuously.

How do I stop duplicate purchase events on refresh?

Guard the emit: either flag the order server-side once tracked, or record the transaction ID in session storage and skip repeats. Do not rely solely on platform-side deduplication.

Check what is actually loading on your store right now — the free tracking audit counts distinct GA4 properties, checks Meta and Google Ads tags, and flags consent gaps on any URL.