Dashboard Design Template for Product Analytics

One per audience. A startup might have three: an executive dashboard (CEO/board), a product health dashboard (PM team), and an engineering performance dashboard (eng leads). Larger companies may have 5-8. The rule is: if two audiences need different metrics at different cadences, they need different dashboards. Use the [NPS calculator](/tools/nps-calculator) to track stakeholder satisfaction with your dashboards themselves.

Rarely. Real-time dashboards are expensive to build and maintain, and most decisions do not require up-to-the-second data. Daily refresh is sufficient for product dashboards. Real-time only makes sense for operational metrics (uptime, error rates, queue depth) where delays cost money.

A dashboard is a persistent, self-service view that the audience checks on their own schedule. A report is a point-in-time document with analysis and recommendations. Dashboards answer "what is happening now?" Reports answer "what happened, why, and what should we do?" Most teams need both.

If you check it more than once a week and it directly informs a recurring decision, put it on the dashboard. If you analyze it monthly for strategic context, put it in a report. Metrics that are only relevant during specific projects or experiments belong in neither. They go in project-specific analysis documents.

Pair vanity metrics with the actionable metric they obscure. Total signups (vanity) next to activated signups (actionable). Page views (vanity) next to engagement rate (actionable). Over time, the audience learns which number actually drives decisions. ---