What is product analytics?

Product analytics is the measurement of what people do inside a product rather than how they arrived at it. It tracks feature usage, activation, habit formation and retention, usually for signed-in users, and its unit of analysis is the user over time rather than the session.

How it differs from web analytics

Web analytics is organised around the session: where it came from, what it did, whether it converted. Product analytics is organised around the user across many sessions: whether they came back, what they adopted, whether they stayed.

That difference in unit changes almost everything downstream. Product analytics needs durable identity, because a question like does someone who uses feature X in week one still use the product in week eight is unanswerable without knowing it is the same person.

It also uses different methods. Cohorts and retention curves are the core of product analytics; source and campaign reporting are the core of web analytics. Funnels are the one thing both use heavily, at different points in the journey.

The four questions product analytics answers

  • Activation

    Do new users reach the point where the product delivers value, and how long does it take? Define the activation event precisely, then measure the share of signups reaching it in the first week.

  • Adoption

    Which features are actually used, by whom, and how often? Usually reveals that a small subset carries the product and a long tail carries nothing.

  • Habit

    Does usage become regular? DAU/MAU, or the weekly equivalent, is the standard measure of whether a product became part of someone's routine.

  • Retention

    Do cohorts flatten, or slide toward zero? The single most predictive thing you can know about a product's future.

See it on real data. The live demo is a fully populated dashboard on demo traffic, with no signup and no card.

Open the live demo

Instrumenting it without drowning in events

The common failure is instrumenting everything. Three hundred events with inconsistent names is worse than twenty with a convention, because nobody trusts any of them.

A workable approach: name events object-action, in one tense, lowercase, with a written list. Report created, invite sent, subscription upgraded. Put properties on the event rather than encoding them in the name, so report-created-pdf and report-created-csv become one event with a format property.

Then instrument the activation event first, the retention-defining event second, and everything else only when someone has a specific question. Events you added speculatively are the ones nobody can define six months later.

Product analytics in mrkr

mrkr supports browser-tracked custom events with properties, configured conversions and revenue values, plus funnels across captured paths and events. It does not provide saved cohorts or signup-week retention curves.

The identity question is the honest constraint. Product analytics needs to recognise the same user across weeks, and mrkr's default cookieless mode deliberately rotates its identifier daily. mrkr’s optional per-site cookie mode can preserve browser identity across days, with the consent requirement that comes with it. It does not provide a cross-device identity model.

mrkr answers acquisition, funnel and conversion questions. A dedicated product analytics tool is a better fit for governed event taxonomies, persistent cross-device identity or retention curves.

What is the difference between product analytics and web analytics?

Web analytics measures sessions and where they came from; product analytics measures users over time inside the product. Web analytics answers which channel works, product analytics answers whether people activate, adopt features and stay.

Do I need a separate tool for product analytics?

Not necessarily. If your tool supports custom events, funnels, cohorts and retention, and you can attach your own user id, that covers most product analytics work for a small team. Dedicated tools add depth in path analysis, experimentation and warehouse-native modelling.

How many events should I track?

Start with fewer than twenty, named to a written convention, covering signup, activation, the core value action and the paid conversion. Add more only in response to a specific question. Large event catalogues added speculatively become unmaintainable and nobody trusts them.

Start with one line of HTML.Your first visitors show up within a minute.