What is revenue attribution?

Revenue attribution links each sale to the marketing touchpoint that brought the buyer in, so you can see which channels earn money and not just visits. It means connecting every sale to the newsletter issue, the Reddit thread, the Google search or the YouTube video that started the journey. Instead of asking “where did my traffic come from?”, it answers the question that decides your budget: “where did my customers come from, and how much did they pay?”

Most analytics tools stop at the visit. They count sessions, pageviews and sign-ups by source, and leave you to guess which of those turned into money. Most payment tools stop at the payment. Stripe knows who paid and how much, but it has no idea that the buyer first arrived from a podcast mention three weeks earlier. Revenue attribution is the join between those two worlds.

Why traffic numbers are not enough

Traffic is easy to grow and easy to misread. A post that hits the front page of a forum can send ten thousand visitors who never buy anything, while a niche newsletter sends two hundred who convert at ten percent. If you rank channels by visitors, the forum looks like the winner. If you rank them by revenue, it is not close.

The same trap applies to sign-ups and leads. A channel that produces many free accounts can still produce few paying ones. Unless the payment itself is tied back to the source, you are optimizing a proxy, and proxies drift.

The four ingredients

Every working revenue attribution setup, whether you build it yourself or buy it, needs the same four parts:

1. Source capture. On every visit, record where the visitor came from: the referring site, any UTM parameters on the link, and ad click IDs such as gclid when there is nothing else.
2. A way to recognize the same visitor later. Buyers rarely pay on their first visit. A first-party identifier, kept on your own domain, lets the later purchase be matched to the earlier visits.
3. A trustworthy record of the payment. The sale should come from the payment processor or your server, not only from a “thank you” page in the browser, which ad blockers, closed tabs and impatient buyers all skip.
4. A rule for giving credit. When a buyer touched several channels, which one gets the sale, and how far back do you look? This is the attribution model and its lookback window.

Where attribution breaks

Knowing the failure modes keeps you from over-trusting any single number:

• Checkout redirects. When a buyer returns from a hosted checkout page, the browser reports the payment provider as the referrer. A naive setup then credits the sale to “checkout.stripe.com”.
• Short-lived storage. Safari and Brave cap cookies written by JavaScript at about seven days. A buyer who comes back after two weeks can look like a new, direct visitor.
• Several devices. Someone who discovers you on their phone and pays on a laptop is two visitors to any tool that does not ask them to sign in.
• Dark social. Links pasted into chat apps, emails and documents usually arrive with no referrer at all, so they show up as direct traffic unless the link carried UTM tags.

None of this makes attribution useless. It means you should read it as strong directional evidence, compare channels against each other over the same period, and tag the links you control so less traffic lands in “direct”.

Verified and browser-reported revenue

It helps to separate revenue you can trust from revenue you are told about. A sale that arrives from your payment processor’s webhook, or from your own server with a secret key, is verified: it happened, and the amount is right. A sale reported by JavaScript on a confirmation page can be blocked, repeated or faked. Both are useful, but they should never be silently added together.

How theBizness.ai does it

theBizness.ai is built around exactly these four parts:

• A small script (about 5 KB gzipped) records the referrer and UTM parameters of each visit and keeps a first-party visitor ID on your domain.
• You connect Stripe with a restricted key, or connect your Whop business, and we create the webhook that reports each sale, refund and cancellation as verified revenue. Other processors can report sales from your server.
• To match a sale to a visit, your checkout passes three IDs (website, visitor and session) in its metadata. It is a short copy-paste snippet, or a ready-made prompt you can give your AI coding agent. Without the IDs the sale is still recorded, but it is not linked to a visit.
• Each sale is credited to the source of the visitor’s most recent visit that had a referrer or UTM tag, within 30 days before the purchase (30 days is the upper limit; Safari and Brave shorten how long a browser remembers a visit). A visit with no source never overrides a real one, and returns from Stripe Checkout, PayPal, Paddle, Lemon Squeezy and Google sign-in are ignored, so the original channel keeps the credit.
• Revenue reported from the browser is labeled client-reported and kept apart from verified revenue.

The result is a report of revenue, orders and conversion rate by source, medium and campaign, plus each customer’s path to purchase. The full technical detail is in the revenue attribution docs.

Getting started

Adding the script takes about 2 minutes, and getting revenue connected and matched takes about 10 in total. You do not need a perfect model to make better decisions. Tag the links you share with UTM parameters (our free UTM builder helps), connect the payment processor you actually use, and give the data a few weeks. The first time you see a small channel quietly outearning a big one, attribution has paid for itself. See the features and pricing (14-day free trial, no card), or the installation guide to start.