Build a marketing dashboard around decisions
Choose dashboard metrics by the decisions they support, then define ownership, comparisons, data freshness, and a practical acceptance test.
Start with the meeting, not the chart library
A dashboard earns its place when it helps someone decide where to adjust spending, which funnel stage to inspect, or whether sales are on track. “Put all our marketing metrics in one place” usually produces a long screen without a reading order. The numbers may be available while the decision still depends on a separate explanation.
Choose one recurring meeting and list the decisions actually made there. Name the people who can act on each decision. Weekly budget allocation and quarterly strategy reviews need different levels of detail and different time horizons. If a metric supports neither a decision nor an important constraint, it probably does not belong on the opening screen.
Define the calculation before presenting the result
For each metric, document the numerator, denominator, unit, reporting period, and exclusions. “Sales conversion rate” could mean paid orders divided by inquiries or closed deals divided by qualified leads. Sharing a label does not make those calculations comparable. Keep an example definition beside the reporting logic rather than only in an analyst's messages.
Analytics scope matters as well. GA4 distinguishes user-, session-, and event-scoped dimensions, which answer different questions. Do not attach a first-user source to every later purchase without explaining the relationship you chose. A reader should understand what the displayed number describes and which conclusions it cannot support.
Connect each signal to a check and an owner
Design the screen as a sequence: question, signal, validation, action. A change in cost should not automatically trigger a budget cut. First check whether the data is complete, definitions stayed consistent, and the sample is meaningful. The illustrative table below describes a workflow rather than a set of industry targets.
Set review thresholds from your own economics and normal variation. If there is little history, label the threshold provisional and revisit it after collecting evidence. A red cell is not an explanation. Show the size of the change, the comparison base, and any reason to interpret it cautiously.
| Decision | Signal | Owner and next check |
|---|---|---|
| Where should the next budget go? | Cost per qualified inquiry | Marketing: compare mature cohorts and lead quality |
| Where are inquiries getting stuck? | Stage-to-stage movement | Sales: inspect reasons and response delays |
| Is this week ready to review? | Source completeness | Analytics: check refresh times and missing records |
Make period comparisons defensible
Put the underlying counts beside percentage changes. Moving from one sale to two is a large percentage increase but provides a different basis for confidence than a large-volume change. Account for working days, seasonality, spending changes, and the delay between inquiry and payment. A partial week is not automatically comparable with a completed week.
Separate activity recorded during a period from outcomes for a cohort. This week's sales may come from last month's inquiries. Dividing current sales by current inquiries can create a misleading conversion measure when the sales cycle is long. Use a sufficiently mature cohort or clearly describe the limitation. Smoothing the chart cannot repair a mismatched calculation.
Trace the important numbers back to records
Each panel needs a source, a refresh time, and an owner for failures. Follow a few controlled records through the pipeline to the aggregate. Check duplicates, missing values, currencies, time zones, and filters. Incomplete loading should be visible before someone interprets a channel comparison as a performance change.
The report-review tool can critique a report you provide and identify unclear reasoning, missing context, and questions for the next decision. It does not connect to source systems or verify that an export is correct. Include definitions and limitations in the supplied material, then validate the underlying data separately. A well-written interpretation can still be based on a bad calculation.
Accept the dashboard through a real user task
Ask the intended reader to work through one decision without the dashboard author guiding them. Can they locate the answer, identify the time period, explain a limitation, and name the next step? Record every point that needs a spoken explanation. Those moments reveal missing labels, definitions, or navigation even when the software runs correctly.
After several meetings, remove metrics that nobody uses and add the context that repeatedly blocks decisions. Keep a short log of actions taken from the report and return to their outcomes. This lets you evaluate whether the dashboard helps the team notice a problem, assign a useful check, and follow through instead of merely collecting attractive charts.
Put it into practice
Frequently asked questions
How many metrics belong on the first screen?
Use the smallest set that supports the meeting's actual decisions. Test the reading task with the intended user rather than treating a universal metric count as a design rule.
Does every metric need real-time updates?
No. Match refresh frequency to the decision and the readiness of the source. More frequent refreshes do not shorten the delay between an inquiry and a completed sale.