Skip to main content

Defining Metrics

Our metric builder allows teams to easily input metric definitions and dynamically generate the yml used to store them in dbt. We also include some best practice metadata so that and other systems can better organize and deliver value using metrics. Below is the complete list of properties that are needed to make metrics.

Definition Types

  • Metric Builder - The easiest way to define a metric. Select a table and the fields used to configure a metric.
  • Custom SQL - A flexible solution with the ability to join tables, edit and paste in SQL from other sources.
  • Derived Metric - Use existing metrics to define metrics with parent-child relationships, like average order value.

Definition Configuration

TableThe table used to calculate this metricdim_customersyes (no for derived metrics)
Calculation TypeThe method of calculation that is applied to the expressioncount_distinctyes
Calculation FieldThe expression to aggregate/calculate overuser_idyes
Date FieldThe time-based component of the metricsignup_dateyes
DimensionsA list of dimensions to group or filter the metric by[plan, country]no
FiltersA list of filters to apply before calculating the metricstatus = 'active'no


Metric properties define how a metric is calculated in Push.

Goal DirectionDefines whether the business goal is to increase or decrease the metric.
Aggregation PropertiesConfigures whether this metric can be aggregated across the date dimension.
Metric FormatConfigures whether a metric will display as a number, percent or currency when displayed.


Dimensions are a valuable way to describe and understand metric changes.

  • Dimensions can be created when defining a metric.
  • Dimensions can be shared across metrics. For example, if you used an orders table to calculate multiple metrics like order volume and revenue, they would likely share dimensions like country.

To avoid introducing unnecessary noise, only dimensions that are relevant for analysis should be included.

Derived Metrics

Derived metrics use existing metric definitions to calculate a new metric with a parent-child relationship. For example, Profit is a derived metric that can be calculating using the parent metrics of Revenue and Cost (profit = revenue - costs). Using derived metrics makes maintaining metric definitions easier by defining the supporting metrics in one definition and then having the derived metrics inherit any metric changes.

With derived metrics, dimensions are inherited. The dimensions available for derived metrics are the ones shared by all related metrics


  • Support currently exists for daily time grains only