Metrics

Every company has the same argument: what’s our actual revenue number? One report says one thing, a spreadsheet says another, and nobody’s sure which to trust. A metric is Ronja’s answer — the single, agreed way to calculate a number like Monthly Recurring Revenue, churn, or active users, with one definition the whole company shares, traceable all the way down to its source data.

You don’t write SQL to make one. You describe it, Ronja builds it, and an admin verifies it — after which it carries a visible trust badge so everyone knows they can rely on it.

What makes a metric different from a table

A metric looks a bit like a table — in fact it’s a special kind of one — but it behaves differently in three ways that matter:

It’s a definition, not a stored result. A table holds rows. A metric holds a recipe — “sum net_sek, divide by the count of orders, anchored on order_date.” Every time you look at it, Ronja recomputes the number from the source data. Nothing is frozen.
It has a trust badge. A metric is either Verified, Unvetted, drifted (“review pending”), or Retired. That badge is the whole point: it tells everyone whether the number is officially endorsed.
It slices correctly. Because a metric recomputes from source, you can break it down by any dimension or time period and the number stays right — even for a ratio. “Average order value, UK only, 2025” is computed from scratch over exactly those rows, not by re-dividing a pre-baked total (which would be wrong).

The two things a metric tracks

A metric has two independent states, and keeping them separate is the key to the whole feature:

Axis	Values	Question it answers
Lifecycle	Live · In progress · Archived	Is it finished being built?
Trust	Verified · Review pending · Unvetted · Retired	Can you rely on the number?

A metric can be fully built and live but still unvetted (nobody has verified it yet). A metric can be verified but drifted — meaning its definition changed since it was last checked, so the endorsement is paused until an admin re-confirms. The two never mean the same thing.

Creating a metric

There are two ways in, and both end with Ronja building it with you — there’s no form where you type raw SQL.

Open Metrics in the sidebar and click New metric (or Create a metric on the empty state).
Give it a name (“Net Revenue Retention”), describe how it should be calculated in plain language, and optionally list what you want to break it down by. Ronja can suggest the breakdowns for you.
Click Create & request verification. Ronja opens a chat in Build mode, finds the right source table, works out the recipe with you, and creates the metric.

The New metric modal — a name, a plain-language description of how it’s calculated, optional breakdown dimensions, and a “Create & request verification” button Describe the number in plain language; Ronja builds the definition and an admin verifies it.

You can also just ask Ronja in any chat — “make ‘Average Order Value’ an official metric” — and she’ll do the same thing. (She won’t mint a metric just to answer a one-off question; a metric is a deliberate, governed act.)

Every new metric starts unvetted. Verification is never automatic — that’s what makes the “Verified” badge mean something.

What Ronja builds it from

Under the hood, a metric is a small, strict recipe:

One clean source table. A metric reads from exactly one already-tidy table. If the data needs cleaning, joining, or de-duplicating first, that happens upstream in a prep table — so the metric itself stays simple and auditable.
A time anchor. Every metric is tied to a date column and a finest grain (day, week, month, quarter, or year), so it can always be shown as a trend.
Named measures and a formula. Ronja defines the building blocks (e.g. revenue = sum(net_sek), orders = count(*)) and combines them with simple arithmetic (revenue / orders) — no SQL functions, just the pieces and the math.

Because the formula is explicit, Ronja knows whether a metric is additive (safe to sum across rows, like total revenue) or not (a ratio or a distinct count, like average order value) — and handles slicing correctly either way.

Verifying and trusting a metric

This is where a metric earns its place as an official number.

A new metric is Unvetted — proposed, but not yet endorsed.
An admin reviews it and marks it Verified. From then on it shows a green Verified badge, and Ronja prefers it when answering KPI questions.
If the definition later changes — or an upstream table it depends on changes — the metric drifts: it shows “Verified · review pending” in amber. The number still displays, but the clean endorsement is paused until an admin looks at the change and either acknowledges it (re-verifies) or asks for a rework.
An admin can Retire a metric that’s no longer the right way to measure something. It stays queryable for history but is clearly flagged as no longer endorsed.

Anyone can Report an issue on a metric — a flag icon on its page. That notifies the owner and admins for review but, deliberately, does not change the metric’s status: one person’s doubt doesn’t un-verify a company number.

A metric’s detail page — the trend chart, the Verified trust badge, grain and breakdown controls, and the “How it’s really calculated” panel resolving down to source data A verified metric: its trend, its trust badge, the slice controls, and the full definition resolved down to source.

Using a metric

Open any metric to see its trend chart and slice it: change the grain (day, week, month, quarter, or year — only grains at or coarser than the metric’s finest grain are offered) or pick a breakdown dimension to split it into series. The “How it’s really calculated” panel shows the full definition resolved all the way down to the raw source tables — so there’s never a mystery about where a number comes from.

When you ask Ronja a KPI question in chat, she’ll answer using the relevant verified metric and show it as a trusted card — and she’ll tell you plainly if the only metric available is unvetted or drifted, rather than passing an unendorsed number off as official.