Every example and amount on this page is illustrative. It shows the method and is not a benchmark, a quote or advice.
What Web Analytics Measures in an Online Store
Web analytics measures what shoppers do on an online store, from arriving on a page to completing an order. It records actions as events and groups them into visits, people, orders and monetary outcomes. The useful question is not simply how many events occurred, but what each count represents and how the counts relate.
A session is a period of activity on the store. One shopper can generate several sessions—for example, one visit from a paid ad and another after returning through an email. A user is the identified or inferred shopper associated with that activity. User counts depend on the tracking method, device, browser and consent settings, so they are not automatically the same as the number of individual people.
An order is a completed purchase record, usually containing products, quantities, discounts, shipping and taxes according to the store’s setup. Revenue is the monetary value assigned to those purchases by the reporting system. Before comparing revenue across reports, check whether it includes taxes, shipping, discounts, cancellations, refunds or returns. A storefront dashboard may show order value at checkout, while a finance report may recognise only revenue that remains after adjustments.
Conversion rate expresses how often store activity produces an order. In ecommerce reporting, it is commonly framed as the share of sessions that result in a purchase, although some systems use users, visitors or orders as the denominator. Those choices produce different results. A returning shopper with three sessions and one order affects a session-based rate differently from a user-based rate.
These measures answer different questions: sessions show visit volume, users describe the tracked audience, orders show purchase count, revenue shows sales value, and conversion rate connects activity with purchasing. Keep the definitions and date range consistent before using them together; otherwise, a higher revenue figure may reflect larger orders rather than more customers or better conversion.
The Core Formula: From Visits to Conversion Rate
The basic formula is: conversion rate = conversions ÷ opportunities × 100. In ecommerce, the numerator must be defined first. It might mean completed transactions, or the number of distinct users who completed at least one transaction. Do not use visits, users and transactions interchangeably; each produces a different rate.
A session-based conversion rate is completed transactions ÷ sessions × 100. It answers: “How often did a visit produce an order?” This is useful for evaluating site and checkout performance. A user-based conversion rate is converting users ÷ users × 100. It answers: “What share of people purchased?” It counts each user once, so repeat visits do not add extra opportunities to the denominator.
A transaction-based figure usually means transactions ÷ users or transactions ÷ sessions. That is not necessarily a conversion rate. It measures purchase frequency or orders per shopper or visit. If one shopper places multiple orders, transactions ÷ users can exceed 100%; if one session contains multiple orders, transactions ÷ sessions can do the same. Calling either figure “conversion rate” without naming the denominator can lead to the wrong decision.
The reporting period and scope must also match. Use transactions and sessions from the same date range, store, channel definition and currency context. Decide whether the numerator includes only completed orders or also cancelled, failed or refunded orders, then apply that rule consistently. For most storefront performance questions, report completed transactions ÷ sessions and label it explicitly. For customer acquisition and retention questions, report converting users ÷ users. The arithmetic is simple; the denominator determines what the result actually says.
| Metric | Formula | What it measures |
|---|---|---|
| Session conversion rate | Completed transactions ÷ sessions × 100 | Orders produced by visits |
| User conversion rate | Users with at least one transaction ÷ users × 100 | Shoppers who purchased |
| Orders per user | Completed transactions ÷ users | Purchase frequency, not a bounded conversion rate |
A Worked Example With Real Ecommerce Numbers
As an illustration only, suppose a Shopify store records 2,500 sessions in May. Its analytics report shows 60 purchase events and $7,200 in purchase revenue. The reported conversion rate is 60 ÷ 2,500 × 100 = 2.4%. That is a valid event-based result, but it is not yet the revenue figure finance should use.
The back office contains 60 orders at $120 each. Four were cancelled before fulfilment, and six of the remaining orders were returned and fully refunded. That leaves 50 delivered orders that were not returned. Realized revenue is therefore 50 × $120 = $6,000. The analytics revenue is $1,200 higher because it includes the four cancelled orders ($480) and six returned orders ($720).
Which Tools Capture Each Part of the Picture
GA4 is the behavioral layer. It records sessions, landing pages, engagement events, funnel steps and purchase events, then applies its own user, session and attribution rules. Use it to answer questions such as “Which landing pages preceded checkout?” or “How did mobile shoppers move through the funnel?” Do not treat GA4 purchase revenue as the store’s accounting revenue without checking event implementation, consent effects, refunds and attribution settings.
Shopify or another commerce platform is the order layer. It knows the order number, products, discounts, taxes, shipping, customer and order status. Use it as the operational reference for orders and merchandise sold. Its sales total may still differ from realized revenue if it includes cancelled orders, pending payments or refunded amounts. Define whether the figure is gross sales, paid orders, refunded sales or delivered revenue before comparing it with any other system.
Ad platforms are reporting an attributed slice of performance, not an independent order ledger. Meta, Google Ads and other platforms may each claim credit for the same purchase under different attribution windows. Their conversion value is useful for evaluating campaigns within that platform, but it should not be added across platforms or expected to equal Shopify revenue. Compare spend directly with the platform’s own attributed conversions, then compare total spend with total store revenue using a separate MER calculation.
A tag manager, such as Google Tag Manager, deploys and manages tracking tags; it is not the source of truth for orders or profit. It can send an event to GA4, an ad platform or both, but it does not validate whether the event represents a completed, delivered order. A profitability tool connects these sources and applies financial definitions consistently. For example, ORVX connects to Shopify and advertising accounts, calculates realized revenue from delivered orders, derives COGS and profit margins, and reports contribution after advertising by product and collection. That is the basis for calculating product profitability after COGS, returns and ad spend.
| System | Primary job | Do compare | Do not compare directly |
|---|---|---|---|
| GA4 | Shopper behaviour and site journeys | Sessions, events and funnel steps within GA4 | GA4 purchase revenue against booked or realized revenue without definition checks |
| Commerce platform | Orders, products, customers and order status | Orders and product quantities within the platform | Its sales total against ad-platform conversion value |
| Ad platforms | Campaign spend and attributed conversions | Spend and attributed results within one platform | Meta conversions plus Google conversions as unique orders |
| Tag manager | Tracking-tag deployment | Tag firing and event payloads during QA | Tag activity as proof of profit or a completed order |
| Profitability tool | Realized revenue, costs and profit | Revenue, COGS, returns, ad spend and margins under one definition | Profit figures against GA4 or ad-platform revenue without aligning scope |
The Tracking Mistakes That Make the Number Wrong
A purchase event is not the same thing as an order. If a confirmation page fires on every reload, one customer can create two or three purchase events. With 100 actual orders and 108 purchase events, an event-based report overstates orders by 8%. If reported revenue is $12,000, the same duplicate events could show $12,960 unless the platform deduplicates them. The error then flows into conversion rate, average order value and attributed revenue.
Consent loss creates the opposite problem: some shoppers buy but never become visible to the analytics tool. Suppose 100 orders were processed but only 80 purchase events were recorded. A report showing 2,000 sessions and 80 purchases calculates 4.0% conversion; the store's operational order count is 5.0%. Payment redirects can create another distortion by breaking the session or assigning the return visit to a payment provider rather than the campaign that generated the sale.
Internal traffic and bots contaminate the denominator. Ten staff sessions and 200 automated page views added to 2,000 genuine sessions make a 100-order store appear to convert at 4.5% instead of 5.0%. Bot activity can also inflate page views, landing-page visits and bounce-related metrics without representing buying intent. A sudden increase in traffic without a corresponding increase in product views, carts or orders should be treated as a measurement question before it becomes a marketing conclusion.
Attribution differences are not necessarily arithmetic errors; they are different allocation rules. An ad platform may credit a purchase after an impression or click, while analytics may use a different lookback window, channel definition or last-touch rule. Three platforms can therefore claim credit for the same $100 order. Adding those reported revenues produces fictitious revenue, even though each platform's attributed count may be internally consistent.
Timezone mismatches move orders across reporting periods. A purchase at 11:30 p.m. in the store's local time may appear on the next date in a UTC-based report, changing daily revenue and month-end conversion. Refunds create a separate mismatch when gross purchase revenue is compared with cash retained: $10,000 of orders less $1,500 of refunds is $8,500 realized revenue, not $10,000. For profitability, use delivered orders and account for returns and cancellations; product profitability separates revenue from the costs and refunds that determine what the sale actually contributed.
| Distortion | What gets overstated or understated | Arithmetic example |
|---|---|---|
| Duplicate purchase events | Orders, conversion rate and revenue overstated | 100 orders recorded as 108 events = 8% overstatement |
| Consent loss | Observed conversions understated | 80 tracked purchases ÷ 2,000 sessions = 4.0%, while 100 actual orders ÷ 2,000 = 5.0% |
| Refunds and cancellations | Retained revenue overstated | $10,000 gross orders − $1,500 refunds = $8,500 realized revenue |
Turning the Result Into a Profitability Decision
A reliable conversion rate is an input to a profitability decision, not the decision itself. Pair it with contribution margin—the selling price left after product cost, fulfilment, payment fees and other variable costs—and customer acquisition cost (CAC). For product-level examples of this calculation, see how to calculate product profitability.
As an illustration only, suppose Channel A produces 40 orders from 1,000 sessions: a 4% conversion rate. Its average order value is $120, and contribution before advertising is $54 per order. With $1,600 in ad spend, CAC is $40, leaving $14 contribution after advertising per order, or $560 across the 40 orders. Channel B converts 15 of 500 sessions, or 3%. Its CAC is $20 and contribution before advertising is also $54, leaving $34 after advertising, or $510 total.
The conclusion is not “Channel A wins” because its conversion rate is higher, or “Channel B wins” because its CAC is lower. A defensible action is to test moving some budget toward B while monitoring order volume, contribution after advertising and tracking quality. B is more efficient per order; A currently produces slightly more total contribution because it has more orders. The next budget decision depends on whether B can add profitable volume, which this sample alone cannot establish.
Review channel-reported attributed ROAS alongside blended MER, since attribution assigns revenue differently while MER compares total store revenue with total advertising spend. If conversion rises but contribution falls, check discounts, product mix, returns and acquisition cost before scaling. If economics are sound but volume is low, test cautiously; if the economics are negative, fix or stop the channel rather than optimise a vanity metric. ORVX can surface a deterministic action—scale, reduce, fix economics, test or stop—from the store’s own numbers and state the reason and confidence.
Web analytics is useful only when its definitions, formulas, and data sources agree. Calculate conversion rate from a clearly defined denominator, reconcile it against orders and revenue, then use the result with margin and acquisition cost to decide where to invest, investigate, or stop spending.