Product analytics answers the questions that product teams need to make confident decisions: which features are being used, by whom, how often, and with what outcomes. The data architecture behind product analytics is distinct from business intelligence — it is event-driven, user-centric, and requires a different set of modelling choices.
Product analytics answers the questions that product teams need to make confident decisions: which features are being used, by whom, how often, and with what outcomes. The data infrastructure behind product analytics is distinct from business intelligence in several important ways — it is event-driven rather than transaction-driven, user-centric rather than entity-centric, and requires different modelling choices at each layer of the stack.
What Makes Product Analytics Different
Business intelligence aggregates transactional records to produce summary metrics: revenue by region, orders by channel, inventory turns by SKU. The questions are aggregate; the grain is a business event (an order, a payment, an inventory movement).
Product analytics asks fundamentally different questions: what did a specific user do in the product before they churned? Which users discovered Feature X and what happened to their retention afterward? How long does it take a new user to reach the activation milestone, and what predicts whether they will? These questions require user-level event histories that can be replayed, segmented, and cohorted — a different data model than a transactional fact table.
The Event Stream Foundation
Product analytics starts with an event stream: a record of every meaningful action a user takes in the product. Events have a type (page viewed, feature clicked, report exported, settings changed), a timestamp, a user identifier, and a set of properties specific to the event type.
The event taxonomy — the defined set of event types and their properties — is the most important design decision in product analytics infrastructure. A taxonomy that is too narrow misses behaviours that turn out to be analytically significant. A taxonomy that is too broad creates an undifferentiated flood of events where the signal is hard to find. A taxonomy that is inconsistently implemented (the same user action tracked differently by different parts of the product) produces data that cannot be analysed reliably.
Designing an event taxonomy requires collaboration between product, engineering, and analytics teams before instrumentation begins. The core questions: what decisions will this data inform, what user actions are necessary to answer those questions, and what properties of each action need to be captured to make the event analytically useful.
The standard event tracking tools (Segment, Amplitude, Mixpanel, Rudderstack) provide SDKs for web and mobile instrumentation that send events to a central collection endpoint. From there, events can be forwarded to a data warehouse for long-term storage and complex analysis, and to product analytics platforms for real-time exploration.
The User-Centric Data Model
The analytical foundation for product analytics is a user activity table: one row per user per time period (day, week), with columns representing the events and metrics relevant to that user in that period. This denormalised structure supports cohort analysis (grouping users by acquisition period, feature adoption, plan type) and survival analysis (tracking whether users are still active over time).
The key entities in the product analytics data model:
**Users** — unique individuals using the product. User identity is complicated by anonymous pre-authentication behaviour, multiple devices, and account sharing. The user entity needs to reconcile these into a canonical user record, with all events attributed to the correct user.
**Sessions** — contiguous periods of user activity within a single authentication context. Session definitions vary by product (a session might be defined as activity within a rolling 30-minute window, or explicitly by login/logout), but sessions are analytically useful for grouping events that occurred within a single usage context.
**Feature adoption events** — the specific events that indicate a user has discovered and used a feature. Not every event qualifies; feature adoption events are those that indicate meaningful engagement with a capability. Distinguishing between a user who loaded a feature page once and a user who completed a meaningful feature workflow requires defining the activation event explicitly.
**Retention metrics** — the most important product metrics are not point-in-time but longitudinal. Day-7 retention, Day-30 retention, and weekly active user rates all require looking at user activity over time and assessing whether users who were active at one point returned. Computing these correctly requires a user-day table (one row per user per day indicating whether they were active) rather than simply counting sessions.
Activation and Retention Analysis
The two product metrics that most directly predict business outcomes are activation (whether a new user reaches a meaningful usage milestone) and retention (whether an activated user continues using the product over time). Both require careful definition before the analytics infrastructure can measure them accurately.
**Activation** is the milestone that predicts long-term retention — the point at which a user has experienced enough product value that they are likely to continue using it. Activation is not the same as signup, and not the same as first login. It is the specific user action or state that empirical analysis shows predicts retention. Identifying the activation milestone requires cohort analysis: compare retention rates for users who completed various early actions versus those who did not, and identify which action has the strongest predictive relationship with 30-day retention.
**Retention curves** plot the percentage of users from a cohort who are still active at each subsequent time period. A cohort of users who signed up in January shows what fraction are still active in February, March, April, and so on. Retention curves from different cohorts, segmented by acquisition channel, plan type, or activation milestone, reveal which user segments have the best long-term retention and which have systematic churn problems.
The Infrastructure Stack
For most product companies, the product analytics infrastructure stack is:
**Instrumentation layer** — SDK-based event tracking (Segment for multi-destination flexibility, or direct instrumentation to Amplitude/Mixpanel for teams that primarily need product analytics exploration tools).
**Warehouse layer** — events streamed to the data warehouse (Snowflake, BigQuery, or Databricks) for long-term storage, complex SQL analysis, and integration with other business data. The warehouse is where product, revenue, and operational data are joined.
**Transformation layer** — dbt models transforming raw event streams into user activity tables, cohort tables, and the feature adoption and retention metrics used in dashboards.
**Exploration layer** — Amplitude, Mixpanel, or similar for real-time product exploration. Tableau or Looker for standardised dashboards shared with executive stakeholders. The two layers serve different purposes; conflating them leads to either analytical rigidity (everything in dashboards) or governance problems (everything in exploration tools).
Our data architecture practice designs product analytics infrastructure for SaaS and consumer product companies — contact us to discuss your product analytics architecture.
A former Microsoft data architect audits your data foundation, identifies your top priorities, and sends you a written plan. Free. No pitch.
Book a Call →