In short
Revenue attribution assigns money received to the marketing touches that led to it, rather than assigning conversion counts. It uses the same models and lookback windows as marketing attribution, but splits a real transaction amount recorded by a payment processor. That makes it sensitive to refunds, partial refunds and renewals, and it is the only version of attribution that can set a budget.
What is revenue attribution?
Revenue attribution is the practice of assigning money received to the marketing touches that led to it. Not clicks, not signups, not form fills: money that actually arrived in your account and stayed there.
That distinction is the entire point. Ask what is revenue attribution and most tools answer with a conversion count. A conversion count tells you a button was pressed. Revenue attribution tells you that a $49 subscription started on the fourteenth of the month, that it came from a visitor whose first touch was a comparison article in March, and that $49 is still yours because the charge was not refunded three weeks later.
The unit matters because channels do not produce equally valuable customers. A channel can send twice the signups and half the revenue. Under conversion-count attribution it looks like your best channel. Under revenue attribution it looks like what it is.
How is revenue attribution different from marketing attribution?
Marketing attribution credits events. Revenue attribution credits amounts. Everything else follows from that.
Marketing attribution is the broader discipline: pick a model, pick a lookback window, split credit for a conversion across the touches in the journey. The conversion can be anything you declare, a trial start, a demo request, a newsletter signup, an add to cart. The output is a count per channel, sometimes multiplied by an assumed value.
Revenue attribution uses the same models and the same windows, but the thing being split is a real transaction amount recorded by your payment processor. The output is currency per channel. It also inherits the messy parts of money that events never have: partial refunds, chargebacks, currency conversion, taxes, discounts, and subscriptions that renew for years after the touch that created them.
In the revenue attribution vs marketing attribution comparison, the practical difference is what you can decide. Marketing attribution answers "which channel produces the most activity?". Revenue attribution answers "which channel produces the most money, after refunds?". Only the second one sets a budget.
Why do payment webhooks make revenue attribution trustworthy?
Because a signed webhook from your payment processor is the only record of a transaction that your visitor cannot influence.
Every major processor signs its events. Stripe signs each request and includes a timestamp in the Stripe-Signature header, and the official libraries verify it with a whsec_ endpoint secret, rejecting anything outside a five-minute tolerance to block replays (Stripe webhook signatures). Lemon Squeezy sends an HMAC hex digest of the payload in X-Signature (signing requests). Paddle sends a timestamp and HMAC-SHA256 hash in Paddle-Signature (verify webhook signatures). Razorpay signs with HMAC-SHA256 in X-Razorpay-Signature (validate webhooks). Polar follows the Standard Webhooks specification and signs every request (Polar webhooks).
Three properties come out of that:
- Authenticity. The amount came from the system that moved the money, over a server-to-server channel, cryptographically tied to a secret only you and the processor hold.
- Completeness. Webhooks fire for the whole lifecycle, not just the happy path. A charge succeeding, a payment failing, a subscription renewing, a refund being issued (Stripe event types).
- Correction. Because the lifecycle keeps arriving, yesterday's attributed revenue can be revised when the money goes away.
Statsy counts revenue only from signed webhooks from Stripe, Lemon Squeezy, Paddle, Polar and Razorpay, or from its authenticated Payment API. Nothing else is allowed to create a revenue number.
What goes wrong when the browser reports the amount?
Browser-reported revenue is a number the buyer's device tells your analytics, which means it is a number anyone can edit, and a number that regularly goes missing.
The usual pattern is a thank-you page that fires an analytics call with the order total, or a client-side purchase event on a checkout confirmation. Four things break it:
- It is editable. The value sits in JavaScript on a page the visitor controls. Anyone with developer tools can send a purchase for any amount. If your public dashboard or your investor update is built on that number, it is built on user input.
- It goes missing. Blockers, a closed tab before the script runs, a redirect straight back to the app, a payment completed in the processor's hosted checkout that never returns. Every one of those loses a real sale.
- It double counts. A refreshed confirmation page fires the event twice. Server-side webhooks are idempotent by event id; a page load is not.
- It never updates. The browser sees one moment: the purchase. It never sees the refund, the failed renewal, or the chargeback two months later.
Under-reporting is the more dangerous of the two failure modes, because it is silent and it is not evenly distributed. Blockers are more common in some audiences than others, so the channels with the most technical audiences lose the most revenue, and you conclude they perform worst.
How should refunds and chargebacks be handled?
Refunds should reduce attributed revenue for the channel that was originally credited. Otherwise the model rewards whichever channel is best at selling to people who ask for their money back.
Processors emit refund events specifically so you can do this. Stripe's charge.refunded fires whenever a charge is refunded, including partial refunds, and Stripe added created, updated and failed events for all refund types in 2024 (Stripe changelog). A refund arrives as its own signed event referencing the original charge, so the link back to the attributed journey survives.
Three rules keep the numbers honest:
- Subtract from the original channel, not from today's. A refund in June for an April order reduces April's attributed revenue for April's channel. Reporting it against June's mix corrupts both months.
- Handle partials by amount, not by count. A $100 order with a $30 refund is $70 of attributed revenue, not zero and not a hundred.
- Decide once whether you report gross or net, and label it. Both are legitimate. Silently mixing them is not.
If you sell subscriptions, the same discipline applies to renewals. A renewal is new revenue attributable to the original acquisition journey, and how far forward you carry that credit is a policy decision worth writing down before anyone asks why the numbers changed.
Revenue attribution vs marketing attribution: what is the difference in practice?
The two disciplines share models and diverge on everything downstream of the model.
| Question | Marketing attribution | Revenue attribution |
|---|---|---|
| What is credited | Conversions, events, leads | Transaction amounts |
| Source of the number | Browser, tag manager, form handler | Signed payment webhook or server API |
| Can the visitor influence it | Yes | No |
| Reacts to refunds | No | Yes |
| Handles subscription renewals | Not usually | Yes, as later revenue on the same journey |
| Typical output | Conversions per channel | Currency per channel, net of refunds |
| Good for | Campaign activity, funnel diagnosis | Budget decisions, channel payback |
Note what the table does not say. It does not say marketing attribution is wrong. If you are diagnosing a funnel, event-level attribution is exactly the right tool, and it is available far earlier in the journey than any payment is. The failure is using event counts where money decisions are being made, then discovering a quarter later that your cheapest conversions were also your least valuable.
Who needs revenue attribution, and who does not?
You need revenue attribution when you take money on your own site and spend money to acquire customers. You do not need it when one of those two is missing.
Clear cases for it:
- SaaS with self-serve checkout. Trials convert at different rates by channel, and plan mix varies by channel too. Counting trial starts hides both.
- Ecommerce with returns. Return rates differ sharply by channel, particularly discount-led and marketplace traffic. Gross attributed revenue flatters exactly the channels that return most.
- Any business running paid acquisition. You cannot compute payback on a conversion count without assuming an average order value, and the assumption is usually the thing you were trying to measure.
Cases where it is not the priority: a content site monetized by ads or sponsorships, a business whose sales close over email and land in an invoicing system with no web checkout, or a pre-revenue product where the honest metric is activation. In those cases event-level marketing attribution, done cleanly, is enough.
If you do need it, the connection to make is between your analytics and your payment processor. Statsy's Stripe revenue attribution page covers the webhook side, and revenue flows through the same five models, last touch, first touch, linear, time decay and position based, with a lookback window from 1 to 365 days.
What should you do next?
- Check where your current revenue number comes from. If it is set in JavaScript on a confirmation page, it is browser-reported and you should stop reporting it to anyone who makes decisions.
- Connect your payment processor's webhooks to your analytics and verify the signature on your endpoint. Every processor documents this, and every processor's library does it in one call.
- Subscribe to refund events as well as charge events, and make refunds reduce the originally credited channel and month.
- Rebuild last quarter's channel table in net revenue rather than conversions, and find the channel whose rank changes most. That channel is the one your budget has been wrong about.
- Write down your policy: gross or net, how long renewal revenue stays attributed to the acquisition journey, and what lookback window you use. Then leave it alone for a quarter.
Questions people ask
What is revenue attribution?
Assigning money received to the marketing touches that led to it. The credited unit is a real transaction amount from a payment processor, net of refunds, rather than a conversion count fired by a browser.
What is the difference between revenue attribution and marketing attribution?
Marketing attribution credits events such as signups and form fills. Revenue attribution credits transaction amounts. Revenue attribution reacts to refunds and renewals; event attribution does not. Only the revenue version supports payback and budget decisions.
Why are payment webhooks better than browser-reported revenue?
A signed webhook is authenticated server to server and cannot be edited, blocked or double counted by the buyer. It also keeps arriving, so refunds, failed renewals and chargebacks correct the original number automatically.
How should refunds affect attributed revenue?
A refund reduces the channel and the month that were originally credited, not the current month. Partial refunds subtract by amount, not by order count. Decide whether you report gross or net revenue and label it.
Do I need revenue attribution for a small business?
Yes, if you take money on your own site and spend money to acquire customers. No, if you monetize through ads or sponsorships, close deals offline, or are pre-revenue. Event attribution is enough in those cases.
