Analytics

How to actually use your analytics data

A practical guide, mostly free of charts.

May 29, 2026 · 14 min read

There's a habit good operators have around analytics, and almost nobody tells you what it is. The advice you get instead is some version of "check your dashboard weekly," which is not actually advice — it's a chore description. It tells you when to look but not what you're looking for.

So most people open their analytics, see a wall of numbers, feel vaguely guilty for not knowing what to do with them, and close the tab.

This piece is about what good operators actually do — and what to do if you're not one yet. It's deliberately light on screenshots and charts. The hard part of analytics isn't seeing the data. It's knowing what to do once you've seen it.

I'm Doug. I built Moonship partly because I kept seeing founders — including me, several times — open their analytics, scan for ninety seconds, and walk away with nothing. The full argument for why dashboards have been failing you is over here. This piece assumes you're past the argument and just want to know what to actually do.


Stop looking at the dashboard. Start asking questions.

The first move that changes everything is almost embarrassing in its simplicity: when you open your analytics, have a specific question in mind.

This is the opposite of what most people do. Most people open analytics the same way they open Twitter — scrolling for stimulation, hoping something interesting catches their eye. Sometimes it does. Usually it doesn't. And either way you walk away with nothing actionable, because you were hoping the data would tell you what to care about, when actually it's your job to tell the data what to care about.

The questions don't have to be deep. They can be:

  • Did the post I published Monday get any traction?
  • Where did the Reddit traffic from last week go on the site?
  • Are signups up or down this week, and from where?
  • Why does the pricing page have a 78% bounce rate?

A specific question lets you ignore 90% of the dashboard. You're not "reading your analytics" anymore — you're investigating one thing. The dashboard becomes a tool again, instead of a stream.

If you can't think of a question, that's a signal too. Don't open analytics. Go do something else. Looking at numbers without a reason is a waste of attention, and the habit of doing it makes you worse at analytics, not better — because you're training yourself to scan instead of think.


The three questions you're actually asking

When good operators check in on their analytics, they're almost always asking one of three things, in roughly this order:

1. Did anything change?

Not "what are my numbers" — but "what's different from last week, or last month, or what I expected?" Change is the only signal that matters. Steady numbers don't require attention. Changed numbers do.

This is why dashboards are bad at this job: they show you absolute numbers and trust you to remember what the numbers were yesterday. You don't remember. Nobody does. The change is the insight; the absolute is the input.

2. Why did it change?

If something moved, you want to know what caused it — at least hypothetically. Was there a deploy? A LinkedIn post? An external mention? A bot wave that bot-filtering didn't catch? A holiday? A weekend?

This is the part that requires interpretation. You're not reading the data anymore; you're playing detective. The data is evidence. You're forming a hypothesis.

3. So what?

The most important question, and the one people skip most often. Suppose your traffic is up 30% from last week. That's a change. Suppose it's because a tweet went mildly viral. That's the cause. Now: so what? Do you do anything? Do you write more about that topic? Do you reach out to the people who shared it? Do you just enjoy the dopamine and move on?

A lot of analytics work stops at step 2 — you noticed something changed and figured out probably why. But unless you reach step 3, the work was just curiosity. It didn't affect a decision.

If you find yourself spending hours interpreting analytics and never reaching "so what" — your interpretation isn't broken, your workflow is. You're treating analytics like an end in itself instead of a tool for making decisions.

What "noticing" actually looks like

The most underrated skill in analytics is noticing. Not running queries. Not making dashboards. Just looking at something and going wait, that's weird.

Noticing is what good operators do automatically and what new analytics users have to build. It's pattern recognition combined with the willingness to follow a thread.

Here's what it looks like in practice. You open your traffic report and notice:

  • "There are 47 people on the pricing page right now. That's a lot." (Anomaly noticed.)
  • "They're mostly from Reddit. I don't usually get Reddit traffic." (Cause hypothesized.)
  • "Let me look at which thread." (Investigation started.)
  • "It's a thread asking about Plausible alternatives. I should jump in." (Decision reached.)

That whole sequence took thirty seconds, but it required noticing the spike in the first place. If you hadn't looked, you'd have missed it.

The bad news is that noticing requires being in your analytics often enough to know what's normal. You can't notice a spike if you don't know your baseline.

The good news is that modern analytics tools — including the ones I work on — are increasingly designed to notice for you. A signal feed surfaces "47 people on /pricing, mostly from Reddit, this is 3× normal." You don't have to be watching to catch it. The product catches it on your behalf.

But even with the product helping, the deciding still lives with you. The product can notice. You decide whether to act.


The hypothesis muscle

The single most useful habit you can build is forming hypotheses about your traffic before you check.

It sounds backward — wouldn't you want to look at the data, then form opinions? But forming a hypothesis first is actually what makes the data useful. Without a hypothesis, you're just absorbing numbers. With one, you're testing a prediction.

Try this: before you open analytics this week, write down — even in your head — what you expect to see. I expect traffic to be down because it's a holiday. I expect pricing-page views to be up because I posted on LinkedIn. I expect signups to be flat because I haven't changed anything.

Then open analytics and check.

If reality matches your hypothesis, you're calibrated. Your mental model of your business is accurate, and you can mostly trust your gut. If reality differs from your hypothesis, that's where the insight lives. "I expected signups to be flat but they're up 40% — what happened that I didn't notice?"

This is the difference between using analytics as a status check (boring, low-value, easy to skip) and using it as a learning tool (interesting, high-value, builds intuition over time). The same data, used differently, gives you radically different returns.


The "so what?" filter

If you take only one thing from this piece, take this: not every insight requires action.

This is the trap most people fall into when they start paying attention to analytics. They notice a thing, figure out why, and then feel like they need to do something about it. So they tweak. They write a blog post. They run an A/B test. They redesign the pricing page.

Most of that work doesn't pay off. Not because the work is bad, but because the insight didn't actually warrant action.

The "so what?" filter is the discipline of asking, every time you notice something: is this worth doing anything about? Sometimes the answer is yes — the action is obvious, the impact will be meaningful. Sometimes the answer is "interesting but no" — you noticed it, it doesn't change anything, you move on.

Letting things go is harder than it sounds. The dashboard makes you feel like every metric is a finger pointing at something you should fix. Most of them aren't. Most movement in analytics is noise, or natural variation, or a single anomaly that won't repeat. The mature operator can look at a 15% bounce rate change and shrug. The new operator panics and redesigns the page.

Bias toward not acting unless the case is strong. If a finding survives the "so what?" filter — if you can articulate the action and feel reasonably confident it'll matter — go do it. Otherwise, note it and move on.


Cadence: daily vs. weekly vs. event-driven

Most advice tells you to check analytics weekly. This advice is reasonable but not quite right.

The truth is that different analytics activities want different cadences:

  • Live / real-time — useful when you've just done something (shipped a feature, posted somewhere, sent an email) and want to see if anything's happening. Not useful as a daily check-in habit; it'll just train you to be anxious.
  • Daily — usually too frequent for most operators. The signal-to-noise ratio is poor; most daily changes are noise. The exception is when you're running an active campaign and need to see real-time effects.
  • Weekly — the sweet spot for most founders. Enough time has passed for trends to emerge. Not so much time that the data is stale by the time you act on it. Ideally Monday morning, looking at last week as a complete unit.
  • Event-driven — the most important cadence, and the one almost nobody talks about. When something happens — you ship, you post, someone mentions you, traffic feels different — that's when you check. Not on a schedule. In response to events.

If you can build the event-driven habit, the weekly habit takes care of itself. You'll already know what happened during the week because you noticed each event as it occurred.

The product version of this is signals delivered to wherever you already pay attention — Slack, email, whatever. The product notices for you, the notification interrupts you with a finding, you check or you don't. This is the version of "checking analytics" that doesn't require a habit, because the analytics finds you.


What metrics actually matter

A short, opinionated list, because the long list is wrong for almost everyone.

For most websites in most situations, the metrics that actually matter are:

  • Conversions — how many people did the thing you wanted them to do. Trial signups, demo requests, purchases, subscribes. Without this, every other number is decoration.
  • Conversion sources — which traffic sources convert, not just which send traffic. A source sending 10,000 visitors with 0 conversions is worth less than one sending 100 visitors with 5 conversions.
  • Top entry pages — where people land first. These pages are doing more work than any other; small improvements compound.
  • Page-level exit patterns — which pages lose people. Especially on pages that should keep them (pricing, signup, checkout).
  • Traffic source changes — not the levels, but the changes. If Reddit suddenly sends traffic, that's interesting. If Google has sent the same amount for six months, that's just gravity.

The metrics that don't matter as much as you think:

  • Bounce rate in isolation. Context-dependent and often misleading.
  • Time on page. Affected by how people read, browser behavior, ad-blocker scripts. Noisy.
  • Page views, in absolute terms. Vanity. The change in page views to a specific page matters; the total doesn't.
  • Average session duration. Almost no decision depends on this.

Spend your attention on the first list. Mostly ignore the second.


What good analytics tools should do for you

If you're using a dashboard tool and the workflow this piece describes feels exhausting — noticing patterns, forming hypotheses, filtering for action — that's because dashboards weren't built to help with this work. They were built to display data and trust you with the rest.

The better version of an analytics tool does the noticing for you. It surfaces what changed without being asked. It hypothesizes causes when it can. It tells you which findings are worth acting on and which are just variation. It interrupts you when it sees something genuinely interesting, and stays quiet otherwise.

This is the bet I'm making with Moonship, and the longer argument for why this matters is in the AI-native analytics guide. For the purposes of this piece, the practical takeaway is just this: you don't have to do all this work yourself. Modern tools can do most of the noticing. Your job is to do the deciding.


A simple weekly routine

If you want a starting template, here's the practical version of everything above, compressed into a five-minute Monday check-in:

  1. Before you open anything: write down what you expect. Traffic up or down? Why? What did you do or not do last week?
  2. Check last week's signals or anomalies first. Not the dashboard — the things that already got flagged as unusual. If you don't have a tool that does this, scan the traffic-by-day chart and look for spikes or drops.
  3. For each anomaly, hypothesize the cause. Even a guess. Write it down.
  4. Run the "so what?" filter. Of the things you noticed, what — if anything — should you do? Most weeks, the answer is "nothing." That's fine.
  5. Note what you got wrong. Anywhere your expectations were off, that's where your mental model of the business needs updating.

That's it. Five minutes if you have a tool that surfaces signals. Maybe ten if you're working from a raw dashboard. The point is that the routine is bounded — you're not browsing analytics; you're running a process — and it leaves you with a decision (or a clear "no action this week") at the end.


The honest summary

The reason most people don't use their analytics well isn't that they don't have the right tool. It's that nobody taught them the workflow.

The workflow, briefly:

  • Always have a question before you open analytics
  • Look for change, not for state
  • Form hypotheses, then test them against the data
  • Filter ruthlessly for "so what?"
  • Build event-driven habits, not calendar-driven ones
  • Most movement is noise; let most things go

The right tool makes this workflow easier. The wrong tool makes it harder by burying you in data and trusting you to do all the work. But even with the wrong tool, the workflow above is what you're trying to do — and naming it helps.

If you've read this far and the workflow resonates but feels like a lot to maintain manually, Moonship is built to do most of these steps for you. Surfaces changes, hypothesizes causes, filters for what's worth your attention. Same workflow, less manual labor. Invite-only early access, no credit card.

If it doesn't resonate — if you genuinely enjoy the dashboard-scanning workflow and find insight that way — keep doing what works. Tools are personal. The point of this piece isn't to push a product; it's to give a name to a workflow most people are doing accidentally or not at all.

Either way: don't open your analytics without a question. That's the move. Everything else is a refinement of it.


Moonship is privacy-friendly website analytics that surfaces findings, not dashboards. Invite-only early access, no credit card.

Analytics that does the noticing for you — so you can focus on the deciding.

Request an invite →