Most teams know how many people signed up. Far fewer know who adopted the product and who only looked around.
A good PostHog product adoption dashboard closes that gap. It tracks whether users reach value, use the right features, and return often enough to matter.
If your dashboard can’t answer those points, it won’t help product, growth, or ops decide what to fix next.
Start with the adoption question
A product adoption dashboard, in this context, is a small set of PostHog charts tied to a behavior that creates value. It measures whether an eligible user or account reached a meaningful action, repeated it, and kept doing it over time.
That differs from a general activity dashboard. Logins, pageviews, and total events can show interest. They do not prove adoption unless they connect to value.
Use this dashboard when you need to improve onboarding, judge a feature launch, or explain soft retention. The business question stays the same. Among the users or accounts that should use this product area, how many adopted it? How fast did they adopt it, and do they still use it?
The wording matters because adoption depends on an eligible audience. A billing export feature should not be measured against all users. A collaboration feature often works better at the workspace level, because one power user can hide weak team usage.
Keep the first version narrow. One activation path and three to five features is enough. When teams pack the whole product into one dashboard, the result is harder to read and easier to ignore.
If you can’t name the eligible population, you can’t calculate adoption.
That rule prevents most bad dashboards.
Set the prerequisites before opening the dashboard
Before you open PostHog, confirm the tracking layer is ready. A clean dashboard cannot rescue messy events.
First, define the core actions in plain language. “Invite teammate”, “create project”, and “publish report” are often adoption signals. “Clicked settings” usually is not. Write one sentence for each feature that states what counts as first use and what counts as repeat use.
Next, standardize event names and properties. Pick one naming pattern and keep it across web, mobile, and server events. Normalize common properties such as feature_key, plan, role, workspace_id, and environment, using the same spelling and casing everywhere.
Whenever possible, pair front-end interaction events with server-side outcome events. A clicked button shows intent. A completed export or saved report shows the work finished.
Then fix identity. New users should move from anonymous activity to identified profiles after signup. If account-level reporting matters, send a stable group identifier so you can roll events up to companies, teams, or workspaces.
Last, set data quality rules. Filter internal traffic. Exclude QA workspaces. Watch for duplicate events, missing timestamps, and backfilled events that can bend trend lines. If a feature rolled out behind a flag, capture exposure so adoption rates only include people who could use it.
Before building the dashboard, write the metric definitions down. Pendo’s guide to documenting adoption metrics makes the same point from another tool angle, and it is a good reminder that the metric sheet comes before the chart.
Configure the dashboard in PostHog
Start with one dashboard, not ten. Use global filters for production traffic, exclude employees, and set a default last-30-day view. Then save a second view for the last 12 weeks so you can spot trend changes instead of reading one week in isolation. For launches, compare the last four full weeks against the prior four.
Save cohorts for new users, activated users, paying accounts, and flag-exposed accounts before adding charts. Reusing the same cohorts across funnels, trends, and retention keeps the story consistent.
If you want a few layout ideas before arranging tiles, these adoption dashboard examples are useful. The exact chart type matters less than the order and the denominator behind it.
Add the core tiles in this order
- Start with an activation funnel. Use
signed_up, thencompleted_onboarding, then the first key value event. Limit the conversion window, often 7 days. Break it down by acquisition source, role, or plan. This shows whether onboarding gets people to first value or loses them halfway. - Add feature adoption trends for each core product area. Measure unique users, or unique groups for B2B accounts, who performed the feature event during the selected period. Filter to the eligible cohort, such as admins only, paying workspaces, or users exposed to the flag. Weekly intervals usually read better than daily ones.
- Add time to first value. Use a funnel view that shows time to convert from signup to the first key action. Watch the distribution, not only the rate. A long tail often means users can find the feature eventually, but too late to stick.
- Add a repeat usage tile. Build a behavior cohort for users who perform the core action at least 3 times in 7 days, or at the cadence that matches your product. Then trend that cohort size over time. This is where “tried it once” becomes “adopted it.” If your product has a weekly or daily habit, add feature stickiness or WAU/MAU next to this tile. Skip it for naturally monthly workflows.
- Add a retention chart for activated users. Cohort by signup week or activation week. Comparing retained activated users is more useful than comparing all signups, because it separates onboarding issues from weak ongoing value.
- Add an account-level adoption view if teams buy your product. Track the percentage of active workspaces or companies that used the feature, not only the number of individuals. A strong account metric might be “paying workspaces with 2 or more members who used collaboration this week.”
Arrange the dashboard so the top row answers the headline questions. Put activation rate, feature adoption rate, time to value, and repeat usage there. Use the middle row for trend charts. Put diagnostics such as role, plan, release cohort, or feature flag exposure at the bottom.
For a second opinion on metric choices, this adoption metrics breakdown is a useful cross-check, especially for time to value, habit thresholds, and stickiness.
Choose the right denominator and adoption level
The same feature can look healthy at one level and weak at another. Pick the level that matches how value is created.
| Level | Use it when | Good denominator | Example metric |
|---|---|---|---|
| User | One person can get value alone | New signups or active eligible users | % of new users who created a first report within 7 days |
| Feature | You are judging one product area | Users exposed to or eligible for the feature | % of admins who used export this month |
| Account | Value depends on team behavior | Active workspaces or paying companies | % of paying accounts with 2+ members using collaboration weekly |
For self-serve products, user-level adoption is usually enough during onboarding. For B2B tools, account-level adoption often predicts renewal better because one champion can mask low team usage. Feature-level adoption helps after releases, because it isolates whether the new behavior caught on.
That is why many teams keep one high-level dashboard and separate feature-level tiles beneath it. The top view answers “are people adopting the product?” The lower tiles answer “which part is strong or weak?”
Keep the denominator tight. If only admins can manage billing, do not divide by every user. If a feature flag reached 30 percent of accounts, do not treat the full customer base as eligible. Raw event counts also mislead here, because one heavy user can make a feature look popular when only a few people use it.
Common mistakes in a PostHog adoption dashboard
The first mistake is mixing activation with adoption. A first project created is a good activation event. Lasting product use needs repeat behavior and retention, or you will celebrate curiosity as success.
Another common problem is inconsistent event definitions. If web sends report_created and mobile sends created_report, your trend line is broken before anyone reads it. The same goes for properties like plan names, feature keys, and workspace IDs.
Denominator errors are even more costly. Teams often divide feature users by all users because it is easy. That inflates failure for niche features and hides success for targeted ones. Filter by eligibility first, then measure the rate.
Short-term spikes can fool you as well. Launch emails, sales demos, and QA sessions can create a brief jump. Also avoid all-time charts, because they hide recent drops. Use rolling 30-day or weekly windows for operating reviews, and 90-day views for trend context.
Keep a simple release log nearby so you can map metric shifts to launches, pricing changes, or onboarding edits.
A spike after launch shows interest. Adoption shows up when later cohorts repeat the behavior.
Last, do not ignore release state. If you shipped behind a feature flag, compare exposed and unexposed cohorts. If identity merging is messy, fix that before sharing the dashboard with the team.
Build the first version this week
A useful PostHog adoption dashboard starts before the first chart. Clear event definitions, a real denominator, and one shared view of “adopted” matter more than extra tiles.
Validate one product area this week. Then build a first dashboard with activation, feature adoption, time to value, repeat usage, and retention.
Use that version in one product review meeting. The gaps it exposes will tell you what to refine next.
