Report

Origin & evolution

Reporting predates dashboards🎛️DashboardData & AnalyticsAn analytics dashboardView reference → by decades, rooted in the periodic management report assembled by hand for a board or a department. The defining trait carried through: a report is a snapshot. Improvado frames the static report as the one that answers "What was our performance last quarter?", showing historical data fixed at the moment of generation.

The sharpest distinction the field drew is push versus pull. As FineReport puts it, reporting follows a push model: it is generated on a schedule and delivered to expected recipients. Analytics follows a pull model, where an analyst goes and fetches what they need to answer a fresh question. A report pushes a known answer; a dashboard waits to be pulled.

As self-serve BI spread, the open question became how much to curate. A curated report is authored, with a narrative and a point of view; a self-serve environment hands people the tools to build their own. Most mature teams run both, and the received guidance is to reach for a report when you need a historical snapshot for stakeholders🧑‍💼StakeholderTeam & OrganisationA person with influence over the productView reference → or compliance, and a dashboard when you need live monitoring.

How it works in practice

A subscription🔂SubscriptionSales & RevenueA recurring subscriptionView reference → business sends a weekly revenue report every Monday at 7am: new MRR, churned MRR, net movement, plus a short written read on the largest swings. It goes to twelve people across finance and leadership. The report is static by design; it freezes Sunday-night numbers so two people quoting "last week" cannot disagree.

Six months in, open rates show four of the twelve never open it. Rather than keep pushing, the team interviews them. Those four wanted to slice revenue by plan tier on demand, a pull need a static report cannot serve. They move to a self-serve dashboard; the remaining eight keep the curated Monday narrative they actually read. The report gets shorter and more-read, and the self-serve users stop asking the analyst for one-off cuts.

Report vs. its neighbours

• Dashboard is pull and live; a report is push and fixed. A dashboard answers "what is happening now" and rewards exploration. A report answers "what happened in this period" and rewards a clear, repeatable narrative. The same metric🔢MetricStrategyA unified metric that measures progress, health, or behaviour across the productView reference → can appear in both, framed differently.
• Metric is a single measure; a report is a composed artefact built from several. A report selects, orders, and annotates metrics for an audience, adding the context a bare metric lacks.
• Data product🎁Data ProductData & AnalyticsA curated, reusable data assetView reference → is reusable infrastructure that many artefacts consume; a report is a finished deliverable aimed at named recipients. A data product feeds reports; a report rarely feeds anything.

In the graph

In the Unified Product Graph, a report sits in the data and analytics region as a consumable analysis artefact. A dashboard_contains_reportDashboardcontainsReporthierarchy edge captures the case where a curated report is embedded inside a monitoring surface, and report_distributed_to_teamReportdistributed toTeamcross-domain records who receives it. Modelling distribution as an explicit edge is what makes the report-nobody-reads problem queryable: a report connected to a team but to no metric, or pushed to recipients who never engage, is visible as a structural fact rather than a hunch.