How to design and structure metrics

In-Depth Discussions
1

Based on the blog post released during Coalesce, this discourse Topic will serve as the central hub for feedback on how to design and structure your metrics! It is our hope that this Topic will continue until we feel that we have enough information and consensus gathered to convert the blog into a Guide of its own.

5 Likes
2

My team is using dbt in sync with Metabase and Metrics are one big feature we are all waiting for

1 Like
3

One use case that I am interested in would be to define derived metrics like here where the component-metrics can be of a different time grain.

Example:
I would like to defined a metrics that calculates user stickiness as WAU/MAU.
I imagine something like this:

metrics:
  - name: active_users
    label: Active Users
    model: ref('fct_sign_ins')
    description: "The number of active users"
    calculation_method: count_distinct
    expression: dim_user_id

    timestamp: dim_date_day
    time_grains: [day, week, month, year]

    dimensions:
        - user_role
        - organization_type

  - name: stickiness
    label: stickiness
    description: "The stickiness as defined as WAU/ MAU"
    calculation_method: expression
    expression: "{{ metric('active_users(time_grain=week)')  / metric('active_users(time_grain=month)') }}"

    time_grains: [month]

    dimensions:
        - user_role
        - organization_type

I realise this brings about some difficulties involved with something like this (like there is not really the possibility for time_grains in the derived metric).

But do you reckon metric definitions like this would become possible in the future?

1 Like
4

Super helpful article team! We were waiting for this kind of best practices to validate our implementation and start spreading the metrics within our company.

One point that would suggest is to have something in between the single metrics file, and the one metric per file. Our team is going to have a yaml file for each mart, within the metrics folder. The rationale behind it is that this folder could end with a huge number of files, leading to some difficulties to find related/derived metrics. In the way we implement it, we actually need to associate a metric with a business unit, keeping the ownership easy to track, but maintaining the folder neat.

Our setup is something like:

- models
     - marts
        - metrics
            core.yml
            finance.yml
            marketing.yml
1 Like