How to track revenue per visitor

Revenue per visitor is total revenue in a period divided by unique visitors in that same period. Track it by tying every payment back to the visitor who made it, then dividing per traffic source rather than site-wide — the site-wide number tells you almost nothing, and the per-source number tells you where to spend.

The formula, and what counts on each side

revenue per visitor = revenue ÷ unique visitors, both over the same window. The arithmetic is trivial; almost every wrong RPV comes from one of the two halves being defined loosely.

Unique visitors, not sessions or pageviews. A person who reads three articles over a week and then buys is one visitor. Divide by sessions instead and your RPV falls every time loyalty rises — the exact opposite of what you want the number to say.

The same window on both halves.If the numerator is “everything those June visitors have ever paid” and the denominator is “June visitors”, you have computed a cohort lifetime value with a misleading name. RPV is deliberately a period metric: what a visitor was worth then, which is what you can compare across sources.

Revenue net of refunds, and credited to the original sale. A refund issued in July against a sale made in June belongs against June, or the channel that brought the buyer keeps credit for money it gave back.

Why the site-wide number is nearly useless

Site-wide RPV is a weighted average of every source you have, weighted by traffic volume — so it mostly reports changes in your traffic mix, not changes in your business. One post that does well on a link aggregator sends 40,000 curious non-buyers and your site-wide RPV halves overnight, while every channel that actually pays your bills performed exactly as it did last week.

Split by source and each number becomes a decision instead of a mood. Newsletter at $2.40 a visitor, paid search at $0.31, that aggregator at $0.02: three different budgets. The site-wide figure is good for one thing — a trend line against itself while your traffic mix is stable — and it stops meaning even that the moment the mix moves.

The same holds one level down — by landing page, by country, by device. The split only works if each payment is credited to a source in the first place; see attributing revenue to marketing channels.

The small-sample trap

A ratio with a tiny denominator is noise wearing a number’s clothes. A referral that sent 12 visitors, one of whom bought a $400 plan, has an RPV of $33.33 — more than ten times your best real channel. That does not make it ten times better. One person bought, and had they not, it would read $0.00.

Three habits fix this, none of them a clever formula. Read absolute revenue beside RPV — $400 next to $6,580 settles it. RPV says where an extra visitor is worth most; total revenue says how much the source matters today.

Set a volume floor and treat everything below it as unranked rather than as the top of your list. Pick the floor from your own paying conversion rate: at 2%, a 500-visitor source expects about ten buyers, enough for an average to mean something, while a 50-visitor source expects one and will read as either a triumph or a zero.

Widen the window instead of squinting harder. This is the honest part: no arithmetic rescues a 12-visitor sample. Read it over 90 days where 30 was too thin, or wait. The uncertainty on a sample that small is wider than the decision it is meant to inform.

RPV vs ARPU vs AOV

These three get used interchangeably and they are not interchangeable. Every difference is in the denominator.

RPV is the only one of the three that includes the people who bounced, which is exactly why it is the marketing number. ARPU counts only the people who signed up or bought, so it prices your product rather than your traffic — a channel full of tyre-kickers and a channel full of buyers can post identical ARPU. AOV knows nothing about traffic at all, and can rise while revenue falls if the cheap orders stop.

They are related, and the relationship is the useful bit: RPV = (orders ÷ visitors) × AOV. When most buyers place one order in the window, orders ÷ visitors is your paying conversion rate, so RPV is roughly paying conversion × AOV. Sell subscriptions, or let customers reorder inside the window, and that shortcut drifts.

The two ways the number goes up

That identity says RPV can only rise two ways: more of your visitors buy, or the ones who buy spend more. They call for different work, and confusing them is how a quarter goes to the wrong thing.

More buyers is conversion work, and it lives mostly on the page the visitor lands on: does it say what the ad promised, does the pricing page answer the objection, how many fields are in the checkout. It is cheap, fast to test, and it compounds across every channel at once.

Bigger orders is pricing and packaging work: an annual plan, a bundle, a higher tier, an upsell at checkout. It is slower, riskier, and it can move conversion the wrong way — a price rise that lifts AOV 20% and drops paying conversion 30% has lowered RPV. Because the levers offset, watch RPV and both components together.

A third lever is not on your site at all: change who arrives. Narrow the keyword, tighten the ad audience, stop chasing the headline that brings the wrong crowd. Same page, fewer wrong visitors, higher RPV — and fewer visitors overall, which is why a traffic-only dashboard reports this particular improvement as a decline.

The decision it drives

RPV exists to answer one question: where does the next marketing hour go? Not simply “the channel with the highest RPV” — the size of an opportunity is RPV multiplied by the visitors you can realistically add. A newsletter at $2.40 where you can reach 500 more people is worth about $1,200; paid search at $0.31 where you can buy 5,000 more clicks is worth about $1,550. RPV ranks the quality; reachable volume decides the size.

For anything you pay for, the second comparison is RPV against your cost per visitor: $0.31 earned at a $0.22 cost per click makes money before overheads, and the same $0.31 at $0.40 does not, however good the traffic looks. That division is yours to do — Statlark records what a channel earned, not what it cost, so it does not compute a return on ad spend.

How Statlark tracks it

Rev / visitor is one of the four headline KPIs on the Overview — with revenue, paying conversion and visitors — and one of the four series the trend chart draws. Each bucket on that chart is its own ratio, that bucket’s revenue over that bucket’s visitors, so a daily line is a series of daily RPVs rather than a running average.

Every traffic source row carries revenue and rev / visitor, and the list is ranked by revenue rather than by visitors. You can group sources by channel, UTM source, referrer or ad-click id; the expanded table under the card adds visitors and paying conversion per row, which is where you check n before you believe an RPV. Landing pages get their own rev / visitor, divided by the visitors whose first visit landed on that path. Filter to a source, country, device or landing page and the KPIs, the trend chart and the other cards all re-scope to that slice, RPV included — the mechanics are in Reading your data.

Both halves are defined as above: visitors are distinct visitor ids with an event in the window, so returning people count once, and revenue is the sum of that window’s payments net of refunds. A payment in a currency other than the site’s configured currency is recorded but left out of the rollup rather than converted at a rate nobody agreed on — an honest gap instead of a plausible-looking wrong number. Each visitor’s source is their first touch, frozen on their first visit, so a later direct return never relabels them; see Revenue attribution for how a payment is tied back to a visitor.

The same numbers come out of the REST API, which is the fastest way to check the small-sample problem against your own data: