# I think we're asking website analytics the wrong questions Analytics counts what happened on a website. The questions that matter are about what led to it. On the gap between measuring and understanding. Author: Hasan Misbah Published: 2026-10-02 Reading time: 7 min read Canonical: https://misbah.co/blog/asking-website-analytics-the-wrong-questions --- ## TL;DR Website analytics is good at counting: how many visitors, from where, on which pages, at what rate. The questions people actually have about their website are about sequence: what happened, in what order, and what led to the outcome. A count can be completely accurate and still leave those unanswered. The useful first step is noticing which kind of question you are asking. Most of my working life is spent in code that moves money: licensing, subscriptions, payments. In that work nobody accepts a number on its own. If a renewal total is off by one, the total is not the answer to anything. Somebody opens the rows and reads what happened, in order, until the number is explained. A webhook arrived, then a retry, then a write. The number is where the investigation starts. Then I look at how website analytics gets read, by me as much as anyone, and the habit runs the other way. Visits are up. The bounce rate moved. A few people filled in the form. Each number arrives looking like an answer, so it gets treated as one, and the conversation ends there. I do not think those numbers are wrong. I think they answer questions I was not really asking. ## Website analytics answers counting questions Almost every standard report in an analytics tool answers one of four questions: - **How many?** Visitors, sessions, pageviews, events. - **Where from?** Search, social, a campaign, a link on another site. - **Which page?** What was viewed, where people arrived and where they left. - **What rate?** How many converted, how many bounced. These are good questions, and the tools answer them well. They are also all one type of question. Each asks for a count, or for one count divided by another. The questions a person running a website actually has are a different type. Why did enquiries drop when traffic did not? What were people looking for when they reached the pricing page and left? What did the visitors who became customers do that the others did not? None of those is a counting question. Each asks what happened, in what order, and what led to what. My view is that a lot of the frustration with analytics comes from that mismatch: asking the second kind of question and receiving the first kind of answer. We ask how many because that is what the tool can tell us, and then we behave as if we had asked what happened. ## A metric is a definition before it is a fact Take bounce rate, since nearly everyone with a website has looked at one. In Google Analytics 4, a bounce is a session that was not engaged. Google [defines an engaged session](https://support.google.com/analytics/answer/12195621?hl=en) as one that lasts longer than 10 seconds, has a key event, or has two or more page views. Bounce rate is the percentage of sessions that met none of those. That is a precise rule, and it has to be. But look at what the rule is about: a duration and two counts. It knows nothing about what the visitor wanted. Picture two visits to the same page. One person arrives from a search, finds the opening hours in the first line, and leaves after eight seconds with exactly what they came for. Another arrives from an advert that promised something the page does not offer, and leaves after eight seconds, annoyed. The report records two bounces. The site did its job for one of those people and failed the other. > A metric is an observation. It is not automatically an explanation. The number is not lying. It is doing exactly what it was defined to do. The meaning was in what surrounded each visit, what the person expected and whether they got it, and that was never the thing being counted. ## One number can sit on top of very different stories The clearest case of this I have seen was not in analytics at all. On the affiliate plugin I maintain, a refund request arrived with no explanation attached. In a report, that is one refund. I have written about [what happened when we asked instead of just processing it](/blog/when-to-automate-refunds): the customer needed a disclosure line to appear automatically wherever an affiliate link was shown, the plugin did not do that, and they were right that it should. As a number, that refund told me nothing. The sentence behind it changed what we built. The same row in the same table would have described a customer who hit a bug, a customer who never found a feature that already existed, and a customer who simply changed their mind. A refund count is about as accurate as a metric gets. It still could not tell those cases apart, and the difference between them was the only part worth knowing. I think a conversion rate works the same way. It counts outcomes, and it is silent about which of several quite different stories produced each one. ## A visit is a sequence, and a report is a set of totals The other habit I bring over from debugging is that order matters more than inventory. I have argued before that [reading code line by line only makes you confident about a fragment](/blog/rubber-duck-debugging-in-php), and that the hard bugs are found by narrating the execution: where it starts, what fires next, in what order. On one renewal bug, the evidence had been sitting in the logs the whole time. Nobody had looked, because nobody had asked the question that made it worth looking for. A visitor moves through a website the way a request moves through a codebase: as a sequence. They arrive from somewhere, with an expectation. They read one thing, then another. Something makes them continue, or stop. A standard report takes that sequence apart. Pages go in one table, traffic sources in another, conversions in a third, each sorted by its own total. Every table is correct. The order, which is where the explanation lived, is what was given up to produce the totals. To be fair to the tools, most of them have path and funnel views, and those help. But they are the specialist corner rather than the first screen, and they show the common routes, not the reason a particular route ended where it did. This is also why I distrust the instinct to collect more. If the order was lost when the events were counted, counting more events does not bring it back. More data is not automatically more understanding. ## Where the count is the right answer None of this is an argument against measuring. If the question really is a counting question, the count is the answer. Did the campaign send any traffic? Is the site getting more visits than it did last year? Which page do most people land on? I would not want any of those answered with a story. There is also a limit on the other side. Not every outcome has an explanation waiting to be found. Some people leave because the phone rang. The trouble starts only when a counting answer is used for a different kind of question, and nobody notices the swap. ## What I am still working out So when I say we are asking website analytics the wrong questions, I mean something narrow. The numbers are fine. We have let the questions the tool can answer stand in for the questions we actually have. I am no longer convinced the gap is a shortage of data. I suspect it is a shortage of context: the before and after that would turn a count back into an account of what happened. What I do not have is a clean answer for how much of that context can be kept, or what keeping it costs, in complexity and in the privacy of the people being measured. That is the part I am still thinking about. ## The takeaway Analytics measures, and it does that well. Understanding is a separate job that no report does for you by default. Before you read a dashboard, say the question in plain words. If it starts with "how many", the number will answer it. If it starts with "why" or "what led to this", the number is where the work begins.