Seeing which sources bring revenue, without cookies

Published 29 October 2026 · 7 min read

Counting conversions tells you which sources bring people who buy. It does not tell you which bring the money. A newsletter that sends ten buyers of a yearly plan can be worth more than a search term that sends thirty buyers of a monthly one. To see that, the analytics has to add up what was spent, not just how many times someone bought.

That sounds as if it needs to know who bought. It doesn't. Revenue by source is a sum, made the same way as a count: each purchase adds its amount to the row for the visit it happened in. No cookie, no customer record and no order number is needed.

This article covers what to send, what one sum can and cannot contain, how to read revenue beside conversions, and where the figures will differ from your payment provider's.

Revenue is an amount on a conversion

Revenue is added to a conversion you already count. If checkout_completed is a goal, the event carries what was paid, and the analytics adds that amount up wherever it counts the goal:

// When the payment has gone through, not when the button is pressed.
analytics.track("checkout_completed", { amount: 49 });

The rules for conversions apply here too, and they matter more when money is involved:

• Send it when the payment has succeeded. If you send it when the Pay button is pressed, declined cards get counted as income.
• Send the amount in the currency's main unit. Send 49 or 19.99, not 4900 cents. Amounts are added up as sent, so cents read as a hundred times the price.
• Send a number. "19.99" as a string is fine. "$19.99" or "1,299.00" is not a number, so it adds nothing.
• Decide what the amount includes, and keep to it. That could be before tax, after a discount, or without shipping. The comparison between sources only holds if every purchase is measured the same way.

Send nothing else about the purchase. An order number, an email address or a customer id makes a purchase traceable to a person. A sum by source doesn't need any of them.

One sum, one currency

You can't add euros to dollars without choosing an exchange rate. The rate changes every day, so a figure converted today and the same figure converted next month would differ even though nobody bought anything. The honest sum is in one currency, added up exactly as sent.

A shop that sells in more than one currency keeps a sum for each: one goal for purchases in euros, another for purchases in dollars. You can send the currency as a property and match each goal on it:

analytics.track("checkout_completed", { currency: "EUR", amount: 39 });

The euro goal then counts checkout_completed where currency is EUR, and sums amount.

Reading revenue beside conversions

Revenue is most useful next to the conversions that produced it. Put the goal on your sources, and each row shows three figures: visitors, conversions and revenue.

Fewer visitors can bring more money; a row with fewer than 5 conversions shows no revenue, since it would be what those few people paid.

Read the rows against each other, not one at a time. In the example, search sends six times as many visitors as the newsletter and brings more conversions, but the newsletter brings more money. Its readers buy the yearly plan. If you looked only at conversions, you would put your effort into search. Looking at revenue suggests the newsletter deserves more of it.

The same sum can be read by campaign, entry page, country or device. Those answer questions such as "which landing page brings the larger orders?" or "is the spring campaign paying for itself?". For campaigns, tag the links you control, as the UTM campaign article explains.

Why a small row shows no figure

A row's revenue is the total of what the people in it paid. When there are many of them, that says nothing about any one person. When there is one, it says exactly what that person spent, and a row such as "Partner blog, Lisbon, one buyer" can tell someone who knows them a lot.

So a revenue figure from fewer than five conversions should be withheld, shown as a dash rather than a number. The conversions themselves still show as "fewer than 5". The row has not disappeared, it is just too small to sum safely. Widen the date range, or read a broader breakdown, and the figure comes back once it covers enough people.

Where it will differ from your payment provider

Revenue in analytics is a way to compare sources. It is not your accounts. Expect it to be lower than what your payment provider reports, and for clear reasons:

• Blocked scripts send nothing. A purchase in a browser that blocks the analytics script still happens, but adds nothing to the sum.
• Only purchases made on your site count. A subscription renewal is charged by your payment provider each month, and nobody visits your site for it. The first payment is counted, and the renewals are not.
• Refunds are not taken off. A refund happens later, usually in your payment provider's dashboard, so it is never part of the visit that brought the sale.
• A purchase belongs to the visit it happened in. Someone who arrives from a campaign on Monday and comes back directly on Thursday to pay is Thursday revenue from Direct. Crediting it to Monday would need an identifier kept across days, and that is exactly what privacy-first analytics doesn't keep.

None of this changes the comparison: a source that brings twice the revenue in the analytics brings about twice the revenue in your accounts. For totals you report or pay tax on, your payment provider is the record.

Common questions

Do I need to send an order id to avoid counting a purchase twice?

No. Send the event once, when your own code confirms the payment, rather than on a page that can be reloaded. A thank-you page that sends the event every time it loads counts a reload as a second sale, and an order id in the analytics would not fix that without making each purchase traceable.

Can I see revenue per visitor?

Divide the revenue by the visitors in the same row. Comparing those two figures across rows shows which sources bring visitors who spend.

Does revenue tracking need cookies?

No. Revenue is an amount on an event, added up by source; it needs no more than the conversion it rides on. What the conversion itself needs, and what the rules on device storage say about it, is in the cookieless analytics article. It is not legal advice.

Can a browser extension or an app send revenue?

Yes, the same way: an event with an amount, when an in-app purchase or an upgrade has gone through.

How AnalyticsTrend does it

In AnalyticsTrend, revenue belongs to an event goal. Under Revenue property give the property that holds the amount, such as amount. Then choose the Currency it is in, one of 15 currencies, from US dollars to Polish złoty. Every event that completes the goal adds its amount, as a number or a string that reads as one. An event without a usable amount still counts as a conversion and adds nothing. Amounts are never converted, and a shop that sells in two currencies makes a goal for each, matched on a currency property.

The goal shows its revenue beside its conversions. Choose the goal on Sources, Referrals, Entry pages, Locations, Devices or Versions, and every row gains its revenue too. That includes each campaign, medium, content and term under Sources. A revenue figure from fewer than 5 conversions shows as a dash, in the dashboard, in the CSV export and through MCP. Adding, changing or removing a goal's revenue counts it again from the last 90 days of events. Only totals are shown, never who bought. Every number that bounds goals is in Capabilities and limits, and what is collected is in What it collects.

To start, see Revenue in the goals guide, and measuring sign-ups and checkouts for the goal it rides on.

---

Checked against AnalyticsTrend's own documentation on 29 October 2026.