Topic 03 · Reporting & visualization

Marketing Dashboards

Dashboards that answer real questions instead of displaying every metric.

Computer monitor displaying green bar charts and data tables in an office with colleagues in the background
A dashboard earns its place when someone changes a decision after looking at it.

Most marketing teams do not suffer from a lack of dashboards. They suffer from too many, built for different meetings, using slightly different definitions, with no clear owner. The result is a familiar ritual: a number is questioned in a meeting, three people open three reports, and the discussion turns into a debate about data instead of a decision about marketing.

A good dashboard is a product with a user, a purpose and a maintenance plan. This guide walks through how to design one.

Start with the audience and the question

Write down who will use the dashboard and what they need to decide. An executive reviewing the quarter needs a handful of outcome metrics with context. A paid media specialist adjusting bids needs daily campaign detail. Trying to serve both on one page is the fastest way to serve neither.

For each audience, list three to five questions the dashboard must answer. For example, for a monthly marketing review:

  • Are we on track against the revenue and pipeline targets for the quarter?
  • Which channels are improving or declining in efficiency?
  • Is customer retention holding steady?
  • What changed this month that needs explanation?

Build from a KPI hierarchy

Dashboards become coherent when metrics are arranged as a tree: one or two outcome metrics at the top, the drivers that explain them underneath, and operational metrics at the bottom. Revenue breaks into new and returning customers; new customers break into traffic, conversion rate and average order value. This structure tells viewers where to look when the top number moves. We explain the method in detail in building a KPI tree.

Layout: the dashboard reading order

People read dashboards like pages: top left first, then across and down. Use that.

  1. Top row: KPI tiles for the outcome metrics, each with the current value, the comparison period and a small trend line.
  2. Second band: one or two trend charts showing the outcome metrics over time with targets.
  3. Third band: driver breakdowns, such as by channel, segment or region, in sortable tables or bar charts.
  4. Bottom: notes, definitions and data freshness.
Wireframe of a dashboard layout with KPI tiles on top, trend chart in the middle and breakdown tables below OUTCOME 1OUTCOME 2DRIVER ADRIVER BTREND VS TARGETBY CHANNELBY SEGMENT ILLUSTRATIVE WIREFRAME
Illustrative wireframe: outcomes first, trend with target second, breakdowns last.

Choosing the right chart

QuestionGood choiceAvoid
How is it changing over time?Line chartMany stacked areas
How do categories compare?Horizontal bar chart, sortedPie with more than three slices
What share does each part take?Stacked bar or simple donut (few parts)3D charts
What are the exact values?Table with conditional formattingChart with every label printed
Is it on target?KPI tile with comparison and sparklineGauge charts
Tip

Use color to carry meaning, not decoration. Pick one highlight color for "needs attention" and keep everything else neutral. If everything is colorful, nothing stands out.

Definitions and trust

Every metric on a dashboard should have a written definition: what is counted, from which source, with which filters, in which time zone. Keep definitions in a shared glossary and link to it from the dashboard. When two reports disagree, the glossary is where the disagreement gets resolved, once, instead of in every meeting.

Display data freshness prominently. "Data through yesterday, refreshed 6:00 a.m." prevents a surprising amount of confusion, especially when platforms report with different delays.

Governance and cadence

  • Assign one owner per dashboard who approves changes and answers questions.
  • Review usage every quarter and retire dashboards nobody opens.
  • Version major changes and note them on the dashboard so trends are not misread.
  • Pair the dashboard with a recurring meeting where it is actually used to decide something.

Tools matter less than design

Looker Studio, Power BI, Tableau and the reporting built into analytics platforms can all produce excellent dashboards. The constraints are usually data modeling and agreement on definitions, not chart features. If you are working in Looker Studio, our Looker Studio dashboard tips cover performance and layout specifics. And when you present results, the techniques in data storytelling for stakeholders will help numbers turn into decisions.

Dashboard launch checklist

Before you share a new dashboard widely, run through a short quality check. It takes less than an hour and prevents most of the problems that erode trust in the first weeks:

  1. Reconcile totals. Pick one closed period and compare every headline number with the source system. Document any expected differences, such as time zone or attribution settings.
  2. Test filters. Change each filter and date control and confirm every chart responds as intended. Charts that ignore a filter are a classic source of confusion.
  3. Check empty states. Select a segment or period with no data and make sure the dashboard shows a clear message rather than a misleading zero.
  4. Read it cold. Ask someone who did not build it to answer the dashboard's key questions without help. Note where they hesitate.
  5. Check load time on a typical laptop and, if relevant, on a phone.
  6. Add the owner and definitions link in a visible place.

Signs a dashboard needs rework

  • People export the data to a spreadsheet every time they use it.
  • The same question keeps coming up in meetings even though the dashboard should answer it.
  • Different teams quote different numbers for the same metric from the same dashboard.
  • Nobody can say when it was last updated or who maintains it.

Each of these signals points to a fixable cause: missing breakdowns, unclear structure, inconsistent definitions or absent ownership. Treat them as product feedback and iterate, just as you would with any other tool your team depends on.