Marketing

Web analytics: which numbers to watch and which to ignore

Traffic on its own doesn't answer a single business question. Which metrics are worth setting up from the start and which only distract.

Almost every website analytics tool shows the same thing on its first screen: how many people came. It's the most accessible number and the most useless on its own. Below: which metrics make sense to set up, which need to be read together, and why a "traffic went up" report doesn't mean the business grew.

Traffic isn't a result

Visits measure the volume of the incoming flow, not its usefulness. The same increase can mean completely different things: you started appearing for the right queries, you were mentioned in an industry channel, or junk traffic started arriving from platforms you never intended to pay for.

There's a simple way to check whether a number is meaningful. Ask: if this metric doubles tomorrow, will I learn something new about my business? For traffic the answer is usually no — you first need to see where those people came from and what they did.

The same goes for bounce rate and time on site. Both depend on the type of page. On a reference article, a short visit is normal: the person found the answer and left satisfied. On a service page, a short visit more often means the page doesn't answer the question. A site-wide average mixes these cases and means nothing.

Target actions and how to set them up

Analytics starts working the moment it describes what counts as a result for you. Until then, any system is just a visitor counter.

A typical set of target actions for a studio or services company website:

  • submitting a request form;
  • clicking a phone number or messenger link;
  • requesting a cost estimate;
  • downloading a document the person left their contact details for;
  • for an online store — add to cart, checkout started and a paid order as separate events.

Three technical things matter here, and they're most often done wrong.

First: a goal should be recorded on the fact, not the intent. A click on "Submit" isn't the same as a successfully received request. If the form fails validation or on the server side, the counter shows a success that never happened. The right time to send the event is after a confirmed server response.

Second: events need systematic names. When a year later the report contains zayavka, form2, Form submit (new) and lead_final, nobody remembers how they differ. A naming convention is worth fixing before there are more than a dozen events.

Third: separate the steps. A single "request" goal won't show where people drop off. Separate events for opening the form, starting to fill it in and successful submission give you a funnel that shows the exact point of drop-off.

Traffic sources: where they came from and how it ended

The second most important breakdown after target actions is the source. It turns an abstract flow into a set of channels, each with its own economics.

At a minimum you need to distinguish:

  1. Organic search — people who searched and found you themselves.
  2. Paid advertising — traffic with a direct cost.
  3. Social media — usually a colder audience with a longer decision cycle.
  4. Direct visits and referral links — people who already knew about you or came on a recommendation.

Tagging ad links with UTM parameters isn't a formality but the only way not to lose the source along the way. Without it, all paid traffic lumps together, and you can't say which campaign brought a request and which only brought impressions.

A report with no breakdown by source shows the result but never the cause.

"Lots of visits" and "lots of requests" are different tasks

There's no automatic link between these two states. A site with a large flow and weak conversion and a site with a modest flow and high conversion produce the same number of requests but require opposite actions.

It's convenient to work through the situation step by step:

  • Little traffic, few requests — the problem is at the entrance. Work on visibility and channels: search optimisation and site structure, advertising.
  • Lots of traffic, few requests — the problem is on the site. Look at landing pages, the form, speed, how clear the offer is.
  • Lots of traffic, lots of requests, but no sales — the problem is lead quality. You're attracting the wrong people, or requests don't reach the sales team.

The third case is especially insidious, because by the site's reports everything looks great. You can only see it where website data is joined with deal data — which is what end-to-end analytics does.

Vanity metrics

That's the name for metrics that are nice to show and impossible to use for decisions. They almost always grow, almost never fall and commit you to nothing.

They usually include:

  • total page views;
  • follower counts regardless of their activity;
  • ad impressions in isolation from clicks and requests;
  • rankings for individual queries nobody searches for;
  • "average" values across the whole site at once.

The problem isn't that these numbers are false. The problem is that they aren't linked to action. If you can't name what exactly you'll do tomorrow based on a metric, it belongs in a reference file, not the weekly report.

A separate word about averages. Average time, average depth, average order value across all categories at once — values that smooth out exactly the differences you're looking at the report for. A breakdown is almost always more useful: by page type, by source, by device.

What to do

The order in which it makes sense to sort out analytics:

  1. Write down what counts as a result for you — in business terms, not interface terms. A request, a call, a paid order.
  2. For each result, describe the technical event and agree on names.
  3. Check that the event fires on actual success, not on a click. Send a test request and make sure it shows up in the report.
  4. Tag all advertising and email links with UTM parameters. No exceptions, including one-off placements.
  5. Build one short report: requests by source for the period and visit-to-request conversion for each source. That's enough to make budget decisions.
  6. Add anything else only when a question comes up that the current report doesn't answer.

This set is duller than a pretty dashboard with a dozen charts, but it's what lets you say which channel works, where the user's path breaks and where it makes sense to add money. If you need help setting it up — tell us about your project.