Four metric types to define in your metrics layer
Product Tips

Four metric types to define in your metrics layer

Annie Worman
Annie Worman

A metric is a quantitative indicator of the performance of a system such as a product or business. There are countless metrics that you can create depending on your company, department, team, or even individual use case.

In this article, we’ll review four metrics types that you can use to construct a variety of individual metrics in a metrics layer like Transform. Keep in mind that you might not use all of these metrics types, but they act as a good reference point as you start to build specific metrics for your business.

1. Ratio Metric

Ratio metrics create a ratio out of two measures—dividing one measure with another. To construct a ratio metric, you must define a numerator and a denominator. Ratio metrics are common metrics because they add  additional detail to a measure.

For example, the ratio metric “Queries per active user” is an example of a metric that could help a product manager measure product engagement. Instead of showing just the number of queries, they can classify these queries by user, giving them deeper insight into their product and their customers.

Another example of a ratio metric used by marketing teams is “Open Rate '' because it is a ratio of the total number of delivered emails divided by total number of opened emails. When you multiply this by 100 you get a percentage that you can use to track the effectiveness of an email marketing program.

2. Cumulative Metric

Cumulative metrics aggregate a measure over a given period of time. For example, “Messages sent” in a messaging app could be set up as a cumulative metric if you want to track the total number of messages for the last year.

Another example of a use case for a cumulative metric is when a VP of Sales wants to see how many customers they acquired last month. A cumulative metric would allow them to see “distinct_customers” by “last 30 days”.

You can specify windows for cumulative metrics to establish the period of time that you want to measure:

  • Days
  • Weeks
  • Quarters
  • Months
  • Hours

3. Calculated Metric

Calculated metrics allow measures to be modified with calculations. In Transform, these are called Expression Metrics because they're defined using a SQL expression. These metrics often include multiple measures.

For example, a finance team might want to report “Adjusted Revenue” for a specific country to their CFO. In this case, they could calculate this metric by subtracting revenue in the United States by cancellations in the United States:

revenue_usd - cancellations_usd

4. Measure Proxy Metric

Measure proxy metrics are metrics that refer directly to a defined measure. For example, you may just want a simple metric that shows revenue. If “Revenue” is a measure in your data source, then you would simply reference this measure as your metric. The metric would sum all of the values in the revenue column of a table in your data source. In Transform, you can also include a constraint string that applies a dimensional filter when computing the metric. Let’s say a marketing team wants to look at order cancellations based on how the user arrived at their website.

They could look at the metric “Cancellations'' and add a dimensional filter for “high-value” cancellations from a certain source. In this case, they could specify:

high value > 100

Don’t get this confused with a “proxy metric'' which uses a related variable that acts as a “proxy” when you are unable to create a key metric.

Avoiding disparate metric logic

You can use these four metrics types to build a variety of metrics in Transform or other data tools. It is important that regardless of the specific metric, your organization is aligned on the definition and the logic behind that metric. Otherwise, different departments, teams, or even teammates can wind up with different numbers (or descriptions) for critical metrics across different downstream tools.

Looking for a specific metric example? Check out this blog series on how to define a “revenue” metric in code.