Analytics for your first 100 users

You shipped. The store listing is live, your agent wrote most of the code, and eleven people have signed up. You open the analytics dashboard and it reports a 9.1% conversion rate, a flat retention curve, and a bounce rate you have no way to judge.

None of that is information. At eleven users, one person moves every percentage by nine points. The tools were built for products with thousands of users, and below a certain size they do not degrade gracefully. They report numbers that look precise and mean nothing.

This is about the first month instead: which questions have real answers at two-digit scale, how to read them, and which habits waste the little signal you have.

Why percentages break below about 30 users

Analytics tools report rates: conversion, retention, churn. A rate is a fraction, and fractions over small denominators swing hard.

You can compute how hard. The margin of error on a proportion is roughly 1.96 × √(p(1-p)/n). At 11 users and a measured rate of 27%, that is about 26 points either side: the true rate sits somewhere between roughly 1% and 53%. At 100 users it narrows to about 9 points. At 1,000 it is under 3.

The table is arithmetic you can redo, not a benchmark. It is also the whole argument: at 11 users a retention number of 27% and one of 45% are the same measurement. Any decision that treats them as different is a story you told yourself, and you will remember the story long after you have forgotten the sample size.

The fix is a change of unit. Below roughly 30 users, stop asking what percentage did X and start asking who did X, and what else you know about them. Every user is legible individually at this size. That is not a consolation prize. It is the one advantage you will never have again, and it disappears silently around the point the charts start working.

The five questions that do have answers

Five questions survive at small N, because each one is about named people rather than rates.

1. Where did each user come from?

Not which channel converts best, which you cannot rank with 15 users. The answerable version is per-person: which link, post, or conversation brought each one in. Tag every URL you share, one distinct link per place you post it. When six of eleven users trace back to a single comment you left on Reddit, you have learned where the next eleven probably are, and no percentage was required to learn it.

2. Who came back, and what did they do first?

Returning is the strongest signal a two-digit product emits. List the people who showed up on more than one day, then read their first session. What did the returners do that the one-and-done users did not? The pattern is often sharp at this size: every returner created a project, or finished setup, or reached one specific screen. That action is your activation moment, and getting people to it is the only job onboarding has.

3. Who hit an error?

At scale an error is a rate. At small N it is a person you lost. Four users hitting the same failure is not a 4% error rate, it is a third of your user base gone for a reason you could have fixed. They will not email you about it either. Capture errors automatically or you will not know: the SDKs do it without any wiring.

4. What changed after each release?

You are shipping several times a week, so the question is whether each change worked. The honest form is a comparison around the moment it went live: the same number of days on each side, the same events counted. Mark the release when you ship it. Without the marker you will be reconstructing dates from git history three weeks later, and you will get it wrong by a day in the direction that flatters the change.

5. Did anyone pay, and what did they do before paying?

One payment among twenty users is not revenue data. It is a case study, and it deserves to be read like one: what that person did in their first session, how many days passed before they paid, which screen they were on when they hit the paywall. Your second and third payments tell you whether any of it repeats.

A week read as people, not rates

Here is the same week described both ways. The left column is what a conventional dashboard reports at this size. The right column is the same data with the unit changed.

The right column is a to-do list. Post again where the six came from. Move project creation earlier in onboarding. Fix the paywall error, then message the four people who hit it, because at this size you can. The left column supports whatever you were already inclined to do, which is what makes it dangerous rather than merely useless.

What goes wrong in the first month

Four habits waste early signal, and all four feel productive while you are doing them.

• Ranking channels by percentage. "Reddit converts at 40%, Twitter at 12%" across twenty users is noise wearing a strategy costume. Count people. Wait until the counts are boring and repeated before you move effort.
• Leaving instrumentation for later. The most common early failure is having no data for the month that mattered, because tracking was a to-do item. Baseline events should arrive from the first build.
• Splitting traffic across projects. Web in one tool, the app in another, payments in a third dashboard. Now one person who found you on the web, installed the app, and paid appears as three unrelated users, and the question that matters most is the one question you cannot ask.
• Running A/B tests. At this size a test cannot reach significance before the product changes underneath it, and stopping early when the numbers look good inflates false positives badly. Evan Miller's write-up on peeking is the clearest explanation of why. Ship the version you believe in, mark the release, compare.

There is a fifth, quieter one: checking a dashboard instead of asking a question. A dashboard shows what it was built to show. The useful early questions are specific and change weekly, and they are usually answerable in a sentence if the data is somewhere you can query it.

Instrument before you need it

Every argument above assumes the data exists. The most expensive early-analytics mistake is not misreading numbers, it is not having them, and it is only visible in hindsight: the launch week you cannot reconstruct, the twenty users who churned before anything recorded why.

The baseline should be automatic. App opened, screen viewed, session started and ended, error caught. None of that is specific to your product, none of it should require a decision, and all of it is what the five questions above are built from. What genuinely needs hand-writing is small: the signup, the activation moment, and the payment.

The first bar is a real number from one of our own apps, and it is the reason this feature exists. Fifty-eight events in ninety days is not a quiet product, it is an uninstrumented one: every event had to be remembered, written, and shipped, so most of them never were. The third bar is the same app after the SDK captured the baseline on its own.

How Vortex reports small numbers

We built this into the product rather than leaving it as a process you maintain. Below about 30 users, insights stop reporting percentages and describe the people instead: who returned, where each arrived from, what the ones who stayed did differently. Users are pseudonymised in that view. The same story arrives by email on Monday, so it reaches you whether or not you remember to open a dashboard.

Because auth, behaviour, and payments share one user record, the question about your first payer is one question rather than a join across three tools. And because there is an MCP server over the same data, you can ask it where you already are:

Release markers and before-and-after comparison work the same way, which closes the loop: the agent that shipped the fix can mark it, wait the window, and check whether the numbers moved.

Frequently asked questions

The bottom line

Small numbers are not bad data. They are a different kind of data, and they answer a different set of questions than the ones dashboards are built to answer. Read them as people, capture the baseline before you need it, and compare like for like around each release. The rates will start working on their own once there are enough users to support them, and by then you will know which ones to look at.