An email reporting run, from reconciled send to logged release

Treat each report as a run with an order of work: reconcile the send, store the lineage, complete the metric cards, check data health, then release with a log. Skipping a stage leaves a figure nobody can rerun. No England benchmark for email performance exists in the reviewed sources, so none is offered.

What to take away

Run reporting in fixed stages, and release only when each stage has a record.
Reconcile attempted sends, accepted messages and matched outcomes, and keep the unmatched count visible.
Complete one versioned metric card before calculating any rate.
Let a data-health panel suspend one broken source without taking the rest offline.
Log the query version, run log and every annotated break with each release.

Work through five stages in order

Each stage hands the next one something it can check. The order matters because a dashboard built before reconciliation only hides the gaps. Use the sequence below for every period, and write down what each stage produced.

Store raw extract identifiers, field definitions and the query version.
Reconcile the scheduler, provider-accepted and matched counts for each send run.
Complete a metric card for every figure you will publish.
Load the dashboard with a data-health panel and the card version beside each tile.
Release with the run log, the annotated breaks and the unmatched count.

Store raw extract identifiers, field definitions, transformations, joins, deduplication and late-event handling. Keep the query version and a run log with each release, so that a second analyst can rerun any published figure from the same inputs. If they cannot, the stage is not finished.

Reconcile every send run before the dashboard loads

Count every stage of a send run before any rate is calculated. Figures below are illustrative, for one job. The scheduler count, the provider acceptance count and the matched outcomes in the warehouse should each be published, with the gaps between them explained.

Stage	Count	Note
Attempted sends at the scheduler	40,000	Job 8841, 12 October 2026
Provider-accepted	39,600	400 rejected at acceptance
Matched outcomes in the warehouse	38,900	700 accepted messages unmatched
Unmatched retained	700	Published as a count, not dropped

Keep unmatched records in the published total and explain why they could not be matched. If the protocol changed mid-run, mark the series broken rather than splicing it. An attempted-message count covers send commands submitted in a job, and an accepted count covers the acceptance event the supplier defines. Neither proves that a person read the message.

Complete a metric card for each figure

A figure without a card is an unlabelled claim. Keep one card per metric and retain earlier versions. The example shows one completed card, with illustrative figures. Write the card before the number, so the definition cannot drift to fit the result.

One completed metric card

Event: Objection recorded in the CRM
Population: Contacts with an objection logged between 1 and 30 September 2026
Numerator: Objections confirmed in all four sending systems
Denominator: Objections logged in the CRM in the same period
Unit and period: Count and share; Europe/London, CRM extract 2026-10-02, query v3
Owner and uncertainty: Deliverability lead prepares, data protection lead approves; late CRM entries understate the share

Metric card required fields

Event and deduplication rule
Eligible population
Numerator
Denominator
Unit
Period and timezone
Source and extraction time
Query and version

A click rate label is incomplete. Unique-recipient clicks and total click events have different numerators. The card is where that difference is written down, and the list of measurement mistakes shows what goes wrong without it.

Show data health beside the figures

The dashboard is the final view of the pipeline, so it should show the pipeline's health. One value should be suspendable without taking the rest offline.

Panel item	What it shows	If it fails
Last load and missing sources	Whether each provider export arrived for the period	Suspend that tile and leave the rest live
Row-count reconciliation	Whether the stage counts agree within tolerance	If it stays above tolerance for two days, pause sending and escalate
Schema changes	Whether a provider field or definition changed	Annotate the break and mark the series broken

Show the metric-card version beside every tile, with filters for period, timezone, population and message type. Print counts next to proportions so the denominator stays visible. The reporting dashboard guidance covers what the main screen should show.

Label the evidence layer on each tile

Each tile should say which of four layers it belongs to: provider observation, internal operational outcome, rule-based attribution or causal estimate. A provider open is not a business outcome, and a figure from one layer cannot stand in for another.

Four evidence layers

Provider-reported

Source: Supplier system
Proves: Activity only
Example: Open observation
Label: Provider

Internal operational

Source: Own workflow
Proves: Control done
Example: Suppression confirmed
Label: Operational

Attributed

Source: Model
Proves: Association
Example: Attributed outcome
Label: Attributed

Causal

Source: Evaluation
Proves: Impact
Example: Controlled test
Label: Evaluated

Open observations depend on a tracking request attached to the message. The ICO finalised its storage and access technologies guidance on 29 April 2026, and it requires analysis of the specific technology and its purpose. The attribution methods compare allocation rules with test designs.

Release with a log and agreed thresholds

Release the report with its log: query version, run log, card versions and every annotated break. A later restatement then has something to compare against. Agree the warning, review and stop thresholds before the period closes, not after the result is known.

When a published figure changes, say what changed and why. The Government Analysis Function publishes guidance on communicating quality, uncertainty and change. State what is uncertain, the likely direction of bias and whether the decision could change. Do not add decimal places the data cannot support.

For financial claims, define contribution, cost period, currency, refunds and the counterfactual first. A dashboard screenshot will not substantiate a return on investment statement, and email software return on investment keeps attributed turnover away from verified contribution.

Before you act

Store the extract identifiers and query version for the period.
Publish the scheduler, accepted and matched counts for every send run.
Keep the unmatched count in the published total.
Complete a metric card for each published figure.
Add a data-health panel with suspendable values.
Release with the run log and every annotated break.

Common questions

What should be stored so a figure can be rerun?

Store raw extract identifiers, field definitions, transformations, joins, deduplication and late-event handling, plus the query version and a run log. With those, a second analyst can reproduce the figure from the same inputs.

What should happen when reconciliation fails?

If reconciliation stays above tolerance for two days, pause sending and escalate. If a provider export is missing at load time, suspend that tile and leave the rest live.

Should I use an England benchmark for open or click rates?

No comparable England benchmark was found in the reviewed sources. Keep any figure attached to its publisher and its definition, or treat it as an attributed observation.