Define a metric before putting it on a dashboard

Start with the unit being counted

A number needs a definition before it needs a chart. Ask whether it counts people, records, attempts, events or transactions. One person may appear in several events. An attempted message is not necessarily delivered, and a delivered message is not proof that someone read or acted on it. Label the unit explicitly rather than using a vague engagement total.

Do not add unlike channel metrics into a single success measure. A phone connection, an email open and a recorded field interaction are different events. Displaying them in one workspace can be useful, but putting them on one axis does not make them equivalent.

Make the time window part of the definition

State the reporting period and how records enter it. A creation date, activity date and correction date can place the same record in different periods. If a source system uses a different time zone, establish the conversion before comparing exports. A chart title that says this week is incomplete unless the team agrees where the week begins and which timestamps it uses.

Separate period totals from cumulative totals. A sample dashboard can show both, but the labels should make the distinction clear. Do not infer that changing a period selector updates every card unless the interface and data actually support that behavior.

Reconcile the displayed total to the export

Pick one channel and one period. Check that the export includes the same scope as the visible report. Review column names, the treatment of missing values and whether filtered-out rows remain in the file. Preserve a read-only source copy so a later correction does not erase the evidence used for an earlier decision.

• Name: what is this metric called?
• Unit: which event or record is counted?
• Scope: which channel, team and period are included?
• Exclusions: duplicates, test data, cancellations or missing records?
• Source: where did the underlying records come from?
• Review: who checks a discrepancy before the report is used?

Keep examples visibly separate from records

Fictional totals are useful for testing navigation and comprehension. They should be labeled as examples and should never appear in a report presented as organizational performance. If a demonstration downloads a CSV, the file should retain that sample-data boundary too.

The BlueRoots reporting preview uses fictional channel counts and two illustrative periods. It can help you inspect filtering and sample export behavior, but it is not live analytics or evidence of delivery. Before adopting any reporting service, ask for a demonstrated reconciliation against an authorized source and agree how corrections will be handled.