Analytics

Product analytics, dashboards and the numbers behind a decision.

0 products

Nothing matches that yet

Try a broader category, or add the product you were looking for.

Add a product

What this shelf holds

Three different jobs share a word here. Web analytics tells you where visitors came from and what they opened. Product analytics follows what people do inside the application. Business intelligence joins numbers from several systems and draws the chart a board meeting needs.

Buying one when you needed another is the most common mistake in this category, and it usually surfaces six months in, when the question nobody can answer turns out to be the important one.

Dashboards that read from your database sit close to databases. Server and error telemetry belongs in monitoring.

The event model decides what you can ask

Product analytics stands or falls on how you name and structure events.

A tool that expects a small vocabulary of events with rich properties will behave differently from one that expects hundreds of distinct event names. Check which shape the product prefers, because that decision propagates into every funnel and cohort you build afterwards.

Identity handling is the other half. Ask how anonymous visitors get merged with signed-in users, what happens when two people share a device, and whether an account can be analysed as a group rather than as individuals. Business software lives or dies on that last one.

Where the numbers come from

Client-side tracking is quick to install and loses a meaningful slice of traffic to blockers and privacy settings. Server-side tracking survives that, costs engineering time, and misses anything that never reaches your server.

Warehouse-first products invert the whole arrangement: data lands in your own store, and the analytics tool reads it. That gives you ownership and one version of the truth, at the price of needing somewhere to put it.

Whatever the route, check the export. Raw event export in a documented format is the difference between a tool you can leave and a history you have to abandon.

Pricing, and the meter that surprises people

  • Events counted per month, where one careless tracking call multiplies your bill.
  • Monthly tracked users, kinder to chatty products and harsher to large audiences.
  • Seats, sometimes free for viewers and charged for anyone who builds a report.
  • Retention, quietly capped at three or six months on entry plans.
  • Data volume on warehouse products, charged by storage and query rather than by person.

Retention is worth extra attention. Annual comparison needs fourteen months of history, and a plan that keeps six will never answer the question no matter how much you like the charts. The wider pattern is described in what pricing pages hide.

Regulators care about identifiers and transfers, not vendor positioning.

Ask where data is stored and processed, whether an EU region is available, what the vendor considers personal data, and how a deletion request is handled end to end. Then ask how the product behaves when a visitor refuses consent: some degrade to aggregate counting, some stop entirely, some carry on in ways your lawyer would rather know about in advance.

Cookieless measurement reduces the paperwork but rarely removes it. Check the specific configuration you plan to run.

What to test before you commit

Instrument three events you genuinely argue about, not the demo set. Build the funnel that would settle the argument. Notice how long that took and how much of it needed engineering help.

Then break something on purpose. Send a malformed event, rename one, look at how the tool surfaces the mess and whether you can fix history afterwards or only going forward.

Finish by asking a question about last year. If the answer is that the data stopped six months ago, you have learned the most useful thing about the plan.

Deciding what to measure before choosing a tool

Analytics projects fail from the same cause as reporting projects: instrumenting everything and asking nothing.

Write down the five questions the business actually argues about. Where signups come from. Which step of onboarding loses people. Whether the feature built last quarter is used. What separates customers who stay from those who leave. What a marketing campaign produced beyond visits.

Those questions determine which events matter, and a small vocabulary of well-named events answers them better than four hundred automatically captured ones.

Then decide who reads the answers. A dashboard nobody opens is a maintenance burden, and a weekly figure that reaches the people making decisions is worth more than a wall of charts with no audience.

Questions people ask

What is the difference between product and web analytics?
Web analytics counts visits, sources and pages. Product analytics follows named events a person triggers inside the application, which is what answers questions about retention, funnels and feature use.
How is analytics software usually priced?
By tracked events, by monthly tracked users, or by seats with an event ceiling attached. Event pricing punishes chatty instrumentation, so know your monthly volume before comparing plans.
Do I still need consent banners with a privacy-first tool?
Often less of one, but the answer depends on cookies, identifiers and where data is stored, not on marketing claims. Get the specific setup checked rather than trusting a badge on the pricing page.
Can I move my history to another tool later?
Raw event export is the thing to insist on. Products that export only aggregated charts leave your history behind, and rebuilding two years of behaviour from scratch is not realistic.
How long should data be retained?
Longer than your longest question. Annual comparisons need at least fourteen months, and plenty of entry plans stop at three or six, which quietly makes year-on-year analysis impossible.

Written about this category

Categories