Working the Conversion Rate Formula on Real Traffic

How do you calculate conversion rate?

Analysts apply one conversion rate formula: conversions divided by sessions or unique visitors, times 100, and the denominator you choose moves the number further than most optimization work does. The formula itself is stable across every tool and every industry:

conversion rate = (conversions / denominator) x 100

Work it on one week of store traffic. The store records 800 orders against 40,000 sessions. 800 divided by 40,000 is 0.02, and 0.02 times 100 gives a conversion rate of 2.00%. That is the arithmetic finished. Everything else on this page is about which number belongs underneath the division line, because "2.00%" on its own does not tell a reader which of three defensible answers they are looking at.

What counts as a conversion in the numerator?

A conversion is one completed instance of the action you named in advance, and nothing else. The numerator is a definition you write down, not a quantity the browser hands you: a purchase, a paid signup, a trial start, a demo request, a form submission, a file download. Two teams measuring the same checkout will disagree on whether a refunded order still counts, whether a second order from the same person counts twice, and whether a signup that never confirms its email counts at all.

Settle those three questions before you divide anything, and keep the definition in the same document as the report. Smaller steps such as add-to-cart events, email signups and pricing page views belong in their own separately named rates, not folded into the headline number, since mixing them silently inflates the numerator over time.

Sessions or users: which denominator belongs in the formula?

Use sessions when you are measuring a page, a campaign or a checkout flow, and use unique visitors when you are measuring people. A session is one visit with a timeout attached, so one person who browses on Monday, returns Wednesday and buys on Friday contributes three sessions and one visitor. The denominator you pick decides whether that person is counted once or three times, and the gap between those two counts is the entire spread you see below.

Here is one week of identical traffic, run through three conventions. The store recorded 40,000 sessions from 25,000 unique visitors, and 800 orders placed by 640 distinct buyers.

Three correct applications of the same formula, on one dataset, produce 2.00%, 2.56% and 3.20%.

Why does the same traffic give three different rates?

Two ratios inside the data drive the whole spread. The 25,000 visitors produced 40,000 sessions, which is 1.6 sessions per person, and the 640 buyers placed 800 orders, which is 1.25 orders per buyer. Session-based counting divides by the inflated visit count and returns the lowest rate. Order-based counting keeps the inflated order count in the numerator while dividing by the smaller people count, so it returns the highest. The top figure is 60% above the bottom one, and no week of design changes moves a real conversion rate that far.

The same effect shows up on a SaaS signup page with no repeat conversions at all. Take 9,000 sessions from 6,000 unique visitors and 240 trial starts, one per person. Session-based: 240 divided by 9,000 is 0.0267, so 2.67%. User-based: 240 divided by 6,000 is 0.04, so 4.00%. The numerator never changed. The denominator carried a 1.5x difference on its own, purely because visitors came back before they signed up.

How do ecommerce and SaaS conventions differ?

Ecommerce reports orders divided by sessions, and SaaS reports converting people divided by unique visitors. Ecommerce chose sessions because a shopping visit is the unit being optimized, repeat purchases inside a period are normal, and a checkout is decided within one visit more than a contract is. SaaS chose people because the consideration window runs across weeks, a person can only start one trial, and the metric feeds a funnel where each step is measured against the people who reached it.

Keep the convention that matches how your buyers behave, then hold it fixed. If you sell both ways, report both rates side by side with their denominators labeled, and pair them with revenue per visitor so a rate that rises on cheap orders cannot be mistaken for a rate that rises on demand.

Why is a conversion rate without its denominator uninterpretable?

A bare percentage cannot be compared to anything, because the reader has no way to reconstruct what was divided. A dashboard that showed 2.00% last quarter and 2.56% this quarter looks like a 28% relative improvement, and in the worked example above those two numbers are the same 800 orders on the same 40,000 sessions, reported once per session and once per visitor. Nothing improved. Someone changed a setting.

This is also why cross-company comparisons collapse. A competitor quoting 3.20% against your 2.00% may be sitting on identical traffic and identical orders. Before you read any benchmark, find the denominator, the conversion definition and the time window it used, and treat a figure missing all three as unusable, not as a target worth chasing. Write your own denominator into the chart title, the alert name and the slide, not into a footnote.

How do you fix the denominator in your analytics tool?

Define the conversion as a named goal event and pin the denominator to the traffic that could have fired it. A denominator of all site sessions understates every page-level rate, because it counts visitors who never reached the page carrying the button. Restrict the denominator to sessions or visitors that hit the step, then the rate answers a question someone can act on.

Flowsery's built-in analytics tracks goals and conversion events alongside funnels and revenue by source, and it does not sample data, so the counts you divide are the counts that happened. Record the exact denominator rule next to each goal, agree on your session definition once, and check any step-level number against the completion rate for that goal before it goes in a report.

Frequently asked questions

What is the conversion rate formula?

Conversion rate equals conversions divided by a traffic count, multiplied by 100. The traffic count is either sessions or unique visitors, and which one you use has to be stated with the result. 800 orders against 40,000 sessions is 2.00%.

Should I divide by sessions or by unique visitors?

Divide by sessions when the thing you are measuring is a page, a campaign or a checkout flow, since the visit is the unit being optimized. Divide by unique visitors when the thing you are measuring is a person deciding over days or weeks, which is the SaaS case. Pick one, label it, and do not switch mid-quarter.

Why did my conversion rate change without any site changes?

Check whether the denominator moved. A switch from sessions to unique visitors raised the example rate from 2.00% to 2.56% with no change to the site, the traffic or the 800 orders. Traffic mix shifts do the same thing: more repeat visitors per person lowers a session-based rate while leaving the user-based rate flat.

Can conversion rate be above 100%?

An order-based rate can exceed 100% if buyers place more than one order each in the period, because the numerator counts orders and the denominator counts people. A rate built from converting visitors over unique visitors cannot pass 100%, since every converter is also a visitor. A rate above 100% is a sign the numerator and denominator count different things.

What time window should the formula use?

Use a window long enough to cover the decision and short enough to still act on. Both the numerator and the denominator must cover the identical window, or you will divide this week's conversions by last month's traffic. Weekly windows suit ecommerce checkouts, and monthly windows suit longer SaaS consideration cycles.

Do I need the same denominator for every rate on a report?

Every rate on one report should state its own denominator, and rates using different denominators should never be compared in the same column. A page-level rate divided by sessions that reached the page and a site-level rate divided by all sessions are both correct and are not the same measurement. Put the denominator in the column header so nobody has to ask.

Should a refunded order still count as a conversion?

The formula doesn't decide this for you. Whether a refunded order counts is one of three definition questions a team has to settle before dividing anything, alongside whether a repeat order from the same buyer counts twice and whether an unconfirmed signup counts at all. Whatever the team decides, they should write it into the same document as the report so the numerator still means the same thing next quarter.

What's the difference between session-based and order-based conversion rate?

Session-based conversion rate divides orders by sessions, while order-based divides the same orders by unique visitors instead. On the one week of data worked through this page, session-based counting returns 2.00% and order-based counting returns 3.20%, using the same 800 orders. The gap exists because order-based counting divides by the smaller visitor count while the inflated order total stays in the numerator.

Why might two companies report different conversion rates on the same traffic?

Two companies can show different conversion rates while sitting on the same traffic and the same order count, since the number moves with the denominator alone. A competitor quoting 3.20% against your 2.00% might be running identical numbers through a different convention, not converting better. Ask for the denominator, the conversion definition and the time window before treating a competitor's number as a benchmark.

Does a returning visitor count more than once in conversion rate?

A returning visitor is counted differently depending on which denominator is in use. Someone who browses on Monday, returns Wednesday and buys on Friday contributes three sessions but only one visitor, so a session-based rate treats that person as three chances to convert while a user-based rate treats them as one. That's the same mechanic that split 40,000 sessions across only 25,000 unique visitors in the worked example.