Product Analytics: Event Taxonomy, Cohort Retention

Most product analytics implementations are a graveyard of half-tracked events, undocumented properties, and dashboards no one trusts.

Product Analytics: From Random Events to Decision-Grade Data

Product analytics is the practice of instrumenting user behavior in your product, storing it in an event stream, and querying it to understand what users do, where they succeed, and where they abandon. Done right it changes the meetings you have — from 'I think users want X' to 'the retention cohort that used X has 2.3x week-8 retention'. Done wrong it produces charts that everyone stops opening.

The event taxonomy is the foundation

Before instrumenting anything, agree on the naming convention. Standard pattern: object_action, past tense, snake_case (invoice_created, message_sent, plan_upgraded). Every event carries a required set of properties: user_id, tenant_id, timestamp (client + server), platform (web/ios/android), app_version, session_id. Domain properties are additive and typed — never rename a property; add a new one and deprecate. Publish the taxonomy as a doc; PR review any new event against it. A 200-event product with a consistent taxonomy is queryable; a 50-event product with drift is not.

The four questions analytics should answer

(1) Acquisition — where do new users come from, and how does source affect downstream behavior? (2) Activation — what fraction of new users reach the milestone that predicts retention, and how long does it take? (3) Retention — of users who signed up in week N, what fraction is still active in weeks N+1, N+4, N+12? (4) Revenue — which behaviors correlate with upgrade, expansion, and churn? Every dashboard should map to one of these. Anything else is decorative — kill it.

Funnels, done honestly

A funnel measures the fraction of users completing an ordered sequence of events (signup → first_action → activation_milestone). Common mistakes: (1) not defining the time window per step (users have 7 days to complete step 2, else they exit); (2) mixing new-user and existing-user cohorts; (3) using percentages instead of absolute numbers, hiding low-volume noise; (4) ignoring the users who complete steps out of order. Report both conversion rate and absolute count at each step; slice by source and cohort. A funnel with a huge drop at one step is your product's most valuable ticket.

Retention curves are the north star

Cohort retention (X-axis: weeks since signup; Y-axis: % still active) tells you more than any single metric. Shape matters: a curve that flattens is a product with product-market fit; a curve that keeps dropping is not. Compare cohorts over time — cohorts should be trending up. Segment by first action, source, plan tier. For usage-based products, replace 'active' with a value-defined threshold ('sent >= 5 messages in the week'). Weekly Active Users without a cohort view can hide steady churn masked by acquisition.

Tooling and warehouse strategy

Instrumentation SDK: PostHog (open-source, self-hostable), Mixpanel, Amplitude, or Segment + destination(s). Warehouse: pipe events into Snowflake/BigQuery/Postgres for arbitrary SQL. Visualization: purpose-built analytics tool for funnels/retention, plus BI (Metabase, Hex, Mode) for custom queries. The bet: keep the SDK and warehouse separate — SDKs die and get replaced; the warehouse is durable. Ship every event to both. Cost at scale is dominated by warehouse ingest — sample high-volume events (page_viewed) after 100M/month, keep sensitive events at 100%.

Frequently asked questions

How many events should we track?
Track every action that has decision consequences and could not be trivially recomputed. Typical rich product: 30-150 event types. Below 30 and you probably have blind spots; above 200 and you probably have redundancy. Regularly retire events with no consumer.
Client-side or server-side tracking?
Both, for different reasons. Client-side captures UI intent (button_clicked, page_viewed) — ad-blockable, subject to spoofing. Server-side captures ground truth (invoice_created, plan_upgraded) — reliable, harder to attribute to marketing. Send revenue and audit events server-side; send UX events client-side; deduplicate on a shared event_id when both paths fire.
How does this differ from BI dashboards?
Product analytics is optimized for event streams and cohort/funnel/retention semantics with self-serve UIs. BI is optimized for arbitrary SQL over modeled data. Use both: product analytics for the standard four questions, BI for anything custom or joining events with billing/CRM.

Related fundraising guides (40)

Investor directory · Fundraising library · Articles A–Z · Company funding database