
Measurement
Part of Social commerce measurement with a metric dictionary, mature orders and reconciled sources
A four-panel social commerce dashboard with filters that cannot change the story silently
Build a social commerce dashboard in England that shows scope, definitions, data quality, mature orders, attribution limits and protected access.
Put scope and data quality above performance. A reader should see the reporting cut-off, England or wider geography, timezone, metric-definition version and order maturity before viewing a rate or currency total.
What to take away
- Show scope and data quality before any rate or currency total.
- Each panel should end with decision owner, threshold source and next action.
- Keep status definitions stable and display unmapped states rather than dropping them.
- Restrict access and exports to aggregates unless handles or narratives are necessary.
- Flag stale panels rather than presenting values from different periods as simultaneous.
Panel 1: coverage
Show channels, checkout routes, products, cohort dates and eligible order states. State whether geography comes from delivery address, account setting or another field. Do not label a UK account total as England.
Panel 1 Coverage Checklist
- Channels, checkout routes, products, cohort dates
- Eligible order states defined
- Geography sourcedelivery address, account, other
- Expected feeds and last successful refresh
- Missing, late, duplicate, unmatched, conflicting records
List expected feeds and their last successful refresh. Display missing, late, duplicate, unmatched and conflicting records. The ONS quality definition identifies relevance, accuracy, timeliness, clarity, coherence and comparability. Although this is management reporting, the same questions help users judge whether a panel is fit for its decision.
Panel 2: operational control
Show public listing errors, rejected catalogue items, stock mismatches, failed checkout tests, order-state exceptions and oldest unresolved case. Link each issue to an owner and pause rule. A dashboard should support action, not merely count failures.
Keep status definitions stable. If the platform and shop use different labels, maintain a mapping and display unmapped states rather than dropping them.
Panel 3: customers and mature orders
Show placed, delivered, cancelled, returned, refunded and disputed orders by cohort. Pair every percentage with numerator and denominator. Explain whether a return means requested, received or completed.
GOV.UK's online returns guidance describes rights for covered distance purchases and exceptions. Legal and operations reviewers should set the maturity rule for the actual goods. Young cohorts stay provisional.
Panel 4: commercial result
Use finance-reconciled settled revenue and contribution. State currency, VAT basis, cost inclusions and the source ledger. Keep attributed and unattributed orders visible. Do not calculate ROI if programme cost, maturity or attribution is incomplete.
Place platform-attributed results under the named rule and window. A separate panel may show an incremental estimate only when an approved comparison design supports it. The 2026 Magenta Book explains the role of a counterfactual in experimental and quasi-experimental evaluation.
Restrict access and exports
Most viewers need aggregates, not handles, emails, order narratives or message text. Under the ICO's data-minimisation guidance, an organisation should identify the minimum personal information sufficient for its specified purpose. Use role-based access, export logs, retention and small-cell controls.
If the dashboard identifies workers or ranks their output, treat that as worker monitoring rather than ordinary channel reporting. Define necessity, fairness, challenge and qualified employment review before use.
Design filters that cannot change the story silently
Display active geography, product, channel, cohort and order-state filters in the exported view. Define whether an empty selection means all records or none. Restrict filters that expose tiny groups or identifiable workers. A total should reconcile to its component panels under the same filter state.
Retain the query time and source-refresh time separately. A dashboard opened today may contain a payment feed from yesterday and a platform feed from an earlier period. Flag stale panels rather than presenting their values as simultaneous.
Record decisions beside results
For each threshold, name its evidence source, owner and action. A breached catalogue control may pause products; a data-completeness failure may block an ROI update. Keep the decision, reason and reviewer in a log rather than changing colours without an audit trail.
Test the dashboard with a known cancellation, late refund, duplicate event and inaccessible source. The test passes only if the visible total, warning and drill-down behave as documented. Preserve the test account exclusion rule.
End each panel with the decision owner, threshold source and next action. Preserve definition and data breaks on the chart. A blank caused by inadequate evidence is more honest than a polished number built from incompatible states.
Before you act
- Display reporting cut-off, geography, timezone and metric version.
- List expected feeds and their last successful refresh.
- Pair every percentage with numerator and denominator.
- Use finance-reconciled settled revenue and state currency and VAT basis.
- Show active filters in the exported view.
- Test with a known cancellation, late refund and duplicate event.
Common questions
What should a reader see before viewing a rate or currency total?
The reporting cut-off, England or wider geography, timezone, metric-definition version and order maturity. These scope and data quality details should appear before any rate or currency total so users can judge whether a panel is fit for its decision.
How should a dashboard handle different status labels between platform and shop?
Keep status definitions stable. If the platform and shop use different labels, maintain a mapping and display unmapped states rather than dropping them. This prevents silent changes to the story and ensures all states are visible.
When can an incremental estimate be shown on a separate panel?
Only when an approved comparison design supports it. The 2026 Magenta Book explains the role of a counterfactual in experimental and quasi-experimental evaluation. Without such a design, incremental estimates should not be presented.



