Two hundred visitors, two customers. Every founder hits this and the first instinct is that something is broken.
Usually nothing is broken. A 1% visit-to-paid rate is inside the normal range for software, and the honest answer is that 200 visitors was never going to be many customers. But there are eight specific reasons those two numbers disagree, some of them are real measurement problems worth fixing, and they are worth separating before you go and rewrite your landing page.
They are ordered here by how much of the gap they typically explain.
1. They are counting different things
Your analytics tool counts sessions or unique browsers. Stripe counts paying customers. Between those two sit a series of steps, each of which loses most of the people who entered it.
A rough shape for a self-serve software product:
| Step | Typical rate | Of 200 visitors |
|---|---|---|
| Visit to signup | 2% to 5% | 4 to 10 |
| Signup to activation | 30% to 60% | 2 to 6 |
| Activated to paid | 10% to 25% | 0 to 2 |
Two customers from 200 visitors is the middle of that range, not a failure. Multiply the three rates and a 1% end-to-end conversion is what the arithmetic produces.
If you want a number to be alarmed by, it is not "200 to 2". It is a visit-to-signup rate under 1%, which usually means the traffic is wrong rather than the page.
2. A quarter of your visitors were never counted
Ad blockers and privacy browsers block analytics scripts. The proportion depends entirely on who your audience is: broad consumer traffic loses maybe 10%, and a developer audience loses a lot more. Surveys of developer tooling put script blocking somewhere between 25% and 40% for that group.
Those people can still sign up and still pay. So the direction of the error is consistent: your analytics undercounts visitors, and undercounts the specific visitors who are most likely to be technical buyers.
This makes your conversion rate look better than it is and your traffic look worse than it is. It is one of the few measurement problems where the two errors partly cancel.
You can reduce it by serving the tracking script from your own domain rather than a third-party host, which most privacy-first tools support. It does not solve the problem for anyone blocking by behaviour rather than by hostname.
3. A meaningful share of "traffic" is not human
Crawlers, uptime monitors, security scanners, preview bots from Slack and Twitter, and the newer wave of AI crawlers all hit your pages. Most analytics tools filter the well-behaved ones by user agent. Not all bots are well behaved.
For a small site with low absolute numbers this can be a large percentage. A hundred hits a day from a monitoring service you set up and forgot about is 3,000 visits a month that will never buy anything.
Check your top pages for anything that gets traffic but no engagement at all. If /health or /robots.txt shows up as a landing page, your filtering has a hole in it.
4. The visit and the payment were months apart
Someone reads a comparison post in March. They bookmark it. In June they have the problem again, search your brand name, and sign up.
If you are comparing this month's visitors against this month's customers, you are comparing two populations that barely overlap. This is why cohort reporting exists, and why "conversion rate this month" is close to meaningless for a considered purchase.
The fix is to measure by acquisition cohort, not by calendar month: of the people who first arrived in March, how many had paid by June.
5. Cross-device breaks the chain
Read the post on a phone during a commute. Sign up on a laptop that evening. Two browsers, two identifiers, and unless someone logged in on both, your analytics has two separate anonymous people, one of whom converted from nowhere.
This inflates your visitor count, deflates your conversion rate, and misattributes the customer to whatever brought the second device, which is usually direct or a brand search.
The only real fix is identity: once someone signs up, tie their anonymous history to their account. Any tool with an identify call can do this, and it is worth doing on the day you install rather than later.
6. The referrer was stripped, so it looks like Direct
A large slice of "Direct" traffic is not direct. It is traffic whose referrer was removed in transit:
- Links opened from native apps: Slack, Discord, iOS Mail, most desktop email clients
- Anything pasted into a message and clicked
- HTTPS to HTTP transitions
- Some in-app browsers
- AI assistants that send no referrer at all, which is now a real and growing category
The practical consequence is that your best-performing channel is often sitting inside Direct, unlabelled. If Direct is more than about a third of your traffic and you are not a well-known brand, that is where your missing attribution went.
Tagging links you control with UTM parameters recovers most of it. Our UTM builder is free and warns you about the four ways tagging usually breaks reporting.
7. Your UTM tags are fighting each other
utm_source=Twitter and utm_source=twitter are two different channels in most tools. So are utm_source=twitter.com and utm_source=x.com. Add a campaign where somebody used utm_medium=social on Monday and utm_medium=Social-Media on Wednesday, and one channel becomes four rows, each too small to notice.
Lowercase everything, decide once what your medium values are, and write them down somewhere. It takes ten minutes and it is the highest-return ten minutes in analytics.
8. Signups and customers are not the same event
Stripe knows about customers. Your analytics knows about visits. Between them is a signup that neither one sees properly unless you tell it.
If you have never sent a signup event to your analytics tool, then your funnel has a hole exactly where the interesting part is. You can see traffic, and you can see revenue, and you cannot see the step that connects them, which is where almost all of the loss happens.
A diagnostic sequence
Work down this list in order. Stop when a number surprises you.
- What is your visit-to-signup rate? Under 1% means a traffic or message problem, not a product one.
- What share of traffic is Direct? Over a third and you have an attribution problem, not a conversion problem.
- Do your top landing pages look like pages a person would land on? If not, filter bots harder.
- Does your signup count in analytics match your database? If not, the tracking is the problem and nothing downstream can be trusted.
- Are you comparing the same cohort on both sides? If not, redo it by acquisition month.
- What is your signup-to-paid rate by channel? This is where the real differences live, and it is the one most people have never looked at.
That last one is the whole reason we built Ripples, so discount accordingly. Traffic, signups, Stripe revenue and ad spend on one screen, attributed to first touch, so the 200 and the 2 are two ends of the same table instead of two browser tabs you are trying to reconcile. Free until $1K MRR, one script tag.
The uncomfortable summary
Most of the gap between 200 visitors and 2 customers is not measurement error. It is the funnel doing what funnels do. The measurement errors matter because they hide which channel is which, not because they explain the gap.
Fixing attribution will not raise your conversion rate. It will tell you which 40 of those 200 visitors were worth having, so you can go and get more of them.
Sources
- Ripples UTM builder, for the tagging problems in sections 6 and 7
- How to connect Stripe to Google Analytics, for the signup and revenue gap in section 8
- Ripples docs: identify, for tying anonymous history to an account after signup