How to track revenue without tracking people

The standard way to get revenue into analytics is to make the browser tell you. A purchase fires an event, the event carries a value and an order id, and something in the pipeline joins that to a visitor identifier so you can trace the money back to a session.

It works. It also requires an identifier that follows a person, which is what a cookie banner exists to ask about, and it means your analytics database now holds transaction data tied to individuals.

There is a second path, and most sites never consider it.

Ask the payment provider instead

Your payment provider already knows exactly what you earned and when. It is the authoritative record — more accurate than anything the browser could report, because it is the system the money actually moved through.

Read it from there. An API call returns charge amounts and timestamps in aggregate; plot that over time next to your traffic over time. No cookie, no visitor identifier, no purchase event, no tag manager.

The privacy properties fall out of the architecture rather than from a policy promise:

• No visitor is identified, because the revenue never comes from the visitor’s browser.
• No customer data enters analytics, because you are reading totals, not a customer list.
• Nothing is stored on the device, so there is no storage to obtain consent for.
• Ad blockers are irrelevant to the revenue number, since it never travels through the page.

That last one is an accuracy argument, not a privacy one, and it is underrated. Browser-reported purchase events are lost whenever the tracker is blocked, the tab closes early, or the confirmation page redirects too fast. Provider-side revenue has none of those failure modes.

What you give up, stated plainly

This is a trade, and the honest version of this article names the cost.

You lose per-visitor revenue attribution. You cannot open one visitor and read the charge they produced, because the two data sets are never joined. If your business genuinely depends on tracing individual customer journeys — high-touch B2B sales with long cycles, for instance — this approach will not do that, and no amount of framing changes it.

Correlation is not credit. Revenue and traffic climbing together in the same week is suggestive, not proven. A newsletter, a price change and a product launch can all land in those seven days. What you get is a much better question, not a settled answer.

One currency at a time. Combining currencies needs an exchange rate and a date convention, and any choice there is wrong for somebody. Reading them separately is the honest default.

What you keep, which is most of it

For the majority of sites, the questions that actually get asked are period-shaped, not person-shaped:

• Did last week earn more than the week before?
• Did the launch move money, or only attention?
• Is the traffic we have been buying worth what it costs?
• Is revenue per visitor trending up or down this quarter?

Every one of those is answerable from two aggregate series on one chart. None of them requires knowing who anybody is.

If you do need credit assignment

There is a middle path that keeps the privacy properties intact: fire a conversion event yourself for the action that matters, without personal data attached, and read it in a funnel or an attribution report.

A signup or checkout_complete event tells you that a visit from a given source reached the outcome. It does not need a cookie, a name or an email — only the fact that the step happened. That gets you channel-level credit assignment while the money itself still comes from the provider, where it is accurate.

Details on both halves: Revenue for connecting Stripe or Polar, and Custom events for the conversion event. Revenue is included on every plan, including Free.

The point

“Privacy-first” is usually presented as a constraint you accept in exchange for losing capability. On revenue it is closer to the opposite: reading money from the system that handled the money is both more private and more accurate than asking a browser to report it, and it removes an entire category of tracking from your site.

You should still be told what it cannot do. But the version where you surveil your visitors to learn what you already know from Stripe is worth questioning before you build it.