SaaS product analytics tools

The most expensive mistake in this market is installing a product analytics platform to measure a marketing site. It happens constantly, it produces a heavy page, a consent banner and an event taxonomy nobody maintains, and the reports it unlocks answer questions a marketing site does not have.

The reverse mistake is rarer and just as costly: running only page-level web analytics inside a product, then being unable to answer why people stop using it.

A SaaS company needs both, on different halves of the same domain.

The actual difference between the two categories

Web analytics answers questions about pages: who arrived, where from, what they read, whether they stayed. It works out of the box because pages are self-describing, and it costs a kilobyte.

Product analytics answers questions about people over time: of those who did A, how many went on to do B, how long did it take, which cohort are they in, and which early behaviour predicts whether they are still here in week four. It requires a designed event taxonomy, it costs tens of kilobytes, it sets cookies by design because following identified users across sessions is the entire point, and it needs somebody whose job includes using it.

Neither substitutes for the other. Asking a web analytics tool about week-four retention is futile; asking a product analytics platform how your blog is doing is forty kilobytes of overkill.

The arrangement that works

Draw the line at the login.

On the public side, the marketing site, the blog, the pricing page and the docs, use a lightweight cookieless tool. No consent banner in front of your acquisition funnel, no payload competing with your largest contentful paint, and honest numbers for the pages your growth actually depends on.

Behind the login, use a product analytics platform. You already have an account relationship and usually consent, the identity you need is a real user ID rather than a guessed one, and the questions are genuinely the ones these tools are built for.

This is not a compromise between two options. It is what a well-run SaaS measurement stack looks like, and it is cheaper than either tool used for both jobs.

The event taxonomy is the whole project

Product analytics succeeds or fails on the event design, not the tool. Agree the events before you implement them, keep them in version control next to the code, use object then past-tense verb naming, and put variable parts in properties rather than in event names.

The common failure is a taxonomy that grows without pruning until four events mean roughly the same thing and nobody trusts the reports. The second most common is autocapture used as a substitute for thinking, which produces an enormous undifferentiated stream and moves the governance problem from instrumentation time to analysis time without reducing it.

Heap's retroactive definition is the genuine innovation here, letting you define an event today and apply it to months of history, which removes the cost of having failed to predict a question. It is the strongest argument for autocapture that exists.

Choosing between the platforms

The free tiers are generous enough that you can evaluate two properly before paying for either, which is unusual in enterprise software and worth exploiting.

PostHog if you would otherwise buy four tools, because analytics, replay, flags, experiments, error tracking and surveys behind one signup is a materially faster loop than four procurement requests. Mixpanel if the priority is that everybody can read a funnel without training, and unlimited seats matter more than breadth. Amplitude if somebody's job is analysis and they will genuinely use behavioural cohorts and path analysis. Statsig if the central question is causal rather than descriptive, particularly with its warehouse-native mode where events never leave your infrastructure.

The rest of the field

Common questions

Related guides