Email marketing software reporting dashboard: what to show

An email marketing software reporting dashboard should reveal definitions and data health before it presents trends. Build it as a decision surface over a versioned evidence pipeline, not as a gallery of provider tiles.

The method below was checked on 5 September 2026 for teams operating from England. It includes a sample layout and worked metric definitions, but no sample results or recommended thresholds; no product was used or evaluated. Teams can apply the definitions to an ESP such as Mailchimp, checking its event definitions rather than assuming they match.

What to take away

Put scope in the header

Show the reporting period, timezone, geography, message class, recipient population, provider, product edition, last successful refresh and metric-dictionary version. Keep filters visible in exports. A screenshot without its filter state cannot reproduce a result.

The dashboard owner should also state the decision supported. Operational triage, campaign learning, financial appraisal and causal evaluation are different jobs.

Separate the evidence layers

Use distinct sections for provider-reported events, internal operational controls, rule-based attribution and causal estimates. Label each source plainly. A provider-accepted state is not recipient attention; a recorded action allocated by a last-touch rule is not incremental impact.

Each tile opens its metric card. The card records event, eligible population, numerator, denominator, unit, period, timezone, system, query version, inclusions, exclusions, owner and uncertainty. Show numerator and denominator next to every proportion. Use a visible row layout: metric, numerator, denominator, unit, period and timezone, source, owner and action.

Example metric-dictionary entries:

Treat these as explicit local definitions. Document how the provider counts sent messages and unique events, plus any exclusions and resends, before comparing systems.

Before publishing, ask a second analyst to reconstruct one tile from the raw source and saved query. If the value, denominator or exclusions differ, keep the dashboard on hold and correct the lineage rather than averaging the answers.

Add a data-health strip

Report provider-event arrival and completeness for sent, delivered, open, click, bounce and complaint data, alongside schema changes, missing fields, failed joins, unmatched identities, late events and reconciliation differences. If a source is absent, mark the affected value unavailable rather than treating missing records as zero. Keep source-data defects distinct from deliverability checks: track SPF, DKIM and DMARC authentication results, inbox placement, sender reputation, blocklist status, and complaint or bounce spikes. Give each check an owner and disposition, such as a data engineer reconciling a late complaint-event feed or a deliverability owner investigating an authentication warning.

Use a strip row with check, status, owner and next action. Example rows:

The government Data Quality Framework links quality to intended use and lifecycle management. It applies to government data, so use its method proportionately rather than presenting the dashboard as officially assured.

Record changes where readers see them

Annotate provider definition changes, tracking configuration, audience rules, campaigns, outages and query revisions on the relevant series. Preserve old versions. A trend that crosses a definition break should be split or labelled non-comparable.

The Analysis Function's guidance on communicating quality, uncertainty and change recommends making limitations understandable. For this dashboard, say what is uncertain, its likely direction and whether it could alter the decision.

Keep privacy visible

List pixels, redirects, recipient identifiers and linked-page technologies behind each metric.

PECR regulation 6 requires clear and comprehensive information and consent before storing or accessing information on a subscriber's device, unless a strictly necessary exemption applies. The ICO's storage and access guidance sets out how to assess each technology. Suppressing a tile does not undo collection, while enabling a feature does not establish permission.

Expose retention, access class and aggregation level. Use the least detailed data that answers the approved question. Keep privacy and PECR decisions separate from analytical quality.

Make the dashboard accessible

Do not encode status by colour alone. Use text labels, logical reading order, keyboard operation, descriptive table headings and downloadable alternatives. Test zoom and relevant assistive technologies, and name what was not covered.

The Great Britain disability guide for service providers explains anticipatory reasonable-adjustment considerations. It does not make any dashboard compliant by citation.

Attach action to every signal

Define who investigates a warning, who may pause a report or send, what evidence permits restart and when the metric expires. An attribution anomaly might prompt a data check; a suppression discrepancy may stop release. Do not give both the same cosmetic red status.

Before you act

Common questions

What should the dashboard header show?

It should show the reporting period, timezone, geography and message class. It should also show recipient population, provider, product edition, last successful refresh and metric-dictionary version. Filters should stay visible in exports, because a screenshot without its filter state cannot reproduce a result.