The state of WooCommerce conversion tracking (2026)

A June 2026 study by stankiewiczgtm.pl statically audited 1,065 Polish shops to check how their conversion measurement is actually wired. It found that most WooCommerce shops make budget decisions on data they do not fully see. We have pulled out the WooCommerce slice here, because it is the platform this whole plugin family is built for, and because it came out worst. The second half of this guide turns the findings into checks: what our free tracking scanner looks at, how to read its grade, and which settings close the most common WooCommerce gaps.

WooCommerce is the worst-measured major platform

Across the platforms in the study, WooCommerce had the lowest adoption of almost every measurement signal that matters.

Signal	WooCommerce	Shoper	IdoSell	Shopify
GA4 installed	67%	100%	92%	90%
Google Ads conversion tag	31%	41%	70%	78%
Meta Pixel	43%	74%	88%	33%*
Server-side tracking	1%	1%	1%	14%
Cookie banner present	76%	86%	97%	80%

*Shopify Meta numbers are understated because its pixel runs in a sandbox a static scan cannot fully see.

The pattern is not that WooCommerce merchants care less. It is that WooCommerce gives you total freedom and zero defaults: nothing is measured until someone wires it, and on the hosted Polish platforms more of that wiring ships out of the box.

The four gaps that cost the most

Server-side tracking is effectively absent. Only about 2% of all shops measure server-side, and under 1% outside Shopify. Everyone else measures purely in the browser, the exact layer that ad blockers, Safari’s Intelligent Tracking Prevention and the redirect back from the payment gateway routinely cut before the purchase event reaches the analytics. The shops that see their true sales first hold the real advantage, not the ones that simply spend more on ads.

Warning: Measuring purely in the browser means ad blockers, Safari’s tracking limits and the payment-gateway redirect can cut a real purchase before it is counted, so browser-only numbers understate your true sales.

One in five shops double-counts GA4. When the same GA4 stream is wired both directly and through Google Tag Manager, every event is counted twice. Sessions and conversions inflate, and the ROAS you optimize against is wrong in your favor, which is the worst direction for it to be wrong.

One in three shops still ships dead Universal Analytics. UA stopped collecting in 2023. The leftover tags do nothing, but they are a clear sign the setup has not been touched since.

The cookie banner is mostly theatre. Over 80% of shops display a banner, yet EU research finds fewer than 15% are correct and two thirds of Consent Mode implementations contain technical errors. A banner without a proper default-denied Consent Mode signal is a compliance risk and quietly degrades your measurement at the same time.

Premium brands are not better

The study looked at premium brands separately, expecting the segment that invests in image and product to invest in data too. It does not. Premium brands measured as poorly as the mass market and were slightly worse on hygiene, with more tags firing without consent and the same rate of duplicate GA4. A brand selling a sofa for tens of thousands can still not know who bought it.

Where most shops actually sit

On the study’s A to E maturity scale, the market clusters in the middle and below: roughly 1% reach A, 7% B, 44% C, 28% D and 19% E. In other words, about half of shops have, at best, working basics, and almost one in five measure next to nothing.

What a static tracking audit can and cannot see

A static audit reads the page source and confirms which tags are installed; it cannot prove that a tag fires on a real purchase. That is the method of the study and of our scanner, and it sets the limits of every result.

What a static audit sees well:

• Measurement IDs in the HTML, such as GA4 (G-), Google Ads (AW-), Google Tag Manager (GTM-) and leftover Universal Analytics (UA-).
• Pixel loaders, such as the Meta Pixel (fbevents.js and fbq('init')) and the TikTok pixel.
• Consent Mode defaults, the gtag('consent', 'default', ...) call with denied signals.
• Cookie banners from common consent platforms, such as Cookiebot, Complianz, CookieYes, Borlabs or Usercentrics, and Polish banner wording.
• Server-side hints, such as a server_container_url or transport_url that sends tags to your own tagging server.

What it cannot see:

• Whether events fire. A GA4 tag in the source can still miss the purchase event on the thank-you page.
• Server-to-server traffic. The Meta Conversions API and server-side GTM run between servers, outside the page.
• Pages behind steps. A scan of the storefront does not walk through the cart, checkout and payment gateway.

Note: Treat every positive result from a static audit as a lower bound. A tag found in the source is installed; a tag not found may still exist on a server the scan cannot reach.

How the tracking scanner grades a shop

The free tracking scanner runs the study’s method on any public shop URL and returns an A to E grade with a plain-language reason for each finding. It fetches the page you enter, follows up to three redirects, and, when the page loads a Google Tag Manager container, also fetches that public container file so GA4 and Google Ads IDs configured inside GTM count too.

Each check returns a status:

Check	What raises or lowers the grade
Server-side tracking	A server-side signal carries the largest single weight; browser-only measurement fails the check
GA4	A GA4 measurement ID passes; no GA4 fails
Consent Mode	A default-denied Consent Mode v2 state passes; a banner without it is a warning; neither fails
Google Ads conversion	An AW- conversion ID passes; without it the scanner shows an information note
Meta Pixel and TikTok	Detected pixels add to the score; Advanced Matching is reported when present
Meta CAPI	Always reported as not detectable from outside, never as missing
Duplicate GA4	GA4 wired both directly with gtag and through GTM lowers the grade
Multiple GA4 streams	Reported for you to confirm each stream is intended
Dead Universal Analytics	Leftover UA- IDs or analytics.js lower the grade
Cookie banner	Presence only; correctness is judged by the Consent Mode check

The scanner also names the detected platform, for example WooCommerce, Shopify, PrestaShop, IdoSell, Shoper or Magento. If the page it receives is nearly empty, for example because a bot challenge or a JavaScript-only shell blocked it, the scanner returns no grade at all instead of an unfair E.

What the scanner stores

Each scan stores the public hostname only, without paths or query parameters, together with the detected platform, the grade, the score and the findings, so that aggregate statistics can be published later. Your IP address is passed to Cloudflare Turnstile for the bot check and stored only as a SHA-256 hash, for the limit of 30 scans per hour. The scanner refuses localhost, private network addresses and non-web schemes. Findings are returned in English, Polish or German.

How to fix the common gaps in WooCommerce

Most WooCommerce shops fail first on consent and on GA4 hygiene, and both are fixable inside WordPress. Polski for WooCommerce covers the browser layer with three optional modules, all off by default and switched on in Polski > Modules.

Consent Mode: the Consent Manager module

The Consent Manager module adds a native cookie banner with three optional categories (analytics, marketing, preferences) next to the always-on necessary category. With Google Consent Mode enabled, which is its default, it prints the default consent state before any gtag or GTM code, at priority 0 in wp_head, with every signal denied except security_storage. When the visitor decides, it calls gtag('consent', 'update', ...), writes the choice to a cookie and records the decision in a consent log with CSV export.

The categories map onto Consent Mode v2 signals: analytics onto analytics_storage, marketing onto ad_storage, ad_user_data and ad_personalization, and preferences onto functionality_storage and personalization_storage. That default-denied call is exactly what the scanner’s Consent Mode check looks for.

Warning: The Consent Manager is marked beta. Only Polski’s own tags and scripts you mark with type="text/plain" data-polski-consent wait for consent; other third-party scripts and iframes still load before the visitor chooses.

GA4 events: the GA4 DataLayer module

The GA4 DataLayer module sends the GA4 ecommerce events view_item_list, view_item, add_to_cart, remove_from_cart, begin_checkout and purchase. It works in two modes: enter a GTM container ID and events go to window.dataLayer, or enter a GA4 measurement ID and the module loads gtag.js and sends events directly. The purchase event is sent once per order, protected by a cookie, so a reloaded thank-you page does not count the sale twice. Scripts load with defer, and you can send the SKU instead of the product ID as item_id.

One setting needs care. The module allows both modes at once, and then events go both to the dataLayer and directly to GA4. If your GTM container also contains a GA4 tag for the same stream, that is the duplicate GA4 pattern one in five shops has. Use one route per GA4 stream: GTM if you manage tags there, gtag.js if you do not.

Pixels: the Tag Manager module

The Tag Manager module loads common pixels from your own IDs, gated by consent category. Marketing tags include Meta Pixel, TikTok Pixel, Microsoft Advertising (Bing UET), LinkedIn Insight, Pinterest, X and Google Ads; analytics tags include Microsoft Clarity, Matomo, Plausible, PostHog, Hotjar, Inspectlet, Crazy Egg and Simple Analytics. Every tag is printed as an inert text/plain script that runs only after the visitor grants the matching category, so the module requires the Consent Manager. GA4 and GTM are deliberately not in this module, which keeps them from loading twice.

Server-side measurement

Polski covers the browser layer only: its Tag Manager makes no outbound request from PHP, and none of these modules sends conversions server-to-server. Server-side measurement needs a separate tagging server, typically a server-side GTM container that your web container reaches through server_container_url or transport_url. Once that is in place, the scanner’s server-side check can see the hint in your page source.

A practical order of work

1. Scan the storefront. Run the tracking scanner on your home page and note every fail and warning.
2. Remove dead weight. Delete leftover Universal Analytics code from the theme, old plugins and the GTM container.
3. Fix consent first. Set a default-denied Consent Mode state that loads before any Google tag, and connect your banner to it.
4. Choose one GA4 route. Keep GA4 in GTM or in gtag.js, not both, and confirm the purchase event in GA4 DebugView with a test order.
5. Add advertising tags you actually use. Google Ads conversion and Meta Pixel only for channels you run, behind marketing consent.
6. Plan server-side. Once the browser layer is clean, add a tagging server for the purchases browser-only measurement misses.
7. Scan again. A second scan confirms the source now matches the plan.

Tip: Run a real test order after every change. The scanner confirms what is installed, and only a test purchase confirms that GA4 records it.

Check your own shop

You do not have to guess where you sit. The free tracking scanner takes your shop URL and statically audits GA4, Google Tag Manager, Google Ads, Meta Pixel, Consent Mode, duplicate GA4, dead Universal Analytics and server-side signals, then gives you an A to E grade with a plain-language reason for each finding. Like the study, it is a static audit: it confirms what is installed, not whether every tag fires on a real purchase, so treat a positive as a lower bound.

If the scanner flags your consent or GA4 setup, Polski for WooCommerce prints a default-denied Consent Mode v2 state, sends GA4 ecommerce events and loads consent-gated pixels such as the Meta Pixel, which closes the two gaps most WooCommerce shops fail first.