Reading Your Own Sales Data Before You Blame the Market
When a small business stalls, the first explanation most builders reach for is external: the market is crowded, the timing is wrong, or the audience just isn't there yet. Sometimes that is true. But blaming the market is often a way to avoid looking at the data you already have. This article offers a simple method for turning raw sales and engagement numbers into a diagnosis you can act on. It applies to any builder running an ecommerce store, a newsletter, a creator product, or a service offer, and it works best when you write your conclusions down before you check whether they were right.
Start With One Question, Not a Dashboard
Most builders open a dashboard, see a dozen charts, and feel vaguely overwhelmed. The fix is to begin with a single question that can be answered with a number. For example: Of the people who visited the product page last month, how many added the item to a cart? Or: Of the people who signed up for the free guide, how many opened the second email? A narrow question forces you to define the stage of the funnel you are examining, which is the first step toward finding where the leak is.
Write the question on paper before you pull any data. Then decide what number would make you think the question was answered in a meaningful way. If you cannot say what a good number would look like, you are not yet ready to interpret the one you have.
Split Your Customers Into Cohorts
An average hides more than it reveals. A conversion rate of four percent could mean every visitor is slightly interested, or it could mean a small group buys a lot while everyone else never returns. Cohorts solve this problem by grouping people by when or how they arrived. You might compare buyers who came from a podcast mention with those who found you through search, or customers acquired in January with those acquired in March.
Pick two or three cohort splits that match how you actually acquire people. Compare the same measure across them: repeat purchase rate, refund rate, time to second order, or how many people finished an onboarding sequence. Differences between cohorts are usually more informative than the overall trend, because they point to a specific source you can investigate further.
Turn Hunches Into Testable Hypotheses
Once you have a pattern, resist the urge to fix everything at once. Write a hypothesis in the form: If we change X, then Y will move, because Z. A hypothesis like 'If we shorten the checkout form, more people will finish purchasing, because the drop-off happens on the address step' is specific enough to test and specific enough to be wrong. Being wrong is useful: it tells you the cause was somewhere else.
Keep the test small. Change one variable, run it for a period long enough to see a meaningful difference given your traffic, and record the result before you decide what it means. Small businesses often have too little volume for statistical certainty, so treat results as directional evidence rather than proof. Note the sample size next to every conclusion so future you can judge how much weight it deserves.
A Practical Checklist for Your Next Review
Use this sequence each time you review performance. First, write the single question you are trying to answer. Second, name the stage of the funnel it concerns. Third, pull the number for your two or three most relevant cohorts and compare them. Fourth, write one hypothesis with a clear 'because' clause. Fifth, decide the smallest change that tests it. Sixth, set a date to check the result, and write down in advance what outcome would mean the hypothesis was wrong.
Ask yourself a few honest questions as you go. Did I choose the cohort before I looked at the data, or did I select the cohort that supported my story? Am I comparing equal time periods, or did a holiday or a launch distort one of them? Did a single large order or a single viral post drive the change? Would I draw the same conclusion if the numbers had moved in the opposite direction?
Keep a Decision Log
The most valuable business lesson often comes from comparing what you predicted with what happened. Keep a simple log with four columns: the date, the hypothesis, the result, and the decision you made. Over several months, this log reveals patterns in your own judgment, such as consistently overestimating how quickly a change will matter or underestimating how much a small wording change affects clicks.
A decision log also protects you from rewriting history. Without it, every failed experiment quietly becomes 'we always knew that wouldn't work,' and every success becomes proof of a grand strategy. Writing down what you expected, when, is the cheapest discipline a solo builder can adopt, and it makes every future review sharper.