[Feature] dbt should know about metrics

[drewbanin]

Is there an existing feature request for this?

• I have searched the existing issues

Describe the Feature

dbt should know about metrics. A metric is a timeseries aggregation over a table that supports zero or more dimensions. Some examples of metrics include:

• active users
• churn rate
• mrr (monthly recurring revenue)

dbt should support metric definitions as a new node type. Like exposures, metrics participate in the dbt DAG and can be expressed in yaml files. By defining metrics in dbt projects, analytics engineers can encode crucial business logic in tested, version controlled code. Further, these metrics definitions can be exposed to downstream tooling to drive consistency and precision in metric reporting.

The ecosystem

There is some prior art for defining metrics in dbt projects. In particular, see

• The MetricQL implementation (using meta fields)
• The Lightdash implementation (using meta fields)

While these two implementations differ (measures vs. metrics), more on that below, there exists a need in the community for a first-class way to define these metrics in dbt code. It is really neat to see that some folks have already made these definitions possible with dbt, but it would better if metrics were treated as well-defined nodes with field validation and helpful utilities inside of dbt Core.

Specification

A metric is a timeseries aggregation over a table that supports zero or more dimensions. These metrics can be encoded in schema.yml files. In the example below, a new_customers metric is defined as a count of customer records created in a given time grain.

# models/marts/product/schema.yml

version: 2

models:
 - name: dim_customers
   ...

metrics:
  - name: new_customers
    label: New Customers
    model: dim_customers
    description: "The number of paid customers who are using the product"

    type: count
    sql: user_id # superflous here, but shown as an example

    timestamp: signup_date
    time_grains: [day, week, month]

    dimensions:
      - plan
      - country
    
    filters:
      - field: is_paying
        value: true

    meta: {}

Given this information, a downstream process (or a dbt macro!) can generate a sql SELECT statement that correctly calculates this metric with a specified time grain and set of dimensions. Here is a breakdown of supported fields:

Field	Description	Example	Required?
name	A unique identifier for the metric	new_customers	yes
model	The dbt model that powers this metric	dim_customers	yes
label	A short for name / label for the metric	New Customers	no
description	Long form, human-readable description for the metric	The number of customers who....	no
type	The type of calculation to perform when evaluating a metric	count_distinct	yes
sql	The expression to aggregate/calculate over	user_id	yes
timestamp	The time-based component of the metric	signup_date	yes
time_grains	One or more "grains" at which the metric can be evaluated	[day, week, month]	yes
dimensions	A list of dimensions to group or filter the metric by	[plan, country]	no
filters	A list of filters to apply before calculating the metric	See below	no
meta	Arbitrary key/value store	{team: Finance}	no

Model reference

A reference to a dbt model. This model may be any "materialized" model, or a reference to an ephemeral model. Direct table references are not allowed, and alternate node types (seeds, snapshots) are not supported.

Metric types

The following metric types should be supported:

• count
• count_distinct
• sum
• average
• min
• max

In the future, alternative metric types (ratios, deltas, etc) should be supported in this model.

Filters

Filters should be defined as a list of dictionaries that define predicates for the metric. Filters are ANDed together. If more complex filtering is required, users can (and should) push that logic down into the underlying model.

filters:
  - field: is_paying
    value: true

Functional requirements

• Metrics should participate in the dbt DAG as a distinct node type
• Metric nodes should be accessible in the dbt Core compilation context via:
  • the graph.metrics variable
  • one or more accessor functions like metrics.find_by_name('...') (exact mechanism TBD)
• Metric nodes should be emitted into the manifest.json artifact
• Metrics should work with partial parsing
• Metric nodes should be supported in node selection and should be selectable with the metric: selector
  • When listing nodes, existing graph operators (+, &, etc) should be supported
• (in a different issue) Metrics should be surfaced in the dbt Docs website

dbt Core should not, itself, evaluate or calculate metrics. Instead, dbt Core should expose the definition of metrics to downstream tools or packages for evaluation and analysis. In this way, it is critical that dbt Core provides hooks into metrics that can be leveraged in both macro code, or by processes that consume dbt Core manifest.json files.

Describe alternatives you've considered

Don't implement metrics as distinct node types and keep encoding them in meta properties:

• This information is untyped and semantically unrepresented in dbt, so it would be a net-improvement to instead create a first-class node type in dbt Core for these logical DAG nodes

Metrics vs. Measures

Metrics are strongly-typed objects. It is extremely common to see folks perform syntactically correct but semantically meaningless calculations over data. This looks like averaging an average, or adding two distinct counts together. You get a number back... but it's not a useful or meaningful result.

To that end, I think we should start with metrics instead of measures. The difference here (and maybe a strawperson of my own creation - tell me if you think so) is that measures are untyped aggregations, whereas metrics are rigorously defined summaries over well-defined datasets. The creation of metrics does not preclude us from teaching dbt about more generic types of aggregations in the future, but I'd prefer to start with a narrow set of functionality and expand over time. It is easy to remove constraints, but it is hard to add them 🙂

Include support for joins

• Joins make metric calculations really complicated. dbt should absolutely know about foreign key relationships (outside of the existing relationships test) in the future, but this would be a meaningful expansion of scope for our first cut of this feature
• While these joins would be semantically useful, they are not a blocker to defining metrics today. Join logic can be pushed down into model code (whether materialized or ephemeral). We should experiment with this single table paradigm, see how it feels, and then consider the best approaching for teaching dbt about semantic joins in the future.

Where metrics are defined

Should metrics be a property of a model? While that could be functional today, I think this would make it hard to extend metrics to work with joins (see above). Instead, declaring metrics as independent nodes that participate in the DAG is a more future-proof idea, and we'd probably do well to avoid the "patching" flow required to get schema tests (properties of models today) translated into their own independent nodes in the DAG.

Inheriting configuration from models

Should metrics be namespaced under a model? This would make it possible to define some "shared" properties for all of the metrics derived from a model (eg. valid dimensions, the time field, supported time grain). This would be good for ergonomics, but not a huge value-add IMO. I'd like to keep this simple for the initial implementation and then make decisions like this with some more information from the community around example use-cases.

Example:

metrics:
  - model: dim_customers
    # dimensions are shared for all metrics defined in terms of this model
    dimensions:
      - country
      - plan

    definitions:
      - name: new_customers
      - name: churned_customers

SQL calculations in dimensions

Should dimensions be allowed to provide arbitrary SQL expressions? I don't think so — that SQL is best encoded in model code, and it would be confusing and dissonant to break up dimension definitions across SQL and yaml files.

Example:

metrics:
  - name: dim_customers

    # This logic should be represented in the underlying model
    dimensions:
      - field: plan_type
        sql: case when plan in ('pro', 'extra pro') then 'paid' else 'free' end
        

Who will this benefit?

Analytics engineers
- As with models, AEs will be able to define metric logic under version control. By colocating model and metric code, new metrics or changes to existing metrics can be made in a tested, versioned, documented, code reviewed environment
- Further, dbt Core's built in lineage can surface information about how changes to an upstream model may impact a downstream metric

BI/Analytics tooling (and therein, data consumers)
- Organizations use metrics to understand performance and make decisions. To that end, the correctness and precision of these metrics is really paramount! By defining metrics rigorously under version control, and then exposing their definitions globally, dbt Core can help ensure consistency in reporting.

The data ecosystem
- There are so many tools, both existing and yet to be created, that can benefit from an open source mechanism for defining a semantic model on top of the data warehouse. I believe that this business logic is just too valuable and strategically important for end-users to be locked up in proprietary tooling. To that end, this feature, and future types of semantic logic like this, should be addressable in an open source way

Are you interested in contributing this feature?

I sure am :)

Anything else?

From around the internet:

• https://basecase.vc/blog/headless-bi
• https://benn.substack.com/p/the-data-os
• https://benn.substack.com/p/metrics-layer

[sisu-callum]

@drewbanin what is the default null behavior for dimensions? I'll confess I'm thinking about this from Sisu's perspective but would the behavior be the equivalent of a * for all model fields or would it just not have any dimensions?

For our platform, we'd probably want all (or a majority of the columns) so I'm wondering if users would have to manually list them all out. Honestly I can see the perspective of requiring definition for every column and some sort of * so I'm wondering what your thoughts on the subject are.

[willweld]

Hey @drewbanin! Incoming novel for ya ;)

Additional Metric Properties:

• format: the presentation format of the metric (e.g. $, %)
• precision: the number of decimal points to round to
• metric_source: the source platform for the metric
• is_source_of_truth: boolean indicating if this metric comes from the source of truth
• pop_increase: indicates whether a period over period increase is good or bad
• alert_threshold: if the metric value is above/below a certain number for a time frame and/or if the metric goes +/- X% PoP

---

re: dimensionality defined at the metric level
Metrics are often consumed at multiple levels of dimensionality (e.g. revenue all-up, revenue by state, revenue by customer status, etc.)

If we're including dimensions as part of the metric definition, then the metric property should be dimension_sets:
dimension_sets:

• [] (empty array --> no dimensions)
• [plan] --> metric by plan only
• [country] --> metric by country only
• [plan, country] --> metric by plan, country

But this raises the question -- should dimensions be defined at the metric level??
There's a difference between how a metric is defined vs. how a metric is consumed. Part of me feels like the metrics should be defined at 0 dimension granularity. When you start applying different sets of dimensionality to a metric, those are ways in which the metric is consumed, which, can and will be different for different users. Ultimately, what I'm getting at is, if we're building a metrics layer, we should also think about building two additional layers:

• (1) the insight/answer/widget layer and
• (2) the report layer

Insight/Answer/Widget Layer:
This layer would be a separate layer that invokes/consumes the metric layer. The metric layer could act as an API and insight/answer/widget layer would essentially pass different dimensions to apply to the metric layer. I suppose this also begs the question if the different date range granularities should be defined in the metric layer or elsewhere. Here's an ugly example:

revenue_by_plan:

• source_metric: revenue
• dimensions: [plan]
• time_periods: [7d, 30d, 90d]

revenue_by_state:

• source_metric: revenue
• dimensions: [state]
• time_periods: [7d, 30d, 90d]

revenue_by_plan_state:

• source_metric: revenue
• dimensions: [plan, state]
• time_periods: [7d, 30d, 90d]

Report Layer:

Consumes the insights/answers/widget layer to include the various metrics/insights. Essentially defines which insights/metrics are part of a report.

---

Drew: dbt Core should not, itself, evaluate or calculate metrics. Instead, dbt Core should expose the definition of metrics to downstream tools or packages for evaluation and analysis.

Por que no los dos? I think there's a lot of value that can be found here on the pre-caching front, particularly in producing reports that don't require/allow users to query with specific date ranges. For example, I created a macro that populates a table with metrics defined at their various date granularities, such that I have a table like:

• date
• metric_value (for this date)
• metric_value_7d (from this date)
• metric_value_30d (from this date)
• metric_value_60d (from this date)

Here's an actual example using a barebones metric layer I defined:

{% macro get_windowed_data() %}
    {% set 
        metric_dict = [
            {
                'column': 'transaction_amount',
                'alias': 'Revenue',
                'method': 'sum',
                'precision': 2,
                'format': '$'           
            },
            {
                'column': 'transaction_id',
                'alias': 'Transactions',
                'method': 'count distinct',
                'precision': 0,
                'format': '#'
            },
            {
                'column': 'customer_id',
                'alias': 'Customers',
                'method': 'count distinct',
                'precision': 0,
                'format': '#'
            }
        ]
    %}

    {% set date_field = 'transaction_date' %}
    {% set date_periods = [7, 30, 60] %}

    SELECT 
    {% for period in date_periods %}    
        {% for metric in metric_dict %}
            {%- if metric.method == 'count distinct' -%}
            , ROUND(COUNT(DISTINCT {{metric.column}}) OVER (ORDER BY {{date_field}} ROWS BETWEEN {{period - 1}} PRECEDING AND CURRENT ROW), {{metric.precision}}) AS {{metric.alias}}_{{period}}d
            {%- else -%}
            , ROUND({{metric.method}}({{metric.column}}), {{metric.precision}}) AS {{metric.alias}}
            {% endif %}
        {% endfor %}
    {% endfor %}
    FROM
        {{ref('mart_customer_transactions')}}
    GROUP BY
        1
    ORDER BY
        1 DESC
{% endmacro %}

---

Drew: Should dimensions be allowed to provide arbitrary SQL expressions? I don't think so — that SQL is best encoded in model code, and it would be confusing and dissonant to break up dimension definitions across SQL and yaml files.

Should they be allowed? I think so! Should this be the best practice? Absolutely not. Here's why I think it might be a good idea to allow this:

• I hope this statement resonates well with you but, to me, dbt should be about flexibility and enabling people to do things in ways that work for them and their teams, even if it's not considered the right/best practice way
• The metrics layer is a new layer in the analytics stack and, with the advent of ALL THE THINGS (to be concise) in this area of practice, the scope of the role of an analytics engineer is growing a little bit out of control. Additionally, you have analytics engineers that are different shades of purple depending on where they are on the red vs. blue spectrum. I think the metrics layer provides an opportunity for those who are less technically inclined to get more involved, particularly in enabling them to do faster data exploration and analysis by tweaking definitions at a metric level rather than the underlying data level.

[owlas]

This is awesome! And completely agree that it'll be a huge boon to the community and tooling to move toward a standard. It's something we've been really excited about at Lightdash.

I think the proposal looks like a great direction. The metric definitions look familiar to the community too: adding to your list of comparisons for the implementation:

• CubeJS: https://cube.dev/docs/schema/reference/measures
• Looker: https://docs.looker.com/reference/field-reference/measure-type-reference

Joins

Agreed these can get confusing. Fortunately, they're also becoming less important, we're seeing teams move to big wide tables (where all models are prejoined for a given analysis). So seems like a reasonable omission

Time-dimension requirement (aka metrics vs measures)

I was interested to see that a time-dimension is a requirement, this excludes a lot of useful aggregates, for example:

• Which user has purchased the most products? (metric: count purchases, dimension: user id)
• What was the clickthrough rate on our most recent campaign (metric: click % rate, dimension: campaign name)

Does this relate to your dimension of metrics vs measures:

measures are untyped aggregations, whereas metrics are rigorously defined summaries over well-defined datasets

I found this quote a bit confusing 🤔. Not sure if I understood correctly, is the difference that a metric always has a time dimension and evaluates to a float? (e.g revenue over time, user count over time), hence giving a more rigorous "type"? Whereas a measure is any aggregation giving any type (date, string, timestamp, number)?

Metrics on models

There is definitely some benefit earned because for analysis tables there tends to be a subset of columns that are destined to be dimensions and some destined to become metrics in the semantic layer. The ability to just go through all columns and tag them with dimension / metric-type can make it really easy to bootstap metrics from a dbt model. Just as @sisu-callum mentioned, there are productivity gains to be had.

While joins aren't supported, metrics only map to a single model so I think there's a strong argument to keep them on models. However, if dbt needs to retain flexility to define metrics across models it would make more sense to define them on exposures / a new resource.

SQL implementation

One noticeable omission here is the implementation of how these metrics definitions compile to SQL. I think it would be even more powerful if the metrics definitions were paired with an expected SQL output for each target warehouse. Is that in scope for the project?

It would be troublesome for example if I have my centralised metric definitions but downstream tools interpret those metrics differently. I imagine something like a reference implementation of the complied SQL statements coming out of metrics (e.g. a dbt macro / package).

Or perhaps the idea here (as with dbt models) is that it doesn't take an opinion on how a metric definition becomes SQL and people are free to essentially build their own metrics layers using a common set of metrics definitions.

Last one...

• Heck no to complex sql definitions for dimensions, this definitely duplicates the holy work of dbt models.

[owlas]

@willweld

I think these properties:

format: the presentation format of the metric (e.g. $, %)
precision: the number of decimal points to round to

Seem more related to visualisation and I think would be strong candidates for the meta tag. So if a tool like Lightdash wants to allow users to mark up formats, then we can leverage the meta tag. This has proven a great pattern so far.

Thanks @drewbanin for including it!

The meta is where the party is 🎉

[willweld]

@owlas

Yeah absolutely agree with you. And the other things like pop_increase: [good/bad] could (should) be stored in the meta as well. As long as these attributes do exist and I can parse them out in dbt, I'm a happy camper :)

[tayloramurphy]

I would echo @owlas's points about the Time-Demension requirement. It feels overly explicit for no clear benefit.

Include support for joins

or

SQL implementation from @owlas

Many moons ago at Meltano we implemented a SQL:1999 compliant algorithm for properly handling JOINs and generating SQL. We call these "Hyper Dimensional Aggregates". The original issue documenting it is in https://gitlab.com/meltano/meltano/-/issues/286 and the SQL:1999 compliance part is in https://gitlab.com/meltano/meltano/-/issues/344

This code is all MIT licensed and could most likely be ported (famous last words) over to dbt if that makes sense. Perhaps @drewbanin you're thinking of having a similar adapter model to SQL generation that dbt has for everything else (a la https://docs.getdbt.com/docs/available-adapters#dbt-labs-supported)

Maybe this discussion is too much for the specification issue, but I wanted to call it out and put that bug in people's brains 🙂

[aaronsteers]

UPDATE: I've logged a separate issue for adding attributes here: #4090

"Metrics on Columns" vs "Metrics on Attributes"

First of all, I completely agree with the value here and general direction, and I agree with much of the great points in the above thread. I do however think we are missing a in important abstraction layer between "tables/columns" and "metrics". A column can only have a data type but an attribute can have a much deeper attribute type. A column is present in a single table, but an attribute has projections throughout the project.

So, I'd propose something along the lines adding both attributes and metrics together, or with attributes arriving slightly before:

1. Adding support for Attribute metadata
   1. let models provide columns with an attribute_name property (or similar)
   2. let attribute definitions be declared along with attribute type at the top of the project (as sibling to metrics)
   3. let models (and folders of models) optionally auto-map column names to attribute names
2. Adding support for metrics to be defined on top of attributes:
   1. The attribute type drives which types of metrics can be built, can be statically checked for soundness. (Ex: sum and avg are invalid over a dimension_key attribute.)
   2. The metric may then be mapped to specific models (implicitly or explicitly) and can be statically checked for soundness. (Ex: average_customer_spend is invalid if we don't have both customer_count and total_spend.)
   3. Each metric can have multiple calculation methods, depending on which attributes are available. (Sometimes this will rely on a combination of "fact" attributes and "dimension" attributes.)
   4. Metrics can build on other metrics. (Ex: average_customer_spend could be defined on top of 2 attributes, such as customer_count and total_spend, or on top of 2 metrics with the same names.)

Other notes:

• Attributes can also have parent-child relationships, such as city->state->region and day->month->(quarter)->year
• Attributes of dimension_key type would naturally seed distinct counts.
• Attributes can have default rendering, sorting, and slicing capabilities in the UI.
• Attributes allow project developers to give an explicit equivalency between columns of the same or similar names, such as two tables that both have sales_region or customer_id.
• The word attribute is intentionally ambiguous as to whether it drives metrics or dimensions, by design. As alluded to above, customer_id is an attribute that drives both dimensions and metrics, and sales_revenue can similarly be the driver of the sales_revenue metrics as well as as bucketization dimension called sales_tier.

Related conversation here in the Lightdash repo, as we recently discussed swapping the terms dimensions for attributes there as well: lightdash/lightdash#457

Example with Column->Attribute->Metric mappings

Expanding the above with a specific strawman example:

attributes:
- name: customer_id
  label: Customer ID
  attribute_type: dimension_key
  column_names:
  - customer_id
  models:
  # as much or as little constraint to get ontologically the right column mappings
  - marts.*
  - !marts.the_weird_one
- name: customer_count
  label: Customer Count
  description: A pre-aggregated count of customers.
  attribute_type: entity_count
  column_names:
  - customer_id
  models:
  # everywhere we see this column in the `marts` folder, map it to this attribute
  - marts.*
- name: country
  label: Country Name
  attribute_type: dimension_key
  models:
  # everywhere we see this column in the `marts` folder, map it to this attribute
  - marts.*
  column_names:
  - country
  - country_name
- name: sales_revenue
  label: Sales Revenue
  attribute_type: amount
  column_names:
  - sales_revenue
  models:
  - marts.*
metrics:
- name: Number of Customers
  calculations:
  - expression: count(distinct {{ attribute('customer_id') }})
    default: true
    models:
    - dim_customers
  - expression: sum({{ attribute('customer_count') }})
    models:
    - fact_customers
    - fact_customers_by_region
- name: Number of Countries
  calculations:
  # `attribute('country')` resolves to either `country` or `country_name`, depending on the model
  - expression: count(distinct {{ attribute('country') }})
    default: true
    models:
    - dim_customers
    - dim_countries
- name: Sales Revenue
  calculations:
  - expression: sum({{ attribute('sales_revenue') }})
    models:
    # Anywhere the attribute is available
    - *
- name: Average Customer Revenue
  calculations:
  - expression: {{ metric('Sales Revenue') }} / {{ metric('Number of Customers') }}
    # Anywhere both metrics are available
    models:
    - *
- name: Predicted Year-End Revenue
  # This calc is built in the BI layer and is not able to be defined in dbt.
  # Instead of `expression`, we provide `depends_on` as a list of attributes.
  depends_on:
  - customer_favorite_color
  - customer_join_date
  - customer_ytd_sales
  models:
  - marts.predictions.fancy_ai_table
- name: Super Fancy AI Prediction
  # This calc is built in the BI layer and is not able to be defined in dbt.
  # Instead of `expression`, we provide `depends_on` as a list of attributes.
  depends_on:
  - customer_favorite_color
  - customer_join_date
  models:
  - marts.predictions.fancy_ai_table

[miike]

Seem more related to visualisation and I think would be strong candidates for the meta tag.

Agreed @owlas format / precision are a good fit for meta as they seem like presentation attributes rather than core to the metric. That said I'd love to see units as a first class citizen as this is something critical to the metric definition (kilometers / meters, seconds / milliseconds etc).

Not sure if I understood correctly, is the difference that a metric always has a time dimension and evaluates to a float?

Not sure I fully grasped this either. I think there are certainly instances (and some you've mentioned) where a metric (or measure?) may not necessarily evaluate to a float, but may still be quite useful (e.g., the mode of a categorical variable).

[georgewfraser]

I would love for dbt to support metrics, mostly so that we could include metric definitions in Fivetran dbt packages. I take issue with your definition of metrics though: metrics can exist without time series. For example, if we have a database of species, “countif(kingdom = ‘animalia’)” is a metric which counts the number of animal species. This isn’t just a technical issue: there are lots of business metrics which are time-series in principle but in practice we choose to calculate at just the present time, because it’s simpler.

[buremba]

Great to see that dbt will support metric definitions! The proposal looks great and we're specifically interested in exposing these metrics to the downstream tools including SQL clients, BI tools, and data science tools. There are a couple of limitations to the proposed features:

dimensions

Unfortunately, most of the BI tools don't support this feature so most of the BI tools might be missing this information. We can ideally throw a user-friendly exception in the implementation as a workaround for now. I see the use case and am happy to implement it in our spec in case dbt has this feature but I'm not sure if it's a common use case and I believe that the name might be confusing for some users. I would suggest using something like allowed_dimensions or so.

time_grains and timestamp

Not all the metrics are time-series metrics and I believe that both of the properties should be optional. If time_grains is defined and timestamp is not, we can use all the available time frames, that's what we're doing at Metriql. I'm in favor of defining them under models rather than explicitly for metrics even though it's not flexible compared to the suggested approach. Most BI tools support time-series datasets but it's not at the metrics level and requiring the users to define them for each metric might be verbose in most cases. What about having a mapping property (example in Metriql) for dbt resources (models, sources, seeds) so that we can define them at dataset level and provide an option for the users to override it for individual metrics?

Features

filters

It looks good and we already support filters. I see two different implementations for the filters though:

1. Having an additional property such as operator to define the filter operation. (Metriql follow this approach)
2. Or let the user define the value and figure out the operation with some special characters such as -. (Looker example)

Even though we follow 1, we're happy to implement 2 for better readability but we should probably think more about the coverage and user experience.

BI-tool specific properties under meta

Each BI tool has its own naming and semantic types and we believe that they should also be defined in YML files. It's one of the most used features of Metriql (see example) but it's hard to standardize so they can fit under meta property I guess.

approx_distinct aggregation type

Modern cloud data warehouses support approximation already and it's the preferred approach for big datasets. It's also additive unlike count_distinct and I believe that we should support both aggregation types. We can either have something like approximate of Looker and use approximation if the aggregation type is count_distinct but we're in favor of adding as an additional aggregation type for convenience since some of the databases don't support it.

Join relations

I believe that metric stores should support joins but I see the reasoning here. We aim to help analytics engineers automate creating dbt models for dimensional modeling and denormalizing the datasets into wide tables might be confusing for some use-cases. We can extend the standard in our implementation and denormalize the dimensions & metrics when exposing them to the downstream tools as we have customers using join relations at the moment.

[alexanderdean]

Supportive, this would mean Snowplow dbt packages can have the metrics built-in. As package authors who already have multiple data stores/SQL flavors to support 💸, it would be great to see market standardization at the metrics definition layer 💯!

[carlineng]

Some things that popped into my mind while reading this --

• Will the metric node type always be a leaf node? I can imagine wanting to materialize a specific cut of a metric as a model, or define another metric such as a ratio that uses two metrics as inputs.
• I agree with previous comments that viz/format related properties shouldn't necessarily be top-level keys.
• I believe that implementing some kind of * functionality to include all model fields as dimensions would require dbt to know quite a bit more about models than it currently does. From my understanding, dbt doesn't actually know much about the DB table underlying a model outside of what is listed in the schema.yml file. Resolving * to a list of actual columns would require compiling the query itself. There are also many cases where columns don't make sense as dimensions, e.g., a "total_revenue" column.
• I'm interested to see more about the interface for querying metrics.