Metric tables
Event tables hold what users do, one row per event. A metric table holds a number your data team already calculates, one row per period: revenue booked per day, MRR at the end of each day, open support tickets per week. Mitzu charts these numbers next to your event-based insights, straight from the table, without recalculating them.
When to use a metric table
- The number comes from a system that doesn't produce events, such as billing, finance, a CRM or a support tool.
- The number is already defined and reviewed in your warehouse, for example as a dbt model, and should match the figure in finance reports exactly.
- The number isn't a count of users or events: revenue, balances, quotas, costs.
When a number can be counted from events, such as signups, active users or conversion, keep it in an event table instead. Event data keeps funnels, retention, journeys and per-user break downs, which a metric table can't offer.
The shape of a metric table
A metric table is a table or view in your warehouse with one row per period and, optionally, per combination of dimensions, for example one row per day and plan:
| revenue_date | plan_type | company_id | mrr | revenue_booked |
|---|---|---|---|---|
| 2026-09-01 | pro | c_102 | 4200 | 310 |
| 2026-09-01 | starter | c_217 | 890 | 45 |
| 2026-09-02 | pro | c_102 | 4200 | 0 |
Each column plays one role:
| Role | In the example | What Mitzu does with it |
|---|---|---|
| Time | revenue_date | Places each row in a period. Without a time column, each metric is a single number, for example current ARR. |
| Metric value | mrr, revenue_booked | Becomes a warehouse metric you can chart. |
| Dimension | plan_type | Filters and break downs. |
| Identifier | company_id | Joins the company's dimension tables, so every metric can be broken down by company properties such as industry. |
Store rows at the finest period you want to chart. Mitzu rolls daily rows up into weeks, months and years, but never splits a row into shorter periods, and weekly rows can't be rolled up into months.
Roll-up rules
A metric table says what a number is for one period. It doesn't say what the number is for a longer one: a month of revenue is the sum of its days, but a month of MRR is its last day. Each metric therefore carries a roll-up rule, such as Add up for revenue, Use the latest value for MRR, or Don't roll up for unique counts and rates, which are only correct at the period one row covers. The rule is the one piece of the model Mitzu can't read from the table; an admin sets it when adding the table. The full list of rules is in Rolling up to longer periods.
How metric tables connect to the rest of the model
- Dimensions shared with events. A dimension column can be linked to an event property or to a property of an entity, such as a user's plan. With the link in place, one insight or dashboard filter applies to events and warehouse metrics alike.
- Entities. An identifier column joins the same dimension tables that event tables join, through the entity it identifies.
- No users or events. A metric table holds totals per period, not users. A warehouse metric can't be a step of a funnel, retention or journey, can't be counted as unique users, and cohorts don't apply to it.
Setting up and using metric tables
- Metric tables in workspace settings: adding a table, column roles, identifiers, roll-up rules and indexing.
- Warehouse metrics: charting them in insights, on dashboards and with the analytics agent.
- Warehouse metric catalog: display names, descriptions and visibility.