Which traffic source actually produced paying customers?

Two reports, open side by side. The traffic report says your largest source is search, then a social platform, then direct. The Stripe dashboard says you had eleven paying customers this month. Both are correct and neither answers the only question that matters, which is which of those sources produced the eleven.

The join between them is a small piece of work that most founders postpone indefinitely. The reason to stop postponing it is that the two rankings are usually different. The channel that sends the most people is frequently not the channel that sends the people who pay, and if you optimise the first you can spend a quarter making the second one worse.

Why joining revenue to a traffic source is harder than it looks

Three things get in the way and they compound.

• The identity gap. Your analytics knows an anonymous visitor. Stripe knows a customer with an email address. Nothing automatically connects the two, and the moment where they could be connected, signup, is over in a second and easy not to instrument.
• The delay. Somebody reads an article in March, signs up in May and pays in June. By the time money moves, the visit that caused it is three months old and, in a cookieless tool, not identifiable at all.
• The multiplicity. Real customers turn up four or five times before paying: search, then a link from a friend, then direct, then direct again. There is no single true source, only a choice about which one to credit.

First touch, last touch, and why last-click attribution misleads

Given several visits you have to pick one to credit. Last touch, meaning the most recent source before signup, is the default in most tools because it is trivial to compute. It is also the most misleading option available to an early-stage product.

Think about how somebody arrives once they have already decided. They type your name, or they search for your name, or they use the bookmark. So last touch credits direct and branded search for nearly every conversion, and both of those are consequences of the decision rather than causes of it. Optimising for last touch means investing in what people do after you have already convinced them.

First touch, the source of the very first visit, is the more useful default before you have volume. It answers *where did this person come from originally*, which is the question you can act on, because it maps onto the work you would do next. It is not more true than last touch. It is more actionable, and at eleven customers a month you have nowhere near enough data for a multi-touch model to say anything meaningful.

The minimum viable join between Stripe revenue and traffic

You do not need an attribution platform. You need four steps and they all fit in an afternoon.

1. Capture the first-touch source and keep itOn the first visit, record where the visitor came from, meaning the referrer or the UTM parameters if the link carried any, and hold it for the length of the visit. If you are willing to store it on the device you can hold it longer, but storing it is exactly what puts you inside the consent rules, so decide that on purpose.
2. Write it onto the account at signupThis is the step everybody skips and the only one that is truly irreplaceable. When a user creates an account, save the first-touch source as a field on that account in your own database. It is one column. It is the bridge between the anonymous world and the identified one, and no vendor can add it for you afterwards.
3. Pass it to Stripe as customer metadataWhen you create the Stripe customer, put the source in the metadata. From that point every payment, subscription and refund carries the acquisition source with it, and the join stops being a join at all.
4. Group revenue by that fieldNow the question answers itself: revenue by first-touch source, trial-to-paid rate by first-touch source, and the number worth watching, revenue per visitor by source.

What revenue per visitor changes about your reporting

Once the source is on the account, compute revenue per visitor for each source: total revenue from customers whose first touch was that source, divided by visitors from that source over the same period. It is a crude number and it is enormously clarifying.

A channel sending a thousand visitors and no paying customers has a revenue per visitor of zero, however good the traffic chart looks. A channel sending forty visitors and two customers is, at that moment, your best channel. Founders routinely have this backwards, because the traffic chart is the one they see every day and the revenue side lives in a different tab.

Two cautions. Small numbers are noisy, two customers is not a trend, and you should resist rebuilding your strategy around a sample of two. And it takes a while to settle, because the customers arriving now were acquired by work you did months ago.

Where revenue attribution breaks down

• Refunds and churn. Revenue attributed on the first payment is not revenue kept. A source producing customers who refund produces a number that looks fine for a month.
• Long cycles. If the gap between first visit and payment is longer than the window you retained the source for, first touch is unavailable and the customer falls into an unknown bucket. Report that bucket rather than redistributing it.
• Multiple devices. Discovered on a phone, signed up on a laptop. The first touch you captured belongs to a session nothing connects to the signup.
• Self-reported source. Asking "how did you hear about us" at signup is worth doing, and the answers are more useful for discovery than for measurement. People misremember, and "Google" absorbs everything.

None of these is a reason not to do it. They are the reason to treat the output as a ranking rather than an accounting statement. You are working out which two things to do more of, not closing a ledger.

How DataSpice joins Stripe revenue to a traffic source

Bluntly: the manual version above works, and you should do it whatever tooling you use, because the account column belongs to you rather than to a vendor. What DataSpice removes is the tab-switching. Traffic, App Store Connect and Stripe revenue are read in one workspace, so the traffic ranking and the revenue ranking sit on the same screen instead of in two browser windows you compare by eye. The pricing page has the tiers, and the comparisons say plainly which tools do this better where they do.

Doing this join by hand is the work cookieless analytics for founders removes: the Stripe integration puts revenue beside the acquisition source that produced it, in one workspace.