48.3k Log in Get started
Dashboard

What does a product retention dashboard show in Metabase?

A product retention dashboard shows whether users who sign up actually stay: activation, cohort retention, stickiness, and growth accounting, computed from product events synced from tools like Amplitude, PostHog, and Mixpanel. In the warehouse, the same math joins to acquisition data — so growth teams can see which channels send users who stick, not just which send signups.

For: growth and product teams, product managers, and founders.Grain: one row per user per active day (daily event rollups), plus one row per user with signup, activation, and channel.

Which cards belong on a product retention dashboard?

  • Weekly retention cohorts — signup week × weeks since signup (heatmap-style table)
  • Activation rate by signup cohort (line)
  • DAU, WAU, and MAU (line)
  • Stickiness — DAU/MAU ratio (line)
  • Retention by acquisition channel (table)
  • Growth accounting — new, retained, resurrected, and churned users per week (stacked bar)
  • Time to activation — days from signup to first value (bar)
  • Feature adoption by cohort (table)

What data does the dashboard need?

  • A users table with user_id,signup_at, activated_at, andacquisition_channel.
  • Daily event rollups per user — user_daily_activity with user, date, and event counts — built from synced product events.
  • Optional mobile attribution from AppsFlyer, mapping installs to channels and campaigns.

How do you build it?

  1. Sync event-level data to the warehouse via each tool's native export (see the Amplitude, PostHog, and Mixpanel guides for routes).
  2. Resolve identities to one canonical user_id and roll events up to a user-day table — cohort SQL gets fast and simple at that grain.
  3. Define activation behaviorally and stamp activated_at andacquisition_channel onto the users table.
  4. Build the cohort table, activity trends, and growth accounting cards, with a channel filter across all of them.

Example card SQL

Weekly retention cohorts, first 12 weeksPostgreSQL
WITH cohorts AS (
  SELECT
    user_id,
    date_trunc('week', signup_at)::date AS cohort_week
  FROM users
),
cohort_sizes AS (
  SELECT cohort_week, COUNT(*) AS cohort_size
  FROM cohorts
  GROUP BY 1
)
SELECT
  c.cohort_week,
  (a.activity_date - c.cohort_week) / 7 AS week_number,
  ROUND(
    100.0 * COUNT(DISTINCT a.user_id) / MAX(s.cohort_size), 1
  ) AS retention_pct
FROM cohorts c
JOIN user_daily_activity a ON a.user_id = c.user_id
JOIN cohort_sizes s ON s.cohort_week = c.cohort_week
WHERE (a.activity_date - c.cohort_week) / 7 BETWEEN 0 AND 12
GROUP BY 1, 2
ORDER BY 1, 2;

Metrics

Activation rateChurn rateLTVCAC

Integrations

Amplitude + MetabasePostHog + MetabaseMixpanel + MetabaseAppsFlyer + Metabase

Dashboards

Marketing funnelEmail engagement

FAQ

How should activation be defined?
Behaviorally — the first moment a user gets real value, not the moment an account exists. Account creation is a form submit; activation is the action that predicts staying: a first dashboard created, a first message sent, a first file synced. Find it by comparing retention curves of users who did and didn't perform candidate actions in week one, then encode the winner as activated_at on the users table so activation rate means the same thing on every card. Funnel tools like Amplitude are good for discovering the moment; the warehouse is where the definition becomes governed.
Why does retention need cohorts instead of an average?
Because an averaged retention number blends day-one users with year-three veterans and moves for reasons that have nothing to do with the product. A growth spurt drags "average retention" down purely because the user base skews new — while the actual experience may be improving. Cohort tables hold signup week constant, so you can see whether the March cohort holds better at week 4 than January's did. The same logic applies to churn rate: read it by cohort before reading it in aggregate.
How do you connect acquisition channel to retention?
Store acquisition_channel on the users table at signup — from UTM attribution, or from AppsFlyer for mobile installs — and group the cohort math by it. This is the card that closes the loop with marketing: some channels deliver users who churn by week two, others deliver users who stay, and blended CAC hides the difference completely. Paired with the marketing funnel dashboard, it turns budget debates into a retention-per-channel question rather than a cost-per-signup one.
How do identity merges affect retention math?
Users start anonymous and become identified at signup; tools like PostHog and Mixpanel merge those identities, and the warehouse copy has to respect the same mapping. If pre-signup events land under a device ID that never links to the user_id, time-to-activation looks longer than it is; if one person's two devices count as two users, retention undercounts. Sync the tool's identity-mapping table alongside events and resolve to a canonical user_id in a model before any cohort math runs.
Should product analytics data come from warehouse exports or the API?
Warehouse-native exports, almost always. Amplitude, Mixpanel, and PostHog all ship managed exports (or, for PostHog, a queryable store) that deliver complete event-level data on a schedule. Scraping aggregate numbers out of reporting APIs gives you pre-cooked rollups you can't re-cohort, re-join to acquisition data, or audit. The export path costs a little setup and buys the thing this dashboard exists for: retention math you control, at user grain.