solobuild
Most solo builders install analytics the same way they install a favicon. You paste a script tag before launch, forget about it, and then open the dashboard three months later hoping it will tell you why nobody is paying. It never does. You get a chart of sessions by country, a bounce rate you cannot interpret, and a vague sense that traffic is either fine or not fine. The problem is not that the tool is bad. The problem is that nobody ever decided what question the tool was supposed to answer.
Analytics for a one-person business has a different job than analytics at a company with a growth team. You are not running experiments across five squads or building attribution models for a paid media budget. You have limited hours, one product, and a small number of decisions in front of you: what to build next, what to fix, and where to spend your attention. A good setup answers those three things and ignores everything else. This is how to build one in an afternoon and actually use it.
Most setups fail because they answer the wrong question
The default analytics dashboard is built around traffic, because traffic is easy to measure and easy to sell as a number that went up. Pageviews, sessions, users, average time on page. All of it is real data, and almost none of it changes what you do on Monday morning. If your pageviews jump 40% and your signups stay flat, you have learned something, but you learned it by accident. You were watching the wrong number the whole time.
There is a second failure mode that hits builders harder, and it is the opposite problem. You get excited about analytics, you install a full product analytics platform, and you start tracking forty custom events with names like button_clicked_v2 and modal_open_final. Two months later you cannot remember what half of them mean, the naming is inconsistent, and you avoid the dashboard because opening it feels like work. Over-instrumenting is just as useless as under-instrumenting, and it costs more time to create.
The way out is to start from decisions instead of from data. Write down the two or three questions you would genuinely change your behavior over. For most solo products that list looks something like: are people who sign up ever reaching the point where the product is useful, are they coming back, and is the thing I ship next week going to matter to anyone. Everything you instrument should trace back to one of those questions. If a metric cannot be connected to a decision, it does not go on the dashboard.
Google Analytics 4 deserves a specific mention here, because it is the default most people land on and it is a poor fit for this job. GA4 replaced the older session-based model with an event-based one, which is more powerful and considerably harder to reason about. Basic reports that used to be one click now live behind custom explorations, event-level data is capped at 14 months of retention, and getting real answers often pushes you toward BigQuery and Looker Studio. If you have an analytics engineer, that is fine. If you are the engineer, the marketer, and the support desk, it is a tax you do not need to pay.
The five numbers a one-person business actually needs
Activation is the first and most important one. Activation is the percentage of people who sign up and then reach the moment where your product does the thing it promised, whatever that is for you. For a writing tool it might be publishing a first draft. For an invoicing app it is sending a real invoice. This number tells you whether your onboarding works, and it is the single most common place where small products quietly bleed out. A rough industry rule of thumb is that activation under roughly 30% means the problem is your onboarding or your positioning, not your traffic.
Retention comes next, and for most solo products it should be measured in weeks, not days. Take everyone who activated in a given week and check how many of them came back and did the core action again seven, fourteen, and twenty-eight days later. What you want to see is the curve flattening out rather than going to zero. A curve that flattens at 20% means you have a small group of people who genuinely need this, and that group is your business. A curve that hits zero means you built something people try once, which is a very different problem from a traffic problem.
The third number is revenue, tracked at the level of individual events rather than a monthly total. New subscriptions, upgrades, cancellations, and failed payments each tell you something the aggregate hides. If MRR is flat, that can mean nothing happened, or it can mean you added six customers and lost six, which is an urgent situation dressed up as a calm one. Stripe gives you most of this in its own dashboard for free, and for a business under a few hundred customers that is usually enough.
Fourth is the acquisition source for people who actually convert, not for people who visit. Plenty of solo founders discover that the channel driving 80% of their traffic drives 5% of their paying customers, and that a single forum thread from four months ago quietly produces their best users. You need referrer data attached to signups, not just to sessions, which usually means capturing the referrer at registration and storing it on the user record. It is a small piece of work and it repays itself the first time you decide where to spend a weekend.
The fifth is qualitative, and most builders skip it. Session recordings and heatmaps show you what people do when they hit the part of your product you were sure was obvious. Watching five recordings of real users failing to find your pricing link will teach you more in ten minutes than a month of aggregate charts. This is the one place where a small sample beats a large one, because you are looking for a specific broken thing rather than a trend.
The tools worth considering in 2026
PostHog has become the default recommendation for technical solo founders, and the free tier is the reason. It includes 1 million events, 5,000 session recordings, and 1 million feature flag requests per month, which covers most products well past the point where they start making money. You get product analytics, funnels, recordings, and feature flags in one place, and it is open source if you ever want to self-host. The tradeoff is that PostHog is genuinely a lot of software, and if all you want is a traffic number, it will feel like using a workshop to hang a picture. Pay-as-you-go pricing past the free tier runs around $0.00005 per event, which stays cheap for a long time.
Plausible sits at the other end of the range and is built for people who want one clean page of numbers. It is cookieless, lightweight, and does not require a consent banner in most jurisdictions, which removes a real friction point from your site. Pricing starts around $9 per month for 10,000 pageviews, and funnels live on the higher Business tier at roughly $39 per month. If your product is content-led and your main question is which pages bring people in, Plausible is often all you need. It will not tell you what happens inside your app.
Fathom occupies almost the same space with a slightly more polished interface and EU data isolation, at around $14 to $15 per month for 100,000 pageviews. Umami is the option for people who would rather run their own thing, since it is MIT licensed and cheap to host on a small VPS, and Umami Cloud offers a generous free tier of roughly 1 million events per month. Between those three the differences are mostly about taste and whether you enjoy maintaining infrastructure. None of them will replace product analytics if you have a real application with user accounts.
Microsoft Clarity is the one nobody should skip, because it costs nothing and has no traffic caps. You get unlimited session recordings, heatmaps, and rage-click detection, with recordings retained for 90 days. Microsoft is clearly using it to build a data position rather than a revenue line, which is worth knowing before you install it, but for a solo builder trying to understand why a signup flow leaks, it is hard to argue with free and unlimited. Run it alongside whatever else you choose rather than instead of something.
Mixpanel is the enterprise-adjacent option that occasionally makes sense. Its free plan covers up to 100,000 monthly tracked users with basic features, and paid Growth plans start around $28 per month and scale with volume. The reporting is strong and the funnel analysis is excellent, but the setup assumes someone whose job is analysis. Most solo products will get to the same answers faster with PostHog, and the ones that genuinely need Mixpanel usually know it already.
| Tool | Best For | Free Tier | Starting Price |
|---|---|---|---|
| PostHog | Apps with user accounts, funnels, feature flags | 1M events, 5K recordings/mo | ~$0.00005 per event after free tier |
| Plausible | Content sites, simple traffic answers | No | ~$9/mo (10K pageviews) |
| Fathom | Simple traffic with EU data isolation | No | ~$14/mo (100K pageviews) |
| Umami | Self-hosters and cost-sensitive builders | Yes, ~1M events/mo on Cloud | Free self-hosted, VPS cost only |
| Microsoft Clarity | Recordings and heatmaps, no traffic limits | Yes, unlimited | Free |
| Mixpanel | Deep behavioral analysis at larger scale | Up to 100K MTUs | ~$28/mo |
| Google Analytics 4 | Ad attribution and Search Console tie-ins | Yes | Free |
A setup you can finish in an afternoon
Start by writing the definition of activation for your product in one sentence, in plain language, before you touch any code. Something like: a user is activated when they have created a project and invited at least one collaborator. This sentence is the most valuable artifact of the whole exercise, because everything downstream depends on it and because it forces you to say out loud what your product is for. Put it somewhere you will see it again, in your repo README or in whatever workspace you already live in. If you run your business out of Notion, a single page holding your metric definitions is enough.
Then instrument a small number of events with names you will still understand in six months. Use a consistent pattern like object_action, so you get project_created, invite_sent, subscription_started. Five to eight events is plenty for a first pass, and you should be able to justify each one by pointing at a decision it informs. Resist the urge to add events speculatively, because unused events are not free: they are clutter that makes the useful ones harder to see.
Next, connect revenue and traffic sources. Capture the referrer and any UTM parameters at signup and store them on the user record, so that months later you can group paying customers by where they came from. Wire Stripe webhooks into the same place you keep your event data, or at minimum make sure subscription events land somewhere you can query. If you would rather not write glue code for this, an automation platform like Make can move Stripe events into a sheet or database without a deploy.
Finally, set a weekly rhythm and make it small enough to survive a bad week. Fifteen minutes every Monday, looking at four things: activated users this week, the retention curve for the last few cohorts, net revenue movement, and two session recordings picked at random. Write one sentence about what you saw and one sentence about what you will do. If you are also running an email list, your provider's open and click data belongs in this same review, since tools like Kit will show you which topics your audience actually cares about, which is a useful early signal for what to build.
Reading the data without lying to yourself
Small numbers are noisy, and this trips up nearly everyone building alone. If eleven people signed up last week and fourteen signed up this week, that is not 27% growth, that is three people. The temptation to read a trend into a handful of events is strongest exactly when you most need to be honest with yourself, which is usually right after a launch. A useful discipline is to refuse to draw a conclusion from any change smaller than roughly 30 events, and to look at four-week rolling numbers instead of week-over-week ones.
The second trap is confirmation. You will find yourself opening the dashboard hoping for a specific answer, and dashboards are very good at supplying whatever answer you arrived with. Writing down your prediction before you look is a cheap fix that works surprisingly well. If you expected activation to rise after the onboarding change and it did not, that is information you would have talked yourself out of otherwise.
There is also a real cost to measuring things you cannot act on. Every metric on your dashboard occupies attention, and attention is the scarce resource in a one-person business. When you find yourself checking a number out of habit rather than to decide something, delete it from the view. A dashboard with four numbers you understand deeply beats one with twenty you skim.
FAQ
What analytics should a solopreneur use? For most solo builders the answer is a combination rather than a single tool. PostHog handles product events and funnels on a free tier that covers 1 million events per month, and Microsoft Clarity adds unlimited session recordings and heatmaps for free. If your product is a content site rather than an app, swap PostHog for Plausible or Fathom and you are done. Add GA4 only if you run ads or need the Search Console connection.
Is Google Analytics still worth using in 2026? It depends entirely on whether you buy traffic. GA4 remains free and integrates well with Google Ads and Search Console, which matters if those are part of your acquisition. For understanding what happens inside a product, the event-based model, the 14-month retention cap, and the exploration-heavy interface make it slower to get answers from than the alternatives. Many solo founders end up keeping GA4 installed for search data while doing their real analysis somewhere else.
How many events should I track? Fewer than you think. Five to eight well-named events cover most early products, and each one should map to a question you would act on. The failure mode is not missing an event, since you can always add one later and start collecting data from that point. The failure mode is fifty events with inconsistent names that make the dashboard unusable.
What is a good activation rate for a small SaaS product? The honest answer is that it varies enormously by product type and price point, so external benchmarks are of limited use. The commonly cited warning line is around 30%, below which the problem is usually onboarding or positioning rather than traffic. What matters more is your own trend over time, since you are trying to beat last month rather than an industry average. Measure it consistently for eight weeks before you draw any conclusion about whether it is good.
Do I need session recordings if I already have funnels? Funnels tell you where people drop off and recordings tell you why, so they answer different halves of the same question. A funnel showing 60% abandonment at your pricing page is a fact you cannot act on directly. Five recordings of people scrolling past a confusing plan comparison give you something to fix on Tuesday. Since Clarity costs nothing, there is little reason to choose between them.
What to actually do this week
If you are starting from nothing, install Microsoft Clarity and PostHog, define activation in one sentence, and instrument five events. That is a two to three hour job for most products and it will put you ahead of the majority of solo builders, who either have nothing or have GA4 and never open it. Do not build a dashboard yet. Collect data for four weeks first, because a dashboard built before you have data tends to be designed around what you hope to see.
If you already have analytics and never look at them, the fix is subtraction rather than addition. Open your dashboard, remove every metric you cannot connect to a decision, and see what is left. Most people are surprised at how few survive, and how much easier the remaining ones are to think about. Then put fifteen minutes on your calendar for Monday and treat it like a meeting with someone else.
The point of all of this is not to become a data-driven company, since a one-person business does not have enough data to be driven by. The point is to stop guessing about the two or three things where guessing is expensive. Whether people who sign up ever get value, whether they come back, and where the ones who pay you came from. Everything past that is optional, and most of it is a distraction dressed up as rigor.