WooCommerce CRO Technique

What revenue per visitor is and how to improve it on WooCommerce

Revenue per visitor helps you judge whether your WooCommerce store is making more money from the traffic it already gets, because it combines traffic and revenue into one number.

Summary

Bottom Line: Make RPV your headline metric only if you define it fully and never switch definitions: on WooCommerce that usually means either session-based RPV (purchase revenue ÷ sessions) or user-based RPV (purchase revenue ÷ total users)

  • “RPV” on its own is too vague to govern a business. You need the full formula in the metric name, such as Net RPV per session or Net RPV per total user. GA4 gives you separate metrics for sessions, totalUsers, activeUsers, purchaseRevenue and totalRevenue, and they are not interchangeable.
  • Session-based RPV is the cleanest operating version for most trading and acquisition work, because sessions are native to GA4 acquisition reporting and can be broken down by channel, country and device in standard reporting. That is an inference from Google’s reporting model rather than a platform rule.
  • RPV is a better headline than conversion rate alone because it forces you to care about both how often people buy and how much they spend. In visit-based terms, it is the combination of orders per visit and revenue per order.
  • GA4’s Average purchase revenue per active user is not the same thing as “revenue per visitor” unless you deliberately choose active users as your denominator. A literal visitor-style definition is closer to purchase revenue ÷ total users, and a trading definition is often purchase revenue ÷ sessions.
  • There is no trustworthy public, cross-platform RPV benchmark you can use as a target for a WooCommerce store. Available benchmark sources use different denominators and different samples: Adobe publishes revenue per visit and per visitor, Contentsquare publishes revenue per visit, and IRP publishes revenue per session. Those are directional vendor/platform comparators, not apples-to-apples norms.

How To Implement

  • Write the metric spec before you build any dashboard

    The minimum spec is: Revenue basis: purchase revenue, Woo Net Sales, Woo Total Sales, or another named numerator. Denominator: sessions, total users, or active users. Label: make the denominator and revenue basis part of the visible metric name. That sounds fussy, but it is the difference between a board metric and a vanity number. GA4 exposes separate definitions for sessions, totalUsers, activeUsers, purchaseRevenue and totalRevenue, and WooCommerce separately defines Gross Sales, Net Sales and Total Sales.

  • Choose the default working definition for StrategyFive-style trading

    The safest default for most WooCommerce stores is usually Net RPV per session: Woo Net Sales ÷ GA4 Sessions for reconciliation work, or GA4 Purchase Revenue ÷ Sessions for a pure GA4 version. That is because Woo Net Sales are Gross Sales – Returns – Coupons, while Google’s recommended ecommerce setup tells you to send purchase.value as the sum of item prices times quantity, excluding shipping and tax, and to pass discounted prices explicitly. This is a pragmatic alignment choice, not a universal law; if your store wants a tax/shipping-inclusive board metric, say so and use Woo Total Sales instead.

  • Standardise WooCommerce’s own reporting rules first

    In WooCommerce → Analytics → Settings, check:

    • Excluded Statuses — by default, Pending payment, Cancelled and Failed are excluded; Processing, On hold and Completed are included. Custom statuses are included unless you exclude them.
    • Date Type — Woo says Revenue and Order Reports can use Date created, Date paid or Date completed; default is Date paid.
    • Import Historical Data — run it if the reports are incomplete.
    • Data Status / Update Now / Clear Analytics Cache — use these if figures look stale after changes.

    This step matters because an RPV trend is only credible if Woo’s numerator is being counted the same way every time.

  • Make sure GA4 ecommerce is genuinely live

    Google’s ecommerce guidance says you need ecommerce events on the site, and once they are set up you typically see data within 24 to 48 hours. At minimum, verify purchase and refund; for diagnostics, also verify begin_checkout. If you use the official Woo integration, the free Google Analytics for WooCommerce plugin is configured in WooCommerce → Settings → Integration → Google Analytics for basic ecommerce and site analytics. If you need advanced event coverage such as full order refunds and coupon usage, Woo docs point to WooCommerce Google Analytics Pro, which supports GA4 and is documented as compatible with Cart & Checkout Blocks from WooCommerce 8.3 onward. Measurement note: do one real test order and one real refund before you start reporting RPV.

  • Build the GA4-side version first, even if you will later reconcile to Woo

    In GA4 or the GA4 Data API, you need the core fields for your chosen definition:

    • purchaseRevenue
    • sessions
    • totalUsers
    • optionally averagePurchaseRevenuePerUser or averageRevenuePerUser for comparison only, not as your headline unless you intentionally choose those denominators.

    If you want segmentation, Google’s schema supports deviceCategory, country, sessionDefaultChannelGroup, and newVsReturning.

  • In Looker Studio, create reusable calculated fields at the data source level for the pure GA4 version

    Google’s docs say data-source calculated fields can be reused in any report that uses that data source. Typical fields are:

    • Session RPV = Purchase revenue / Sessions
    • User RPV = Purchase revenue / Total users

    Build those in the GA4 data source so every report inherits the same formula, rather than letting different editors recreate it ad hoc in different charts.

  • If you need the WooCommerce-reconciled version, add Woo as a second source and blend at chart level

    WooCommerce lets you export Analytics tables to CSV, while Looker Studio lets you create chart-specific calculated fields on blended data but not data-source calculated fields on blended data. In practice, that means: export the Woo Revenue report or a curated daily order extract, connect it as a second source, blend it with GA4 on Date and any other stable join key you have, then create a chart-level field such as SUM(Net Sales) / SUM(Sessions). This gives you a reconciled RPV without pretending Woo and GA4 use identical native revenue definitions.

  • Segment the metric the same way every week

    The minimum useful cuts are:

    • Device — device category
    • Market — country
    • Source — session default channel group
    • New vs returning — newVsReturning where available in your model

    The rule is simple: the denominator must stay the same across all cuts. If the board metric is “Net RPV per session”, every segment must still be “per session”.

  • Use WooCommerce Order Attribution as a supporting view, not as your RPV source of truth

    In WooCommerce → Settings → Advanced → Features → Order Attribution, Woo can capture order origin, source type, UTM campaign, medium, device type and session page views, and show order origin in WooCommerce → Orders. That is useful for debugging source and device performance from the order side. It is not a replacement for GA4 because Woo’s own documentation says attribution is last-click, stored only when an order is placed, and the cookies expire with the visitor’s session.

  • Note the WooCommerce platform caveats

    There is no classic-shortcode vs Blocks difference in the RPV formula itself; this is a measurement technique, not a template change. The only implementation difference that matters is event collection: if your store uses Cart & Checkout Blocks, make sure your GA4 method explicitly supports them. Also note that since WooCommerce 8.2, HPOS is stable and default for new installs, so any custom export or SQL route you use for reconciliation must be HPOS-aware.

How To Measure

The key KPI is your agreed RPV definition, trended over time and read by device, market, source, and new vs returning using the same denominator everywhere. In GA4 terms, the building blocks are purchaseRevenue, sessions, totalUsers, deviceCategory, country, sessionDefaultChannelGroup, newVsReturning, and the ecommerce events purchase, refund and begin_checkout. In Looker Studio, create a reusable GA4 data-source field for the pure GA4 version, and a blended chart-level field if you need a Woo-reconciled numerator. Success looks like three things happening together: one agreed metric name used in every report, the same trend direction in GA4 and Looker Studio, and only a small, explainable gap between GA4 and Woo order totals rather than random mismatches.

The operating metrics beneath RPV should be conversion rate and AOV. In WooCommerce reports, Average Order Value is Net Sales ÷ Orders. In Adobe’s visit-based metric language, orders per visit is effectively conversion rate, and revenue per order is AOV; together they explain why revenue per visit moved. Use those beneath the headline to diagnose whether RPV changed because more visitors bought, because baskets got larger, or both.

The guardrail metrics that must not get worse are:

  • Conversion rate and AOV in the same segment, so you can see whether an RPV rise is genuine or just a denominator artefact.
  • Transactions / orders reconciliation, so a tracking break is not masquerading as a performance change. Woo and GA4 both document refunds and revenue separately enough for this QA.
  • Sampling and quota health in Looker Studio, because GA4-connected reports can be sampled, are subject to Data API quotas, and Looker Studio does not flag sampled GA data in the report itself.
  • Consent and attribution coverage, because Woo’s own Google Analytics docs warn that consent requirements can create discrepancies between store data and Google reporting.

Pitfalls

  • Myth: “RPV is just GA4’s average purchase revenue per active user.” It is not, unless you deliberately chose active users as the denominator. GA4 explicitly distinguishes totalUsers, activeUsers, sessions, purchaseRevenue and averagePurchaseRevenuePerUser, so using the canned metric as a shortcut changes the meaning of the number.
  • Mistake: reconciling Woo Total Sales to GA4 Purchase Revenue without noticing shipping and tax. Woo Total Sales include shipping and tax, while Google’s recommended purchase value excludes them; if you compare those directly, the gap is partly definitional, not necessarily a tracking bug.
  • Mistake: assuming discounts net off automatically in GA4. Google’s discount guidance is explicit: GA4 does not subtract discount from price automatically, so you must pass the discounted item price if you want accurate revenue metrics.
  • Myth: “There must be an industry-average RPV target I can compare to.” There is no credible public benchmark you can treat as cross-platform truth. Adobe, Contentsquare and IRP all publish different denominator conventions and different samples, so baselining your own store is safer than chasing somebody else’s number.
  • Mistake: using Woo Order Attribution as a full traffic denominator. Woo says this feature is session-based, last-click, cookie-backed, and only stored when an order is placed. That makes it useful for order-side context, but not for a storewide RPV denominator.
  • Mistake: trusting every Looker Studio session total at face value. Google documents three gotchas: GA4 connector quotas, unflagged sampling, and some stacked bar configurations that can inflate or double-count sessions. If the RPV chart looks wrong, check the report mechanics before you change the site.

Examples

FAQs

Sources & Further Reading

Want us to implement this for you?

We run measured CRO consultancy for WooCommerce. If you want help prioritising, testing & implementing these improvements, tell us about your store.

Book Pilot

About This Page

  • Written By: Eliot Webb – Founder & WooCommerce CRO Consultant
  • Last Reviewed: 22 Jun 2026
  • Last Updated: