Metric definitions: the contract behind clean reporting

Two dashboards, one number, two answers

The pattern is familiar in every growing ecommerce business. The founder’s dashboard says Rs 3.41 crore for last month. The finance pack says Rs 3.08 crore. The marketplace panel says something else again. Half a day disappears into reconciliation, someone declares the difference is returns and GST, and the meeting moves on. Next month the same gap reappears with a different explanation.

The pipeline is rarely at fault. What is missing is a definition layer: a set of written, owned, versioned statements about what each metric counts, on what date, with which filters. Without it, every report is one analyst’s interpretation, and interpretations do not survive staff changes.

What a definition actually contains

A usable definition is five fields, not a paragraph of prose.

• Grain: the row the metric is computed over. Order, order line, shipment, customer, or SKU-day. Most disputes between marketing and operations start here, because one team counts orders and the other counts shipments.
• Date basis: order created, dispatched, delivered, returned, or settled. Stated with the timezone, which for Indian businesses should be IST everywhere, including in tools that default to UTC.
• Filters and exclusions: cancelled orders, test orders, employee orders, replacements, and B2B or bulk orders that distort per-customer measures.
• Treatment: whether the figure includes GST, shipping charged to the customer, discounts, and platform-funded promotions.
• Owner and version: one named person, a version number, and the date it last changed. Definitions change, and undocumented changes are worse than bad definitions.

The seven definitions that cause the most damage

Not all metrics deserve this care. These seven do, because they feed decisions with money attached.

Revenue. Decide gross or net of returns, whether GST is included, and whether shipping revenue counts. Publish both a gross and a net line rather than arguing about which is real.

Orders. A multi-shipment order is one order and three shipments. Fix which one your order count means, because conversion rate and AOV both sit on top of it.

Return rate. The dangerous one. Returns in a month divided by orders in the same month is not a return rate, it is a ratio of two unrelated cohorts. Attribute returns to the dispatch cohort. In a growing business, calendar-basis return rate understates the true rate by 2 to 5 points, which is exactly the error size that makes a bad SKU look acceptable.

Contribution margin. State which costs are in and at what layer. Product cost, inbound freight, packaging, outbound freight, payment fees, platform commission, returns cost. Two brands quoting a 34 percent contribution margin are frequently measuring different things.

Inventory on hand. Whether it includes goods in transit, stock at marketplace fulfilment centres, quarantined returns, and units already allocated to open orders.

Stockout. Zero sellable units at some point in a day, or zero at a fixed snapshot time. The two produce very different availability numbers and the snapshot version is usually flattering.

Active customer. The window matters. A 12-month window and a 6-month window can differ by a factor of two in repeat rate, and repeat rate drives retention budgets.

Where the definition lives

Definitions written in a slide or a wiki page decay within a quarter because nothing forces them to stay true. The working pattern is to keep the definition next to the code that computes it, in whatever transformation layer you use, so the definition and the calculation move together and change through the same review.

Under that, three rules hold the system up. Every reported metric resolves to exactly one computation, so a number appearing in three dashboards comes from one place. Every change to a definition gets a version bump and a note on affected reports, so historic charts do not silently restate. And no metric enters a management report without an owner who will answer for it in the review.

Reconciliation as a standing control

A definition layer only becomes trustworthy when it is tested against something external. Set up three monthly reconciliations with stated tolerances.

• Platform revenue against settlement reports and against your books, with a tolerance of about 0.5 percent to start, and every break above it logged with a cause code.
• System inventory against physical counts on a rolling sample, tracked as absolute unit variance rather than net variance, because a positive and a negative error do not cancel out on a shelf.
• Marketing spend in the ad platforms against invoices, because platform-reported spend and billed spend diverge on credits and currency conversion.

Cause codes matter more than the variance number. Four or five recurring causes will explain the vast majority of breaks: timing at month end, returns credited before receipt, cancelled orders counted, GST treatment, and platform fee adjustments. Once each has an owner, the tolerance can tighten.

Rolling it out without stopping the business

This does not need a project plan. Take the twelve metrics that appear in your weekly review and write their definitions on one page, in the five fields above. Circulate it and expect three of them to be contested. Those three are the ones causing your reporting disputes, so resolve them first, in a room with operations, finance and growth present.

Then move the agreed definitions into the transformation layer, retire every competing calculation, and set the monthly reconciliation with named owners. Two weeks of work removes a recurring argument, and it makes every downstream decision, from SKU pruning to courier selection, rest on numbers that mean the same thing to everyone reading them.