Blog · Finance metrics and formulas
Ecommerce website conversion rate compares qualifying orders with sessions in the same reporting scope. Work it by channel and device, reconcile the order count, and distinguish orders per session from the share of sessions that purchase.
Ecommerce website conversion rate is qualifying website orders divided by website sessions, expressed as a percentage. For a useful comparison, both counts must cover the same dates, website, channel rules, and device groups. Label the figure orders per session so nobody mistakes it for the percentage of visitors who became customers.
Ecommerce website conversion rate = Qualifying website orders / Website sessions × 100
A session is a visit period, not a person. Google's session documentation describes a session as a period of interaction with a website or app. The same shopper can return in another session, so a session denominator answers a different question from a user denominator.
The numerator here is distinct qualifying orders placed during those sessions. It is not item quantity, purchase-event rows before deduplication, or revenue. Specify whether qualifying means submitted, payment accepted, fulfilled, or retained after a cancellation window. This example uses payment-accepted website orders and removes test orders; later refunds remain a separate measure.
There is another valid measure: sessions containing a qualifying purchase divided by all sessions. That counts each purchasing session once. Orders per session counts each order, including additional orders in the same session. Keep the labels separate rather than silently substituting one for the other.
This is an online checkout measure. Win rate, close rate, and conversion rate explains the different denominators used for CRM sales outcomes.
Start with a session report grouped by date, session channel, and device category. Export the order register for the same website and reporting dates. Retain the order identifier, order timestamp, payment status, test flag, and the session channel and device used for the comparison.
| File | Required fields | Check before grouping |
|---|---|---|
| Session export | Reporting date, session channel, device, session count | Each session belongs to one reported segment |
| Purchase export | Order identifier, purchase timestamp, session channel, device | Repeated events do not become additional orders |
| Store order register | Order identifier, order origin, payment status, test flag | Website scope and qualifying status match the calculation |
Use session channel for both sides of this report. An order report that attributes purchases to a different marketing touch cannot be divided by session-channel traffic without reconciling the attribution difference first.
Missing device or channel is a reporting category to resolve or retain as unknown. Dropping unmatched orders while retaining their sessions depresses the rate. Conversely, excluding unclassified sessions while keeping their orders inflates it.
A US office-supply retailer compares September 2026 website traffic with payment-accepted orders. The following figures are an illustrative business example, not an industry benchmark. Rates are rounded to two decimal places; totals use the original counts.
| Channel | Device | Sessions | Qualifying orders | Orders / sessions | Conversion rate |
|---|---|---|---|---|---|
| Paid search | Desktop | 3,200 | 128 | 128 / 3,200 | 4.00% |
| Paid search | Mobile | 4,800 | 96 | 96 / 4,800 | 2.00% |
| Organic search | Desktop | 2,000 | 90 | 90 / 2,000 | 4.50% |
| Organic search | Mobile | 3,000 | 75 | 75 / 3,000 | 2.50% |
| Desktop | 800 | 64 | 64 / 800 | 8.00% | |
| Mobile | 1,200 | 48 | 48 / 1,200 | 4.00% | |
| Total | 15,000 | 501 | 501 / 15,000 | 3.34% |
With sessions in column C and orders in D, put this in F2 and format it as a percentage:
=IF(C2=0,"",D2/C2)
Fill down through F7. The company rate in F8 is:
=IF(SUM(C2:C7)=0,"",SUM(D2:D7)/SUM(C2:C7))
The simple average of the row percentages is 4.17%, which overweights the smaller email groups. The correct total gives each session equal weight. This follows the same denominator discipline as any stage conversion rate, although these rows describe website visits rather than sales stages.
The order numerator should be independently recoverable from the event export and the store register. Here is the retailer's reconciliation:
| Reconciliation | Starting rows or orders | Exclusion | Further exclusion | Qualifying orders |
|---|---|---|---|---|
| Purchase-event export | 527 | 18 repeated events | 8 test orders | 501 |
| Store order register | 519 | 10 offline orders | 8 test orders | 501 |
Both routes give 501. Google's transaction-ID guidance explains that repeated purchase events with the same transaction identifier can be deduplicated. For the export check, preserve distinct legitimate order identifiers rather than treating repeated event rows as new business.
There is also a mathematical check:
Total rate = Sum of each segment's sessions × its unrounded rate / Total sessions
The spreadsheet identity is:
=SUMPRODUCT(C2:C7,F2:F7)/SUM(C2:C7)
It must equal 3.34%. Use the unrounded cell values, even when the report displays fewer decimals. A correct weighted identity proves the aggregation; the order reconciliation proves the numerator. Neither proves that missing tracking has been recovered, so document any known coverage gaps.
For a different sales process that requires matching quotations to accepted orders, use the separate quote-to-order export method.
Regrouping the worked rows gives these comparisons:
| Comparison | Sessions | Orders | Rate |
|---|---|---|---|
| Paid search | 8,000 | 224 | 2.80% |
| Organic search | 5,000 | 165 | 3.30% |
| 2,000 | 112 | 5.60% | |
| Desktop, all channels | 6,000 | 282 | 4.70% |
| Mobile, all channels | 9,000 | 219 | 2.43% |
Mobile is lower within every channel in the original table, which supports investigating the mobile purchase journey. It does not establish a technical defect. Check purchase intent, product availability, new versus returning customers, and whether visitors later purchase on another device.
The channel totals also do not establish that moving budget to email would reproduce its rate. Existing customers may behave differently from new prospects. The report identifies questions for the ecommerce owner; campaign and checkout owners should test the explanations against comparable traffic.
Covirage is not affiliated with Google.
Bring a file or Google Sheet containing your session totals, order identifiers, and qualifying-order rules. Covirage maps the columns, its tools compute and check channel and device rates, and the external AI model explains the results with every figure traced to its rows. Create a free Covirage account, then set up your business and bring a sample of your own export.
See Covirage for sales insights for the supporting approach.
Use sessions when the question is how efficiently visits produce orders. Use users for a separately labeled customer measure. A returning visitor can start several sessions, so changing the denominator changes the question even when the order count stays the same.
That depends on the written order policy. A purchase-event rate usually records the original purchase, while a retained-order rate excludes subsequently canceled or fully refunded orders. Keep both definitions separate and state the follow-up cutoff for any later adjustments.
There is no single useful target for every store. Compare your own mature periods by device, channel, customer type, and purchase purpose under the same tracking rules. A change in traffic mix can move the total without changing any segment's conversion.
Possible causes include duplicate purchase events, tracking gaps, test orders, offline orders, different time zones, and different cancellation rules. Reconcile order identifiers and exclusions before interpreting the gap as shopper behavior or a checkout problem.