How to track revenue from your website
Most analytics dashboards show you traffic. Pageviews, unique visitors, bounce rate, session duration. These numbers tell you whether people visit your site. They do not tell you whether your site makes money.
Revenue attribution — connecting a specific dollar amount to the traffic source, landing page, or campaign that generated it — is the difference between knowing your website is popular and knowing your website is profitable. This guide explains how to set it up, what the options are, and where the common pitfalls lie.
Why pageviews are misleading
Consider two blog posts on a SaaS marketing site. Post A gets 10,000 pageviews per month from organic search. Post B gets 800 pageviews per month, mostly from a niche developer forum. Based on pageviews alone, Post A is the clear winner — it drives 12 times more traffic.
But Post A is a generic listicle that attracts casual browsers. Its conversion rate to trial signup is 0.1%. Post B is a deep technical tutorial that attracts people with an active problem your product solves. Its conversion rate is 5%. Post A generates 10 trial signups per month. Post B generates 40.
If 20% of trial signups convert to paid at $50/month, Post A generates $100/month in MRR. Post B generates $400/month. The page with 12x less traffic produces 4x more revenue. Without revenue attribution, you would never know this. You would invest more in content like Post A because it "performs better" — and you would be optimizing for the wrong metric.
This pattern is universal. It applies to ecommerce (high-traffic product pages with low conversion vs. niche pages with high purchase intent), to lead generation (contact form submissions that become customers vs. those that do not), and to any business where the value of a visitor varies by source and intent.
The revenue attribution chain
Revenue attribution connects four pieces of data:
1. Traffic source. Where the visitor came from — organic search, paid ad, social media, referral, direct. This is captured through referrer headers and UTM parameters.
2. Landing page. The first page the visitor saw. This tells you which content or page attracted them.
3. Conversion event. The action the visitor took — signed up, purchased, submitted a form. This links the visit to a business outcome.
4. Revenue amount. The actual dollar value of the conversion — subscription amount, purchase total, deal size. This connects the business outcome to money.
Most analytics tools handle steps 1 and 2 automatically. Step 3 requires conversion goal setup. Step 4 — the actual revenue connection — is where most tools fall short. This is the gap that revenue attribution fills.
Approach 1: Manual event tracking
The traditional approach is to fire a custom analytics event when a purchase occurs, with the revenue value as a property. In Google Analytics, this looks like:
gtag('event', 'purchase', {
transaction_id: 'T12345',
value: 49.99,
currency: 'USD',
items: [{ item_name: 'Pro Plan' }]
})This works in theory. In practice, it has several failure modes:
The event fires on the wrong page. If you track the purchase on a "thank you" page, visitors who are redirected from Stripe back to your site may hit that page before the analytics script loads. The purchase event never fires. Or the visitor's browser blocks the analytics script entirely, and the purchase is invisible.
Developers forget to update it. When pricing changes, when new products are added, or when the checkout flow is refactored, the revenue tracking code needs to be updated. It lives in your frontend codebase, often in a corner that no one thinks about until the data stops making sense.
Refund and chargeback handling. If you report revenue at the point of purchase, you are counting revenue that may later be refunded. Accurate revenue tracking needs to account for refunds, but client-side event tracking has no mechanism for this — the refund happens in Stripe, not in the browser.
Double-counting on page refresh. If the purchase event fires on a confirmation page and the visitor refreshes that page, you count the revenue twice. Deduplication requires transaction IDs and server-side logic that most implementations skip.
Approach 2: Server-side integration
A more reliable approach is to track revenue on the server side — listening for payment events from your payment processor and linking them to the analytics visitor who initiated the purchase.
Building this yourself requires:
Stripe webhook integration. Listen for checkout.session.completed events from Stripe. Each event contains the payment amount, currency, and customer details.
Visitor-to-checkout linking. Before redirecting to Stripe Checkout, you need to pass a reference to the analytics visitor (a visitor ID or session ID) as metadata on the checkout session. When the webhook fires, you read this metadata to link the payment to the correct analytics visitor.
Attribution logic. Once you know which visitor made the purchase, you need to look up their traffic source, landing page, UTM parameters, and session history. This requires your analytics data to be queryable and joinable with payment data.
This is a substantial engineering project. You are essentially building a data pipeline that joins two systems (analytics and payments) with different data models, different latencies, and different reliability characteristics. Most teams that attempt this in-house either build something fragile that breaks silently or spend weeks on infrastructure that is not their core product.
Approach 3: Built-in payment integration
The simplest approach is to use an analytics tool that integrates with your payment processor directly. sourcebeam, for example, connects to Stripe and handles the entire attribution chain automatically:
When a visitor clicks a checkout link on your site, sourcebeam attaches the visitor's analytics session as metadata on the Stripe checkout session. When the payment completes, Stripe's webhook notifies sourcebeam, which links the payment amount to the visitor's traffic source, landing page, UTM parameters, and session history.
The result is that you can see, in your analytics dashboard:
"Organic search generated $4,200 in revenue this month from 12 purchases. The average revenue per visitor from organic search is $0.84. Twitter referrals generated $1,100 from 5 purchases, with an average revenue per visitor of $2.20."
This data reveals that Twitter sends fewer visitors but higher-intent ones — each Twitter visitor is worth 2.6x more than an organic search visitor. That insight directly informs where you should invest your marketing effort.
No custom event code. No webhook implementation. No data pipeline. Connect Stripe in the settings, and revenue attribution is automatic.
UTM parameters: the foundation of campaign tracking
Revenue attribution only works if you know where visitors come from. For organic traffic, referrer headers provide this. For campaigns — emails, ads, social posts, partner links — you need UTM parameters.
UTM parameters are query strings appended to your URLs:
The five standard UTM parameters:
utm_source — the platform or publisher (twitter, google, newsletter, partner-blog).
utm_medium — the marketing medium (social, cpc, email, referral).
utm_campaign — the specific campaign name (spring-launch, black-friday-2026, product-update).
utm_term — the paid search keyword (optional, mostly used for Google Ads).
utm_content — to differentiate between variants (header-cta, footer-link, sidebar-banner).
Analytics tools — including sourcebeam — capture UTM parameters automatically. When combined with revenue attribution, you can see exactly how much money each campaign generated. Not how much traffic. How much money.
Common UTM mistakes: Inconsistent naming (using "Twitter", "twitter", and "tw" for the same source). Not using UTMs on social media posts (organic social traffic often shows as "direct" without UTMs). Using UTMs on internal links (which overwrites the original traffic source). Not documenting UTM conventions across the team (leading to messy, unanalyzable data).
Multi-touch attribution
A customer's journey from discovery to purchase often involves multiple touchpoints. They might discover your product through a blog post (organic search), return a week later from a newsletter (email), and finally purchase after clicking a retargeting ad (paid). Which touchpoint gets credit for the revenue?
First-touch attribution credits the first interaction — the blog post that initially attracted them. This model values discovery and top-of-funnel content.
Last-touch attribution credits the last interaction before conversion — the retargeting ad. This model values the final trigger. Most analytics tools default to last-touch because it is the simplest to implement.
Linear or multi-touch attribution distributes credit across all touchpoints. The blog post, the newsletter, and the ad each get a share of the revenue. This is the most accurate model but requires tracking the full visitor journey across sessions.
For most small businesses, last-touch attribution is a reasonable starting point. It answers "what was the final trigger?" which is the most actionable question. First-touch is useful for understanding which channels drive initial awareness. Multi-touch requires enough data volume and analytical sophistication that it is rarely worth the complexity for businesses under a few million in annual revenue.
sourcebeam tracks visitor journeys across sessions, so you can see the full path from first touch to purchase — even if the attribution model in the dashboard is last-touch. The raw data is available through the API for more sophisticated analysis if needed.
What to do with revenue data
Revenue attribution is only useful if it changes your decisions. Here are the specific questions it answers:
Which marketing channels should I invest more in? Compare revenue per visitor across channels. If organic search generates $0.50 per visitor and your newsletter generates $3.00 per visitor, the newsletter audience is 6x more valuable — even if it is smaller.
Which content should I create more of? Sort blog posts by revenue generated, not pageviews. Double down on the type of content that attracts buyers, not browsers.
Which campaigns are worth repeating? Compare campaign cost (ad spend, influencer fees, partnership costs) against attributed revenue. A campaign that cost $500 and generated $3,000 in revenue has a 6x ROAS. One that cost $500 and generated $200 should not be repeated.
Which landing pages need work? Compare pages by revenue per visitor, not just conversion rate. A pricing page with a 2% conversion rate and $50 average order value generates $1.00 per visitor. A features page with a 0.5% conversion rate and $200 average order value generates $1.00 per visitor too. Same revenue per visitor, very different optimization strategies.
Getting started
If you use Stripe, the fastest path to revenue attribution is an analytics tool with built-in Stripe integration. Our guide on how to connect Stripe to your analytics walks through the full setup. sourcebeam handles this automatically — connect Stripe in settings, and every checkout is attributed to its traffic source.
If you use a different payment processor, you will need manual event tracking or a server-side integration. The manual approach is faster to implement but less reliable. The server-side approach is robust but requires engineering effort.
Whatever approach you choose, start with UTM parameterson your campaigns. Consistent UTM usage is the foundation — without it, all your paid and social traffic shows up as "direct" or "referral" with no campaign differentiation. Define a naming convention, document it, and enforce it across your team.
sourcebeam connects to Stripe automatically — revenue attribution with zero configuration. Try it free