What is revenue-first analytics?
Revenue-first analytics puts money in the first column of your dashboard instead of a spreadsheet you open later. Here is what the term means, what it requires, and what it is not.
All posts
Revenue-first analytics is web analytics where money is a primary series rather than a feature you configure later. The dashboard’s first answer is whether something earned, not whether it was visited. In practice it means joining two data sets that normally sit in separate tools — traffic from your website and payments from your payment provider — so that a single chart can answer the only question most site owners actually have.
That is the whole definition. The rest of this article is about why the join is unusual, what it costs, and where the honest limits are.
Why traffic alone is the wrong first column
Every analytics dashboard ever built opens with a visitor count. It is a reasonable default for a media business, where attention is the product. It is a poor default for anyone selling something, because traffic and revenue routinely disagree about which channel matters.
The disagreement is not subtle. A comparison-shopping aggregator can send ten times the visitors of a niche newsletter and a fraction of the revenue. Ranked by visits, the aggregator wins every report you run. Ranked by money, it may not be worth the bandwidth.
Being wrong about that ordering is expensive in a specific way: you spend the next quarter buying more of the thing at the top of the list.
Why the join is rare
The gap is structural rather than a gap in anyone’s product roadmap.
Analytics tools watch browsers. They see a request, a page, a referrer, a device. They have never seen a bank transaction and have no way to.
Payment tools watch charges. Stripe knows precisely how much money arrived and from whom. It has never seen a referrer and does not know that the customer arrived from a podcast six days ago.
The two systems are keyed on different identifiers, governed by different privacy rules, and joined — in nearly every company — by a person with two browser tabs open and a spreadsheet in between. An entire micro-industry of connector products exists to automate that spreadsheet, which is the clearest evidence available that the underlying tools were never designed to answer the question together.
The two ways to join, and what each answers
They are genuinely different, and conflating them is the most common source of confusion in this area.
Aggregate revenue beside aggregate traffic
Read total revenue from your payment provider’s API for a period and plot it on the same axis as visitors for that period.
- Answers: did the week that got more traffic also earn more money? Did the launch move revenue or only attention? Is the trend line going the same direction as the visitor line, or have they diverged?
- Requires: a read-only API key. Nothing else.
- Privacy cost: none. The provider already knows these totals, no visitor is identified to produce the number, and no tracking event is involved at any point.
Per-channel credit assignment
Fire a conversion event when a purchase completes, then attribute it to the visit that preceded it using an attribution model.
- Answers: which specific channel should be credited with this sale?
- Requires: a conversion event you implement, plus enough visitor continuity to connect arrival to purchase.
- Privacy cost: real, and proportional to how long a journey you want to reconstruct. Following someone from a first touch in March to a purchase in May means remembering that person for two months.
Most products marketed as “revenue analytics” quietly mean the second and require the first as a prerequisite. sonex does the first by default on every plan including Free, and offers the second through the Attribution report when you send a conversion event yourself. The distinction is worth insisting on, because the first is free of privacy cost and the second is not.
What it is not
It is not ecommerce tracking. Client-side purchase events report what the browser was told to report. They are lost to ad blockers, to beacons that never fire on a closed tab, and to checkouts that complete on a payment provider’s domain. Reading from the payment API means the total is the actual total.
It is not a payments dashboard. Stripe already shows revenue over time, beautifully. What it cannot show is the traffic that produced it, because it has never seen your site.
It is not attribution in disguise. Aggregate revenue beside aggregate traffic is a correlation over time, presented as one. Any product presenting it as per-visitor causation is overselling.
It is not incompatible with privacy. This is the assumption worth attacking directly, and it is the reason the category has been slow to appear.
Revenue-first and privacy-first are not in tension
The intuition says otherwise: money is the most sensitive thing you could attach to a visitor, so surely tying revenue to analytics means more surveillance rather than less.
It does not, because of where the number comes from. Revenue arrives from the payment provider’s API in aggregate — totals per period, already known to a system you already trust with far more than this. Nothing about it originates in the visitor’s browser. No cookie is required. No identifier is stored. No consent banner is triggered, because nothing is written to the device to trigger one.
You end up in a position that sounds contradictory and is not: the dashboard knows how much money you made and does not know who any individual visitor is. Those facts come from different places, and only the second one was ever a privacy problem.
Per-visitor attribution is where the trade-off actually lives, and it is opt-in. That is the correct place for it — visible, deliberate, and yours to decide.
What a revenue-first dashboard shows
| Question | Traffic-first answer | Revenue-first answer |
|---|---|---|
| Did the launch work? | Visits rose 40% | Visits rose 40%, revenue rose 4% |
| Which channel is best? | The one sending most visits | The one sending most money per visit |
| Is the blog worth writing? | It has readers | It earns, or it does not |
| Should we buy more of this ad? | CTR is good | ROAS is above break-even, or it is not |
| Is this month better? | More sessions | More revenue per visitor |
Every left-hand answer is a real measurement. None of them is the question that was asked.
What to look for in a tool
If you are evaluating anything claiming this category, four questions separate the real thing from the label:
- Where does the revenue number come from? Payment provider API, or a browser event? Only the first survives an ad blocker.
- Is it gated? Revenue is frequently reserved for the top tier, which means the small business that most needs to know whether it is profitable is the one that cannot see it.
- What does connecting it cost in privacy? If reading revenue requires a durable visitor identifier, ask why — the aggregate view does not.
- Does it survive a refund? Gross charges are not revenue. Net of refunds is.
Where the term is going
The label is new and slightly contested, which is normal for a category that has just become buildable. Payment provider APIs are good now, analytics no longer needs cookies to be useful, and both facts arrived recently enough that the combination is still unusual.
What matters is not the phrase but the reordering behind it. A dashboard is a claim about which question is most important, made by whoever decided what goes at the top. For a decade that claim has been “attention”. For anyone selling something, it should have been “money” all along.
sonex is revenue-first web analytics: connect Stripe or Polar with a read-only key and read revenue beside the traffic that earned it, on every plan including the free one. No cookies, no consent banner. Start free.
Frequently asked questions
- What is revenue-first analytics?
- Revenue-first analytics is web analytics where earned money is a primary series rather than an add-on. The dashboard's first answer is whether something made money, not whether it got visits. It requires joining two data sets that normally live apart — traffic from your site and payments from your payment provider.
- Is revenue-first analytics the same as ecommerce tracking?
- No. Ecommerce tracking reports purchases the browser was told about, which means it inherits every gap in client-side measurement — ad blockers, failed beacons, abandoned tabs. Revenue-first analytics reads money from the payment provider's API, which is a system of record, so the total matches what actually arrived.
- Can revenue-first analytics work without tracking individual visitors?
- Yes, for the aggregate view. Revenue over time can be read from a payment provider and plotted beside traffic over time without identifying anyone. Per-channel credit assignment is a separate, harder problem that needs a conversion event you fire yourself.
- Does revenue-first analytics replace Stripe's own dashboard?
- No. Your payment provider remains the system of record for money. Revenue-first analytics puts that same number next to the traffic that earned it, which is a question the payment dashboard cannot answer because it has never seen your traffic.
sonex is privacy-first web analytics. No cookies, no consent banner, no personal data. Drop one script and read realtime visitors, funnels and a world map in seconds.
Try sonex free