How to connect Stripe to your analytics and track revenue per visitor

Analytics tools are excellent at counting things. They tell you how many people visited your site, which pages they viewed, how long they stayed, and where they came from. These metrics feel informative. They fill dashboards with numbers that go up and to the right. But none of them answer the question that matters most: is this making money?

Pageviews measure attention, not value. A page with 50,000 views might generate zero revenue if the visitors are not in a buying mindset. A page with 200 views might generate $10,000 if every visitor is a high-intent buyer from a targeted campaign. Without revenue data attached to your analytics, you have no way to distinguish between these two scenarios. You treat all traffic as equal, and it is not.

The same problem applies at the channel level. You might know that Google sends 60% of your traffic and Twitter sends 5%. But if Twitter visitors convert at 10x the rate and spend 3x more per purchase, Twitter is actually your most valuable channel by revenue — despite being a footnote in your traffic report. Pageview data alone would never surface this insight.

This blindness compounds over time. When you allocate marketing budget based on traffic volume instead of revenue, you systematically overinvest in channels that generate attention and underinvest in channels that generate money. Every month, the gap between what you think is working and what is actually working grows wider.

Your analytics tool knows about visitors. It tracks sessions, referrers, UTM parameters, device types, and pageviews. It knows that a visitor arrived from a Google ad at 2:14 PM, viewed three pages, and left after four minutes.

Your Stripe account knows about payments. It tracks charges, subscriptions, invoices, refunds, and customer emails. It knows that someone@example.com paid $49 for a Pro plan at 2:22 PM.

The problem is that these two systems do not share a common identifier. Your analytics tool does not know the visitor's email. Stripe does not know the visitor's traffic source. There is no built-in connection between "visitor from Google ad" and "$49 payment from someone@example.com." The data exists in both systems, but the link between them is missing.

This is not a minor inconvenience. Without this link, you cannot answer questions like: which traffic source generates the most revenue? Which landing page leads to the highest average order value? Which campaign has a positive return on ad spend? These are the questions that drive real business decisions, and they require data from both systems joined together.

Revenue attribution is the process of connecting a specific payment back to the traffic source, landing page, or campaign that brought the paying visitor to your site — building on the conversion tracking you already have in place. It answers the question: where did this money come from?

More precisely, it creates a chain of four data points:

Traffic source. Where the visitor originated — organic search, paid ad, social media post, email newsletter, referral link, or direct visit. This is captured through referrer headers and UTM parameters.

Landing page. The first page the visitor saw on your site. This tells you which content or product page attracted them and made the initial impression.

Conversion event. The action the visitor took — starting a trial, purchasing a product, subscribing to a plan. This links the anonymous visit to a business outcome.

Revenue amount. The actual dollar value from Stripe — the charge amount, subscription MRR, or one-time payment total. This turns the business outcome into a concrete number.

When all four pieces are connected, you can say things like: "visitors from our March newsletter who landed on the pricing page generated $1,800 in revenue from 6 purchases." That level of specificity is what separates guessing from knowing.

Without revenue attribution, marketing decisions are based on proxy metrics. You optimize for traffic because it is measurable. You celebrate a blog post that went viral because it drove 20,000 visitors. You keep running the Google Ads campaign because it has a good click-through rate.

But proxy metrics can be deeply misleading. The viral blog post might attract an audience with zero purchase intent. The Google Ads campaign might have great CTR but terrible conversion rates because the ad copy attracts the wrong people. You would never know without connecting the revenue data.

Revenue attribution changes the conversation from "which channel drives the most traffic?" to "which channel drives the most revenue?" These are often very different answers. And the second question is the one that actually matters for building a sustainable business.

When you can see that a specific podcast appearance generated $3,200 in revenue from 8 new customers, while a month of daily tweets generated $400, you know where to invest your time. When you can see that visitors from your documentation site convert at 5x the rate of visitors from your blog, you know which content strategy to prioritize. Revenue attribution turns vague intuition into precise feedback loops.

The most basic approach is to export data from both systems and match them manually. Export your Stripe payments with customer emails and timestamps. Export your analytics data with visitor sessions and traffic sources. Open a spreadsheet and try to match the payment email to a signup event in your analytics, then trace that signup back to a traffic source.

This approach has several problems. First, it is time-consuming. Matching records across two exports requires manual work for every reporting period. Second, the match rate is low — analytics tools often do not capture the email address, so you are matching on timestamps and guesswork. Third, it is error-prone. A single timezone mismatch or duplicate email can corrupt your attribution.

Fourth, and most importantly, it does not scale. When you have 10 payments a month, this might take an hour. When you have 500 payments a month, it is unworkable. And by the time you finish the analysis, the data is already stale. Marketing decisions need timely data, not a report that arrives two weeks late.

Manual matching can be useful as a one-time exercise to understand your attribution landscape, but it is not a sustainable workflow.

A more robust approach is to build a server-side integration using Stripe webhooks and your analytics platform's API. The idea is straightforward: when a payment happens in Stripe, your server receives a webhook event, extracts the payment details, links it to the corresponding analytics visitor, and records the attribution.

The implementation looks roughly like this:

Step 1: Pass visitor identity to checkout.When a user clicks your "Buy" or "Subscribe" button, include the analytics visitor ID or session ID as metadata on the Stripe Checkout session. This creates the link between the anonymous visitor and the upcoming payment.

const session = await stripe.checkout.sessions.create({
  line_items: [{ price: 'price_xxx', quantity: 1 }],
  mode: 'subscription',
  metadata: {
    analytics_visitor_id: visitorId,
    analytics_session_id: sessionId,
  },
  success_url: 'https://yoursite.com/success',
  cancel_url: 'https://yoursite.com/pricing',
})

Step 2: Listen for payment webhooks. Set up a webhook endpoint that receives checkout.session.completed events from Stripe. When a payment succeeds, read the metadata to get the visitor ID, then query your analytics backend for that visitor's traffic source, landing page, and UTM parameters.

Step 3: Store and aggregate the attribution data. Write the payment amount alongside the traffic source to a database. Build queries to aggregate revenue by source, by page, by campaign, and by time period.

This approach is powerful and flexible. You control every aspect of the data pipeline. But the engineering effort is significant: webhook handling, retry logic, idempotency, database schema design, aggregation queries, and a reporting interface. For most teams, this is weeks of development time that could be spent on their core product.

The third approach is to use an analytics tool that connects to Stripe natively, handling the entire attribution pipeline without custom code. sourcebeam is built with this integration at its core — you connect your Stripe account in settings, and revenue attribution works automatically.

When a visitor on your site clicks a checkout link, sourcebeam attaches the visitor's session metadata to the Stripe Checkout session. When the payment completes, Stripe's webhook notifies sourcebeam, which links the payment to the visitor's full session history — traffic source, landing page, referrer, UTM parameters, and browsing path.

This eliminates the engineering overhead entirely. No webhook endpoints to maintain, no database schema to design, no aggregation queries to write. The attribution data appears in your analytics dashboard alongside your traffic data, ready to filter and analyze.

The tradeoff is less customization compared to a fully custom pipeline. If you need revenue attribution combined with proprietary business logic — say, attributing revenue across a multi-product suite with complex cross-sell rules — a custom solution gives you more control. But for the vast majority of SaaS businesses, ecommerce stores, and subscription products, a native integration handles the job with zero ongoing maintenance.

Conversion rate is the standard metric for measuring website effectiveness. It tells you what percentage of visitors take a desired action. But conversion rate alone is incomplete because it treats all conversions as equal.

A visitor who purchases a $9 starter plan and a visitor who purchases a $299 enterprise plan both count as one conversion. Your conversion rate treats them identically. Revenue per visitor does not.

Revenue per visitor is calculated by dividing total revenue by total visitors for a given segment — a traffic source, a landing page, a campaign, a time period. If 1,000 visitors from organic search generated $500 in revenue, your revenue per visitor from organic search is $0.50. If 200 visitors from a partner referral generated $600, your revenue per visitor from that referral is $3.00.

This single metric captures both conversion rate and average order value in one number. The partner referral visitors are worth 6x more each, not because they convert at a higher rate (though they might), but because the combination of their conversion rate and their purchase amount produces more revenue per person.

Revenue per visitor gives you a common currency to compare across channels, pages, and campaigns. It answers the question you actually care about: how much is each visitor worth?

Once you have revenue attribution in place, the first thing to look at is revenue by traffic source. This breaks down your total revenue by where the paying visitors came from — organic search, paid ads, social media, email, referrals, and direct traffic.

The results are often surprising. Many businesses find that their highest-traffic channel is not their highest-revenue channel. A common pattern is that organic search drives the most visitors but has a low revenue per visitor because it attracts a mix of high-intent and low-intent queries. Meanwhile, email or referral traffic — which might be a small fraction of total visits — converts at a much higher rate because those visitors already know and trust the brand.

For paid channels, revenue per visitor becomes even more critical because you can compare it against your cost per visitor (ad spend divided by visitors). If Google Ads sends you visitors at $1.50 each and those visitors generate $0.80 in revenue each, you are losing money. If a niche industry newsletter sends visitors at $0.30 each and they generate $2.00 in revenue each, that is a profitable channel worth scaling.

This analysis should happen monthly at minimum. Traffic quality shifts over time as your audience evolves, ad targeting changes, and competitors enter the market. A channel that was profitable last quarter might not be profitable this quarter.

Landing page analysis by revenue reveals which of your pages are actually generating money versus which are generating vanity metrics. Sort your pages by revenue attributed (not by pageviews), and you get a fundamentally different picture of your site's performance.

Your pricing page will likely show high revenue per visitor, which makes sense — visitors who view pricing are deep in the buying process. More interesting are the content pages. Which blog posts attract visitors who eventually pay? Which feature pages lead to signups that convert to paid plans?

Consider two blog posts. One is a broad tutorial that ranks well and gets 8,000 visits a month. The other is a narrow case study about solving a specific problem with your product, getting 300 visits a month. If the case study has 20x the revenue per visitor, it is actually your more valuable piece of content. You should create more content like it, link to it more prominently, and potentially promote it with paid distribution.

Revenue per landing page also helps you identify underperforming pages in your conversion funnel. If your homepage has high traffic but low revenue per visitor compared to your product pages, that suggests your homepage is not effectively routing visitors toward high-intent paths. It is an optimization opportunity that pageview-only analytics would never surface.

Campaign-level revenue attribution answers the most direct question in marketing: did this campaign make money? When every campaign is tagged with UTM parameters and every payment is attributed back to its source campaign, you can calculate the return on investment for each individual effort.

A Google Ads campaign costs $2,000 per month and generates $6,500 in attributed revenue. That is a 3.25x return on ad spend (ROAS). A sponsored newsletter placement costs $400 and generates $1,800. That is a 4.5x ROAS. Both are profitable, but the newsletter is more efficient per dollar spent.

Without revenue attribution, you would evaluate these campaigns on traffic metrics — clicks, CTR, cost per click, bounce rate. Those metrics can be misleading. A campaign with a high bounce rate might still generate significant revenue if the visitors who do convert have large order values. A campaign with excellent engagement metrics might generate zero revenue if it attracts the wrong audience.

Campaign-level attribution also helps with creative decisions. If you are running multiple ad variants, you can see which variant generates the most revenue — not just the most clicks. The difference matters because the ad copy that maximizes clicks often makes broad promises, while the ad copy that maximizes revenue qualifies the audience and attracts genuine buyers.

The technical core of Stripe-to-analytics attribution is passing a visitor identifier through the checkout process. Here is how the flow works:

1. Visitor arrives on your site. Your analytics tool assigns a visitor ID (usually stored in a first-party cookie or localStorage). It also records the traffic source, referrer, UTM parameters, and landing page.

2. Visitor clicks a checkout button. Your server creates a Stripe Checkout session. At this point, you include the analytics visitor ID as metadata on the session. This is the critical linking step — it connects the anonymous analytics visitor to the upcoming Stripe transaction.

3. Visitor completes payment. Stripe processes the payment and fires a checkout.session.completed webhook. The webhook payload includes your metadata with the visitor ID, plus the payment amount and currency.

4. Attribution happens.Your analytics backend receives the webhook, reads the visitor ID from metadata, looks up the visitor's session history, and attributes the revenue to the original traffic source, landing page, and campaign.

The key requirement is that the visitor ID is available on your server when creating the Stripe Checkout session. If you are using Stripe's client-side checkout, you need to pass the visitor ID from the browser to your server (via a hidden form field, API parameter, or cookie that your server can read). If you are using server-side checkout creation, you read the visitor ID from the request cookies or session.

Revenue attribution through Stripe seems straightforward in theory, but several real-world complications can throw off your data:

Asynchronous payments. Not every Stripe transaction completes immediately. Bank transfers, SEPA debits, and some payment methods have a delay between checkout initiation and payment confirmation. Your attribution system needs to handle the gap — storing the visitor ID at checkout creation and attributing the revenue when the payment eventually succeeds, which could be hours or days later.

Refunds and chargebacks. If you attribute $100 in revenue to a Google Ads campaign and that payment is later refunded, your attribution should be updated to reflect the refund. Otherwise, your revenue reports overstate performance. A robust system listens for charge.refunded and charge.dispute.created webhooks and adjusts attributed revenue accordingly.

Free trials and delayed conversions. For subscription products with free trials, the checkout happens at trial start but revenue only flows when the trial converts to paid. You need to decide whether to attribute revenue at trial start (optimistic) or at first payment (conservative). The conservative approach is more accurate but means your attribution data has a lag equal to your trial period.

Multi-touch attribution. A customer might visit from a Google ad on Monday, return from an email on Wednesday, and purchase on Friday via a direct visit. Which touchpoint gets credit? First-touch gives all credit to the ad. Last-touch gives all credit to the direct visit (which is unhelpful). Most analytics tools default to last-touch or first-touch, but be aware of what model your tool uses so you interpret the data correctly.

Subscription renewals. For recurring subscriptions, should renewal payments be attributed to the original traffic source? There is no universally right answer. Some businesses attribute only the first payment to the acquisition source and treat renewals as organic retention. Others attribute all payments from a customer to the original source to calculate true lifetime value by channel. Choose one approach and be consistent.

Currency conversion. If you accept payments in multiple currencies, your attribution system needs to normalize revenue to a single currency for comparison. Stripe provides the amount in the payment currency, but comparing $100 USD and 95 EUR requires exchange rate handling.

Connecting analytics with payment data raises legitimate privacy considerations. You are linking browsing behavior (which pages someone viewed, where they came from) with financial data (what they paid). This combination requires careful handling.

Minimize personal data in the link.The connection between analytics and Stripe should use an anonymous visitor ID, not the customer's email or name. The analytics system does not need to know who the customer is — it only needs to know which anonymous visitor session produced the payment. This preserves the analytical value while minimizing personal data exposure.

Aggregate, do not individualize.Revenue attribution is most useful at the aggregate level — revenue per channel, per page, per campaign. You rarely need to see that "visitor #12345 from Google Ads paid $49." Instead, you need to see that "visitors from Google Ads generated $4,900 across 100 purchases." Aggregation inherently provides privacy protection.

GDPR and data processing agreements. If you operate in the EU or have EU visitors, connecting analytics with payment data constitutes data processing that must comply with GDPR. Ensure your analytics tool has a Data Processing Agreement (DPA), stores data in appropriate jurisdictions, and provides mechanisms for data deletion requests. Using a privacy-focused analytics tool that avoids cross-site tracking and cookie consent requirements simplifies compliance significantly.

Data retention policies. Define how long you keep attributed revenue data. You probably do not need visitor-level attribution data older than 12-24 months. Aggregate reports can be kept indefinitely, but individual session-to-payment links should have a retention period to limit exposure.

If you are starting from zero, here is a practical sequence for setting up Stripe revenue attribution:

Step 1: Get your analytics foundation in place. Before you can attribute revenue, you need reliable traffic source tracking. Make sure your analytics tool is installed on every page, correctly capturing referrers and UTM parameters. Test by visiting your site from different sources and verifying they appear correctly in your dashboard.

Step 2: Standardize your UTM parameters.Create a naming convention for utm_source, utm_medium, and utm_campaign. Document it in a shared spreadsheet or wiki. Common conventions: lowercase everything, use hyphens instead of spaces, be specific but consistent (e.g., "google-ads" not sometimes "google" and sometimes "adwords").

Step 3: Connect Stripe to your analytics. If your analytics tool has a native Stripe integration (like sourcebeam does), this is a one-click setup in your settings. Authorize the Stripe connection and the integration handles the rest — attaching visitor IDs to checkout sessions, receiving webhooks, and attributing payments.

If you are building a custom integration, implement the checkout metadata flow described earlier: pass the analytics visitor ID as Stripe Checkout session metadata, then build a webhook endpoint to receive payment events and link them to your analytics data.

Step 4: Verify the connection.Make a test purchase (use Stripe's test mode). Check that the payment appears in your analytics dashboard attributed to the correct traffic source. If you visited from a UTM link, verify the payment shows up under that campaign. If it does not, check that the visitor ID is being passed correctly in the checkout session metadata.

Step 5: Wait for data to accumulate. Revenue attribution becomes meaningful once you have enough data points. A single payment attributed to organic search is anecdotal. Fifty payments attributed across five different channels is a pattern you can act on. Give it at least two to four weeks of data collection before drawing conclusions.

Step 6: Review and act. Set a recurring cadence — weekly or monthly — to review your revenue attribution data. Look at revenue per visitor by channel, by landing page, and by campaign. Identify your highest-ROI channels and double down. Identify underperformers and either optimize them or cut them. The data is only valuable if it changes your behavior.

Step 7: Iterate on attribution quality. Over time, refine your setup. Add UTM parameters to channels you were not tracking. Fix inconsistencies in your naming conventions. Consider how you handle trials, refunds, and renewals. Attribution is not a one-time setup — it improves gradually as you cover more edge cases and clean up your data hygiene.