A metrics view in PushMetrics showing measures, dimensions, and inline distribution sparklines

A metrics view is your team's definition of how a given thing should be counted. You write one model query, list the measures (sums, averages, counts), and list the dimensions you want to slice by. After that, anyone in the workspace can ask questions against it without rewriting the SQL, and the agent can do the same.

We built this because metric definitions drift. "Active users" tends to mean five different things across five different conversations. A metrics view fixes the definition in one place, and every chart, analysis, and chat answer reads from that same place.

Where to find them

Metrics views live in Content in the top nav, under the Metrics tab. Knowledge entries and analysis documents sit on the same page, so it's all in one spot.

The Content page in PushMetrics with the All, Knowledge, Analysis, and Metrics tabs across the top, and a sparkline preview of measures inside the selected metrics view

Click into a view and you'll see its measures, dimensions, and a sparkline next to each measure showing the distribution of values.

Creating a metrics view

You can build one yourself, or ask the agent to draft it and review what it came up with.

The Create New menu open on the Content page, showing options for New Knowledge Article, New Analysis Document, New Metrics View, Upload .md Files, and Upload Metrics .yaml
1
Click Create New → New Metrics View.
2
Pick the database, set a timeseries column if the data has one, and write the model. The model is just a SELECT that returns the rows you want to measure.
3
Add measures and dimensions. Detect Columns classifies the columns from your model automatically. Suggest with AI hands the model to the agent and asks it to draft a starter set of measures.
4
Save. The view appears in the Metrics tab and the agent picks it up on the next message.

The form view

The form is the easiest way to start. There are fields for the model SQL, parameters, measures, and dimensions, with a format column on each measure for things like number, currency, or percentage.

The Form editor for a metrics view, with sections for Model SQL, Parameters, and a Measures table listing name, expression, display name, description, and format

A few things to know about the fields:

  • Measures are SQL aggregate expressions like COUNT(*), SUM(discount), or AVG(profit). Each one needs a short name (used inside queries) and a display_name (the label shown in the UI).
  • Dimensions are columns from the model that you want to group or filter by. Things like city, country, category, or orderdate.
  • Parameters let the model query use Jinja templates, for example {{ start_date }}. The agent fills them in when it queries the view.
  • Format controls how a measure renders. Options include number, currency_usd, percentage, and a few more.

The YAML view

Toggle YAML in the top right and the same definition appears as a single text document. This is handy if you want to copy a view into a code review, paste it into a doc, or version it in git.

The YAML editor for a metrics view, showing the same definition with name, description, database, timeseries, model, and a list of measures with name, expression, display_name, format, and additive flag

The YAML format is also what Upload Metrics .yaml expects. Drop a file in and it gets imported as a new metrics view. No clicking through the form.

💡
Form and YAML are the same thing. You can edit in either view, save, and the other one stays in sync. Use the form when you're figuring out what's possible. Use the YAML when you want to move definitions between workspaces or check them into git.

Exploring a metrics view

Click Explore on any saved metrics view to open the explorer. Pick measures from the list on the left, optionally pick a dimension to group by, and hit Run.

The metrics view explorer with measures listed on the left, two measures selected as aggregates, and the result table on the right showing total_rows and total_discount

Add a dimension and you get the breakdown:

The metrics view explorer grouped by city, showing total_rows and total_discount per city for the top results

Behind the scenes, the explorer compiles your selections into a single SQL query against the model, runs it, and shows the result. If you want to see the actual SQL that ran, click the SQL tab next to the results.

How agents use them

When an agent has the Knowledge permission turned on, it can see every metrics view in the workspace. In a chat it can:

  • List the views to find one that fits the question.
  • Read a view to see what measures and dimensions are available.
  • Query a view by picking measures and dimensions, then use the result in its answer.
  • Reference a view when saving an analysis document, so the document and the definition stay tied together.
  • Suggest a new view when it notices the same calculation getting reinvented across conversations.

Because measures and dimensions have names, the agent doesn't need to write SQL from scratch. A question like "how many active users in March, by country" turns into a single call: pick the active_users measure, group by country, filter the time range. The numbers come back the same way every time.

📐
Why this is better than raw SQL. Without a metrics view, every analysis is one creative interpretation of "active user" away from being wrong. The view is the contract. The agent can compose questions against it, but it can't redefine the metric mid-conversation.

What to put in a view

Anything where the definition matters and gets used more than once.

Core business metrics
ARR, MRR, active users, conversion rate, churn. The numbers leadership cares about.
Domain entities
One view per "thing" you ask questions about: orders, users, sessions, tickets.
Repeated calculations
Anything you've written the same SQL for more than twice. Promote it to a measure and stop retyping it.
Definitions with gotchas
"Excludes test accounts", "fiscal year starts in April". Encode the rule once instead of explaining it every time.

Metrics view, knowledge, or memory?

These three storage spots all hold know-how, but they do different jobs.

Memory
Knowledge
Metrics view
What it stores
Rules and notes for one agent
Free-form prose for the team
Executable measures and dimensions
Who sees it
One agent
Every agent in the workspace
Every agent in the workspace
Best for
"This agent always does it this way"
"This is how our company works"
"This is exactly how we count it"

If the definition needs to actually run against the database, it belongs in a metrics view. If it's prose or guidance, put it in knowledge or memory.