Skip to content

Metric requests

A metric request is how an ad-hoc query becomes part of the catalogue. The person who found the number proposes it; the person accountable for the number approves it.

From the Data Explorer:

  1. Get the query right in the playground.
  2. Give it a label — the name people will recognise.
  3. Optionally describe what it measures.
  4. Request metric.

Requests appear under My Requests, with their status.

An admin reviews the pending queue and either approves or rejects.

Approving creates a Registry metric from the query. The request then links to the metric it produced.

Rejecting leaves a note explaining why, which the requester can read. A rejection with no reason is a dead end for the person who filed it.

The query passed read-only enforcement, which says it was safe — not that it was right. Review is where someone confirms the grain, the filters, and the join. That is the difference between a query that ran and a metric someone can rely on, and it is why certification matters as much as the SQL.

  • Check the columns are described and marked with sensible roles. A query written against undocumented columns will be misread later.
  • Use a real label. q3_final_v2 tells the next person to go read the SQL; “Revenue by priority” tells them what it measures.
  • Check the grain. Monthly versus quarterly is the most common reason a certified metric has to be revised.