The Test Bench240 guides, 20 benches
Conversion.sale
The Test Bench - a field guide to conversion for small online businesses
Home / Bench 16 - CRO on WooCommerce and WordPress / Guide

WooCommerce Analytics and GA: Two Views of the Same Store

WooCommerce analytics knows orders and products in platform terms; Google Analytics knows sessions and journeys in its own terms. Used together with clear definitions, they agree enough to act on. Mixed carelessly, they argue.

Published 24 October 2026Evidence checked on 24 October 2026Small online stores, global English edition

The short answer

Use WooCommerce analytics as your record of orders, revenue and product performance, because it sits closest to transactions. Use Google Analytics, where you have it configured, for acquisition, landing page and journey questions, because it sees sessions before a buyer reaches the store machinery. Expect the systems to differ on totals and rates because they define sessions, attribution and timing differently. Pick one source per question, write the definition beside the number in your log, and judge trends within one system at a time. The conversion value is not more data; it is fewer arguments about whose number is right.

What the WooCommerce view does best

WooCommerce analytics, in current versions, reports revenue, orders, products, categories and coupons from store data, with filters that suit merchandising questions: which products earn, which coupons are used, how a category performs over a period. Start conversion investigations there when the question is about what sold. Its view of traffic is thinner, so a product with weak sales might have a traffic problem WooCommerce alone cannot explain. Check current WooCommerce documentation for report availability and definitions in your version and for any extensions that alter how orders are counted, such as subscriptions or bookings.

What the GA view adds

Google Analytics describes sessions, sources, landing pages and events under its own definitions, documented in Google Analytics support. That view answers where visitors came from, which content or campaign pages they entered on, and how journeys proceed before purchase. Enhanced measurement and ecommerce events depend on how GA was integrated, often through a plugin or tag setup, so verify that product views, add to cart and purchase events are actually being recorded before analysing them. A beautiful funnel built on missing events is fiction. Test with a real order and confirm it appears, allowing for reporting delay, before using GA to judge a page.

Why the numbers differ, normally

Sessions in GA and visits or activity in WooCommerce are not the same unit. Attribution windows assign an order to different channels. Ad blocking, consent choices and browser restrictions affect GA more than server side order records. Refunds, manual orders and test orders may appear in one system and be excluded in the other depending on configuration. None of this means either system is broken. It means a monthly report should name its source per line: orders from WooCommerce, landing sessions from GA, and never a conversion rate calculated by dividing one system orders by the other system sessions.

Assign each question one home

Write your standing questions and their home system. What sold, and which products are slipping: WooCommerce. Which landing pages receive traffic that buys: GA for entry, reconciled with WooCommerce for orders, read cautiously. Which campaigns send sessions: GA. Whether checkout changes coincided with order change: WooCommerce orders over whole weeks, with a note of the change date. This assignment, kept in the log, stops the monthly meeting from relitigating definitions. When a question cannot be answered by either system, that is a signal to add observation, such as watching session behaviour or reading support messages, not to force an answer from a report.

A two system monthly rhythm

Monthly, in order: WooCommerce orders, revenue, top and slipping products, coupon use. Then GA sessions by main channel, top landing pages with their purchase outcomes, and one journey question you chose in advance. Then one manual phone journey for the worst mismatch, as in the platform rhythm of analytics and behaviour tools for CRO. Log definitions and changes. That division uses each system for its strength, keeps the reading under an hour for a small store, and produces decisions, which is the only output analytics is for.

Sources and evidence on the record

Evidence basis: Platform guide. Behaviour described is as documented by the platform in the sources listed below, checked on 24 October 2026; platform behaviour changes, so re-check before a rebuild. Applies when: You read both WooCommerce analytics and Google Analytics

Next on the bench

Bench 16 - CRO on WooCommerce and WordPress WooCommerce and WordPress Conversion: The Working Guide WooCommerce and WordPress give you control Shopify does not, and charge you for it in speed, maintenance and checkout decisions. This guide maps where that control helps conversion and where it quietly taxes it. Bench 16 - CRO on WooCommerce and WordPress WordPress Speed: Hosting, Caching and Images in That Order WordPress speed advice often starts with plugins and images because they are visible. The order that works is hosting first, caching second, then images, plugins and theme weight on a foundation that can respond. Bench 16 - CRO on WooCommerce and WordPress WooCommerce Product Pages: Fixing the Defaults That Cost Sales A default WooCommerce product page is orderly but generic: gallery, summary, tabs and related products in fixed places. Keep what works, move what buyers need earlier, and add only the information your products require. Bench 13 - Analytics and behaviour tools Analytics and Behaviour Tools for CRO: The Working Guide Analytics answers where buyers are lost; behaviour tools show what losing them looked like. This guide sets up a small, honest measurement stack a one-person business will actually use every week.