Metric keys, and where a value comes from

Roiva calculates value by comparing what things were like before an initiative with what they're like now. Everything on this page exists to make that comparison mean something — to make sure the before-value and the after-value are the same measurement of the same thing, taken the same way.

A metric key names one measurement

Every metric Roiva ships has a key, and every key reads domain.object.measure:

support.tickets.closed_count — tickets closed
crm.deals.won_count — deals won
insurance.claims.avg_cycle_days — average days to settle a claim

The unit is not in the key. It lives on the metric, with its type and, where it needs one, its range — so a key can gain a better unit without every formula that reads it having to be rewritten. % means a value runs 0 to 100, so 12.5 is twelve and a half percent; 0–1 means it runs zero to one. Where the unit's range is wrong for the measurement, the metric says so itself: net retention runs past 100, so its range is open at the top.

That grammar is a contract, not a convention. Every key a shipped formula or an initiative template reads has to exist in the registry, and a spec fails the build if one doesn't. The whole registry is published: the Metric registry lists every metric Roiva ships, what each one measures, and which kind of connection feeds it.

Your account can define its own metrics as well. Those live beside Roiva's in the library and work the same way.

A baseline and a reading are the same measurement at different times

A metric entry is one value of one metric for one period. There are two kinds, and the only difference is which side of the comparison they sit on:

A baseline is the before-value — what the metric was before the initiative started.
A reading is a value after it — this month's handle time, this quarter's won deals.

That is why the grammar matters. A baseline measured as "average hours to first response" and a reading measured as "median hours" are not comparable, and the difference between them is not a result. One key, one definition, both sides.

Where a baseline comes from

Most accounts do not have a before-value written down anywhere, which is the single most common reason an initiative has no number. Roiva fills one in four ways, and the order between them is deliberate.

From your own history. When your connected systems hold figures for the complete calendar months before the initiative started, Roiva averages the last three of them. The resulting baseline records the months and the figures it used, so the arithmetic can be checked rather than trusted.
From an estimate, when there is no history to read. Roiva will hold a stand-in so a formula can produce something, and marks it as an estimate.
From history, later. If those months sync in or get imported afterwards, a calculated baseline supersedes the estimate, and the periods already calculated against the old figure are worked out again — except any whose value has been approved, which are left alone.
From you. A baseline you enter or import is yours. Roiva never overwrites it, not with an estimate and not with a calculation from history.

The last rule is the important one. A measurement somebody committed to is evidence; a figure Roiva worked out is a convenience. Convenience does not get to overwrite evidence.

Where readings come from

A reading arrives one of five ways: from a connected system on its sync, from a query you write against your own data warehouse, from a value formula that produces a metric of its own, from a CSV import, or from a person recording it.

A reading a connection synced is read-only in Roiva. It is that system's number, and an editable copy of somebody else's record is a number with two answers. To change it, change it where it lives and let the next sync carry it across.

Some measurements have no system Roiva connects to that holds them, and Roiva says so rather than implying an integration exists: a key with no feeding platform is marked as recorded by hand, imported, or read from a warehouse query, and the Missing Inputs page lists what formulas are waiting on. Some of those rows say where to find the figure in the system that has it.

From your data warehouse

Claims cycle days, quotes per underwriter and submissions by line of business usually sit in a warehouse your analysts already maintain, not in a help desk or a CRM. A metric query reads a monthly figure from there on every sync, for any metric that would otherwise be recorded by hand. Its text is versioned, and each reading names the version and the rows it came from. See Metrics from your own data warehouse.

What a period means

A metric entry is for a period, not a moment, and the period is what a formula reads by. Where a formula sums a metric over a period, it sums whole periods: the total for a month is the month's total, not a slice of it. That keeps a figure calculated in March comparable with the same figure calculated in April, and it is why a reading recorded against no period at all is a number Roiva cannot use.

How Roiva calculates value — formulas, inputs, and what turns a measurement into dollars
Metrics, baselines, and readings — the Method tabs, and what to record next
What makes a figure auditable — why a past figure still reproduces after a formula changes