A lead network dashboard in three bands, with drill-through kept to a minimum

A lead generation networks reporting dashboard should help an owner decide, pause or investigate. It should not expose personal enquiries, hide broken joins or imply that attributed outcomes were caused by the network.

What to take away

Start with an empty specification

For each tile, store these non-numeric fields:

Blank placeholders prevent fictional sample values from becoming targets. The UK government AQuA Book supports documented, assured and fit-for-purpose analysis, while remaining government guidance rather than a private dashboard standard.

One fully worked tile, with real metric names:

Use three dashboard bands

The top band is data health. Show last successful refresh, missing state events, duplicate identifiers, rejected joins, late arrivals and reconciliation difference. Disable or qualify decision tiles when the approved tolerance is breached.

A typical reconciliation tolerance is 0.5 per cent of disclosed leads; a breach greys out the accepted-enquiries tile and shows the variance. The data owner sets the exact value.

For illustration, if disclosed leads are 1,000 and accepted enquiries are 400, the ratio is 0.40. If the duplicate and rejected-join counts add 10, the reconciliation difference is 10 divided by 1,000, or 1.0 per cent, above the 0.5 per cent tolerance, so the accepted-enquiries tile disables.

The middle band follows the operational funnel without merging states: submitted, quarantined, validated, matched, disclosed, accepted, rejected, credited, contacted and fulfilled. Each count links to its definition and query version. A commercial credit does not delete the original rejection or complaint.

The third band handles exceptions. Display complaint stages, suppression propagation, wrong-recipient holds, security cases, accessibility defects and exit reconciliation using aggregated or restricted views. Give each alert an owner and response.

Minimise access and drill-through

The ICO's Guide to the data protection principles, in its data minimisation guidance, says personal information should be adequate, relevant and limited to the purpose. Aggregate tiles do not need names, contact details or free-text requests. Authorised case investigation can use a separate audited view with a defined purpose and retention rule.

Suppression views should confirm which controlled routes received an instruction, not reveal a convenient marketing list. Requested-service reporting and later promotional reporting remain separate because their purposes and permissions can differ.

The NCSC's SaaS security guidance, the Using SaaS securely page in its Cloud security collection, covers account control, permissions, activity logs and incident response. It does not validate the dashboard configuration. Test roles, export, logs and recovery with synthetic fixtures that carry no production identity.

Test the released view

Create synthetic fixtures for every state and one controlled late-arriving event. Predict the tile and alert that each fixture should change, run the refresh, then reconcile expected and actual outputs. No production identity is needed for this functional test.

Use a second account to verify that an ordinary dashboard user cannot reach restricted detail through filters, exports, cached links or scheduled email. Check keyboard operation, focus order, labels, error messages and contrast on the configured dashboard rather than relying on a theme claim. Record browser, assistive method, date, tester, defects and retest outcome.

Release stays on hold when totals do not reconcile, refresh time is unknown, a query lacks version control, personal data appears outside the authorised view or an alert has no response owner.

Control interpretation and revisions

Label monitoring as descriptive. Put the attribution rule and window on attributed outcomes. Reserve causal wording for an evaluation with a credible comparison. Mark any planning scenario as conditional, with its input source and uncertainty.

When data arrives late, publish a revision record. When code is wrong, issue a correction with affected periods and approver. The ONS Guide to statistical revisions, published as its revisions and corrections policy, governs official statistics, but its transparent distinction is a useful internal pattern.

Review the dashboard after source, recipient, state, purpose, system or query changes. Stop distribution when reconciliation fails, privacy access is excessive, a security event affects integrity or a key definition has no owner. A visually polished view is not evidence that the underlying decision is safe.

Before you act

Common questions

What should the top dashboard band show?

The top band is data health. It shows last successful refresh, missing state events, duplicate identifiers, rejected joins, late arrivals and reconciliation difference. Decision tiles should be disabled or qualified when the approved tolerance is breached, so an owner can see whether the data is fit to act on.

Why should drill-through be kept to a minimum?

The ICO's Guide to the data protection principles, in its data minimisation section, says personal information should be adequate, relevant and limited to the purpose. Authorised case investigation can use a separate audited view with a defined purpose and retention rule, so ordinary users cannot reach restricted detail.

When should the dashboard be reviewed or distribution stopped?

Review the dashboard after source, recipient, state, purpose, system or query changes. Stop distribution when reconciliation fails, privacy access is excessive, a security event affects integrity or a key definition has no owner. A visually polished view is not evidence that the underlying decision is safe.