Metric definitions

One team may use sales to mean accepted orders. Another may mean shipped goods, and another may use issued invoices. All three can produce internally consistent numbers while describing different activity.

We help turn a reporting question into an explicit calculation. That means identifying the source fields, included records, relevant dates and treatment of exceptions. The business chooses what the measure is meant to represent. We implement that meaning in the analytical model and check it against examples.

This work can sit inside a new data project or focus on a report that already exists. A disagreement between two totals is often a useful starting point, provided each total can be traced to its records and rules.

Suppose a report is intended to show the value of orders accepted during a selected period. A draft definition might include accepted order lines, exclude cancelled lines and use the order acceptance date to choose the period. Currency and the treatment of discounts still need to be specified.

A partial cancellation exposes another question: should the measure show the value first accepted or the value still committed after the cancellation? The answer changes the calculation and possibly the amount attributed to an earlier period. A single field named order_total does not settle it.

The definition can record both the choice and a small example that demonstrates it. This is a hypothetical analytical measure, not a recommendation about financial recognition. A business's accounting and reporting requirements need their own appropriate decisions.

Start with a limited set of records where the two reports disagree. Compare which records are present before comparing their totals. Then examine the fields and transformations that contribute to the measure.

Differences may come from source coverage, joins, filters or timing. A report using a current status can exclude an order that another report included using the status recorded at the time. A conversion applied at line level can differ from one applied after aggregation, particularly when rounding is involved.

We document the explanation at the level needed to reproduce it. Once a small set behaves as intended, broader reconciliation can establish whether the agreed rule is applied consistently across the selected population. An unexplained balancing adjustment would hide the original question.

A measure should name the date that controls inclusion. Event date, posting date and received date can place the same activity in different periods. A timezone boundary can also affect a daily total when source systems record timestamps differently.

Units need the same attention. A quantity in packs should not be added to a quantity in individual items without an agreed conversion. Values accumulated since the start of a year should not be treated as individual monthly movements. Where currencies differ, the measure needs a stated conversion basis.

These details do not all belong in a dashboard title. They do need a maintained place near the model or report, with enough context for someone changing the calculation later.

A revised definition should be identifiable as a revision. We establish which reports will use it and whether earlier periods will be recalculated, preserved or shown alongside a comparable measure.

The code change and the written explanation should describe the same treatment. A definition that says cancelled orders are excluded is misleading if the query only filters records cancelled before the latest extraction. A worked example makes that gap easier to catch.

The assignment can include the definition, implementation and reconciliation checks around a measure. It does not require replacing the entire reporting environment to address one disputed calculation.