Learn

How to measure paying conversion rate

How do I measure the percentage of visitors who actually pay?

Paying conversion rate is the number of visitors who made at least one payment divided by total visitors in the same period. It differs from a goal conversion rate in what counts as success: a goal fires on an action you chose, while paying conversion only counts money actually received.

The formula, and the decision hiding inside it

Paying conversion rate = paying visitors ÷ total visitors, over one window, as a percentage. Count everyone who reached your site in June, count how many of them paid you anything in June, divide.

The arithmetic is trivial. The denominator is where the argument lives, because three of them are defensible and they give answers that differ by nearly a factor of eight.

Denominator	What it counts	The trade-off
Unique visitors	Distinct people in the window, as far as your cookie can tell	The safest default: comparable across channels and stable when engagement changes. Splits one human in two across devices.
Sessions	Visits, not people	A lower rate that drifts with browsing habits — a customer who returns three times before buying makes it look worse while nothing changed.
Qualified visitors	Only visitors who reached a step you defined — pricing, cart, trial	Flattering, and useful for diagnosing checkout. Meaningful only if the qualifying step never moves.

One month: 40,000 unique visitors, 62,000 sessions, 8,000 people who reached the pricing page, 340 who paid. That is 0.85% on visitors, 0.55% on sessions and 4.25% on qualified visitors — same month, same 340 customers.

So the rule is not to pick the right one. It is to pick one, write it down, and never change it silently. A rate that doubles because someone swapped sessions for visitors is the most expensive kind of wrong number: it looks exactly like a win.

Why this one survives and “conversion rate” does not

Ask four people at one company what the conversion rate is and you get four numbers — visitor to lead, trial to paid, click to checkout, demo request to booked call. Everyone is right, nobody is measuring the same thing. Paying conversion leaves no such room: money either arrived or it did not, so a bank statement settles the numerator.

Goal conversion rate vs paying conversion rate

Both are worth tracking and they answer different questions. A goal conversion rate counts an action you chose to instrument; a paying conversion rate counts money received.

	Goal conversion rate	Paying conversion rate
Numerator	Visitors who fired an event you defined	Visitors who made at least one payment
Set by	Your code — you decide what counts	Your payment processor
Speed	Immediate	Lags by the length of your trial or sales cycle
Fails when	The action is cheap and uncorrelated with revenue	Volumes are too low for the rate to be stable
Best for	A fast signal on a slow funnel	Deciding where money goes

A goal is the right proxy when the payment is genuinely far downstream — a 14-day trial, an annual contract, a sales cycle measured in weeks — because otherwise you wait a month to learn whether last month’s campaign worked. It is the wrong proxy when the goal is cheap to fire.

The test is the rate at which your goal turns into a payment. If 18% of signups pay every month, signup rate is a fine leading indicator. If it swings between 6% and 30%, the goal is not tracking revenue and improving it proves nothing. Statlark keeps both — goals fire from your own code, paying conversion is computed from the payments — so neither definition drifts into the other. See Goals & conversions.

What counts as a good rate

Nobody can tell you: any number quoted as the industry benchmark is an average over a population you are not in. A $9-a-month tool and a $2,000-a-year platform should not have the same rate.

The only benchmark worth keeping is your own trend, on a fixed denominator, split by source. This month’s organic paying conversion against last month’s is a real comparison; yours against a blog post’s average is not.

One caution, because the number is usually small: at 0.85% you need roughly 4,000 visitors to expect 34 buyers. A week with 300 visitors and 2 buyers is not a 0.67% rate, it is noise — act on it and you rewrite a landing page that was fine. A common working rule is to not read a rate at all until it rests on a few dozen conversions.

Split it by source or it is not actionable

The site-wide number averages populations that behave nothing alike, so it describes nobody. A site at 1.1% overall might be getting 4.2% from its email list and 0.2% from a syndication link supplying a third of its traffic. Change the mix and the 1.1% moves without anything improving.

Split it and the action changes. The syndication link is not a conversion problem to fix with better copy, it is a traffic source to stop counting as a win. Two decisions fall straight out of a per-source rate: where to spend more, and which channel to stop reporting as growth.

Which source a visitor belongs to depends on whether you credit the first touch or the last — see first-touch vs last-touch attribution. Whichever you pick, apply it to the numerator and the denominator identically. Statlark picks first touch and freezes it, so on a per-source rate that choice is already made for you.

It multiplies with average revenue per customer

Paying conversion is one of exactly two factors in revenue per visitor:

Revenue per visitor = paying conversion × average revenue per paying customer

It is an identity, not an approximation — both sides are revenue over visitors, with paying customers cancelling out of the middle. From the example: 340 payers ÷ 40,000 visitors = 0.85%, $28,900 ÷ 340 payers = $85 each, and 0.0085 × $85 = $0.7225 per visitor, which is $28,900 ÷ 40,000 exactly.

A weak channel is weak in one of two ways that need opposite fixes: high conversion with low revenue per visitor is plenty of buyers spending little, a pricing problem; low conversion with healthy revenue per visitor is a few large orders carrying the channel, fine until one churns. Each side has its own page — revenue per visitor and customer lifetime value, which is what that average becomes once you count a person across every purchase rather than one window.

How Statlark measures it

Statlark computes paying conversion as distinct visitors who made at least one payment in the window, divided by distinct visitors with any event in the window. The denominator is unique visitors, never sessions — on a default install a visitor is a first-party cookie with a 365-day lifetime, while a session id lives in per-tab session storage, which makes the visitor the more stable of the two.

Both counts come from the same set of visitors active in the window, so the numerator is always a subset and the rate can never exceed 100%. A renewal from a customer who did not visit that month adds to revenue but not to the numerator — the behaviour you want from a rate about visitors.

Revenue is counted net of refunds everywhere. A payment in a currency other than the site’s configured currency is recorded but deliberately left out of revenue rollups rather than converted at a guessed exchange rate. And traffic you exclude by path, country or hostname is dropped before it is counted, so staging and internal hits never dilute the denominator.

On the Overview it sits alongside revenue, revenue per visitor and visitors, each with the preceding equal-length period; it can be plotted over time; and clicking any source, country, device or page re-scopes it. The Sources table carries a paying conversion on every row next to revenue per visitor. More in Reading your data.

Both numbers are also available over HTTP:

# Paying conversion for a window, plus the preceding equal-length period.
curl "https://app.statlark.com/api/v1/overview?site=sl_xxxx&from=2026-06-01&to=2026-07-01" \
  -H "Authorization: Bearer slk_your_token_here"

# The same rate, split by traffic source.
curl "https://app.statlark.com/api/v1/sources?site=sl_xxxx&from=2026-06-01&to=2026-07-01&grouping=channel" \
  -H "Authorization: Bearer slk_your_token_here"

{
  "site": "sl_xxxx",
  "range": { "from": "2026-06-01T00:00:00.000Z", "to": "2026-07-01T00:00:00.000Z" },
  "metrics": {
    "revenue": 28900,
    "previous_revenue": 24100,
    "visitors": 40000,
    "previous_visitors": 38200,
    "paying_conversion": 0.0085,
    "previous_paying_conversion": 0.0072,
    "revenue_per_visitor": 0.7225,
    "previous_revenue_per_visitor": 0.6309
  }
}

Where the number is not exact

A payment that cannot be tied back to a visitor still counts as revenue but cannot count as a paying visitor, so heavily unattributed revenue makes the rate read low and the implied order value read high. Per-source rows contain only attributed payments, which is why they will not sum to the site-wide figure. The fix is upstream, at checkout: carry the visitor id through to the charge, as in tracking Stripe revenue in your analytics, or see Revenue attribution for the Statlark setup.

And when the rate is charted over time, each bucket carries its own denominator, so the buckets do not average out to the headline: the headline counts a visitor once across the range, while a visitor active on three days appears in three buckets. Both are right; comparing them directly is the mistake.

Last reviewed 29 July 2026