What Analytics Should You Actually Track?

Most analytics setups measure everything and change nothing. The test for a metric is whether a plausible reading of it would make you act differently.

What Analytics Should You Actually Track? — Troiana insight cover

In short

Track the small number of things that would change a decision: how people arrive, whether they reach the action that matters, where they stop, and what that is worth. Everything else is decoration. A metric earns its place only if you can name the decision it would change — pageviews and bounce rate rarely pass that test, while a named conversion event and its drop-off almost always do.

The test for any metric

Before adding a number to a dashboard, answer one question: if this went up or down by a third, what would I do differently?

If the honest answer is "nothing", it is decoration. Most dashboards are mostly decoration, which is why teams check them weekly, feel informed, and act on none of it.

What is usually worth tracking

How people arrive. Which channels bring visitors, and which bring the ones who do anything. Traffic without segmentation is a vanity number; the useful comparison is between sources.

Whether they reach the thing that matters. Every site has one or two actions that constitute success — a booking, a signup, a purchase, an enquiry. This is the number.

Where they stop. For any multi-step flow, the drop-off between steps points directly at what to fix. This is the most actionable data most sites already have and do not look at.

What it is worth. Conversions without value cannot be compared. A channel producing many low-value enquiries can look better than one producing a few good ones.

Site health that affects the above. Core Web Vitals on real visitors, and error rates. Not because the scores matter in themselves, but because they change the other numbers.

That is roughly five things. Most sites need no more.

What usually is not worth tracking

Pageviews. They go up when you publish and down when you do not. They rarely change a decision.

Bounce rate, as usually interpreted. A visitor who read the answer and left satisfied is a success, and looks identical to one who left in frustration.

Time on page. Ambiguous in the same way. Long could mean engaged, or confused.

Aggregate averages. "Average session duration" across all traffic mixes people doing entirely different things. Segment or ignore.

None are useless in principle. They are useless as headline numbers, because they do not distinguish good outcomes from bad.

Instrument events, not clicks

The most common instrumentation mistake is tracking interface mechanics — button_click, nav_open — which produces volume and no meaning. Six months later nobody knows what cta_2 referred to, and the button has been renamed.

Track outcomes in the language of the business: booking_completed, quote_requested, signup_started. Those survive redesigns, because they describe what happened rather than what was clicked.

A few habits that keep event data usable:

Name consistently. Pick object_action or action_object and never mix them. Mixed conventions make analysis archaeology.

Attach the properties you will segment by — plan, source, step — at the point the event fires. Adding them later cannot backfill history.

Write down what each event means somewhere findable. The person analysing it in a year will not be you.

Track the start as well as the finish. checkout_started and checkout_completed give a rate. Only the second gives a number you cannot interpret.

Privacy is now part of the design

Analytics that requires consent only measures the people who consented, and in some markets that is a minority — which quietly biases everything you conclude.

Cookieless, privacy-first analytics avoids the consent banner entirely for basic measurement, at the cost of some cross-session detail. For most sites that trade is worth it: complete data about everyone beats detailed data about the subset who accepted.

Whatever you choose, collect only what you will use. Every field you store is something to secure, justify in your privacy policy, and eventually delete.

Reading it without fooling yourself

Compare like with like. Week over week for a business with weekly rhythms; year over year for anything seasonal. Month-to-date against last month is the classic misleading comparison.

Watch for the denominator. A conversion rate rising while conversions fall means you lost traffic, not that you improved.

Expect no data to be perfect. Ad blockers, consent rejection and privacy features mean you are always seeing a sample. Use analytics for direction and relative change, not for reconciling to a revenue figure — that is what your billing system is for.

Give changes time. A week of data after a change is mostly noise, particularly on lower-traffic sites.

A reasonable starting setup

One privacy-respecting analytics tool. Two or three named conversion events with values. A funnel for your main flow. Real-user performance data. Search Console for how people arrive from search.

Then a monthly habit worth more than any tool: look at the numbers and write down one decision they support. If you cannot, either the metrics are wrong or nothing needs to change — and both are useful to know.

If your dashboard is full and your decisions are not getting easier, book a call.

Common questions

What metrics should a website actually track?

About five things: how people arrive segmented by channel, whether they reach the one or two actions that constitute success, where they drop out of multi-step flows, what those conversions are worth, and the site health that affects all of it. Most sites need nothing beyond that.

Is bounce rate a useful metric?

Rarely as a headline number, because it cannot distinguish a visitor who read the answer and left satisfied from one who left in frustration. The same ambiguity applies to time on page. They can be useful within a tightly defined segment, but not as a measure of overall site quality.

What events should I track in analytics?

Outcomes described in business language — booking_completed, quote_requested, signup_started — rather than interface mechanics like button_click. Outcome events survive redesigns because they describe what happened rather than what was clicked. Track the start as well as the finish so you get a rate rather than a bare number.

Do I need cookie-based analytics?

Often not. Analytics requiring consent only measures people who consented, which in some markets is a minority and quietly biases your conclusions. Privacy-first cookieless analytics avoids the consent banner for basic measurement, trading some cross-session detail for complete data about everyone.

Why don't my analytics numbers match my sales figures?

They never will exactly. Ad blockers, consent rejection and browser privacy features mean analytics always shows a sample. Use it for direction and relative change between periods or channels, and reconcile absolute revenue against your billing system instead.

Have something worth building right?