[Feature] Allow for custom-defined metrics types

Is this your first time submitting a feature request?

• I have read the expectations for open source contributors
• I have searched the existing issues, and I could not find an existing issue for this feature
• I am requesting a straightforward extension of existing dbt functionality, rather than a Big Idea better suited to a discussion

Describe the feature

Note: I am creating this issue following a Slack thread during 2022-08-04 dbt Staging.

Currently there is a defined list of type values that may be used for metrics. I assume that over time more will be added, like median. I support adding various common, standard types.

BUT, it would be nice if users could define their own custom types. That would make it super extensible, and then dbt devs wouldn’t be on the hook to anticipate every scenario. A custom type would likely be very specific to an org’s business context, so it makes sense for development to be in the hands of the user rather than relying on a finite list.

I hypothesize that while any individual custom definition of a type could be considered fringe or rare, in aggregate, the various fringe types could constitute a significant proportion of metrics that users need to implement.

Describe alternatives you’ve considered

dbt devs greatly expand the type options, while still inevitably failing to anticipate all user needs.

Who will this benefit?

• Users who want to develop a metric type that has not yet been conceived of and/or is not one that should be made available to the broader community, most likely because it is a fringe use case.
• dbt devs who don’t have to do as much work building out type options.

Are you interested in contributing this feature?

Possibly! I don’t know enough about the mechanics of type or metrics overall to say if I’d be the best person to help with this, but it seems possible that I could be helpful.

Anything else?

No response

[callum-mcdata]

@leoebfolsom that first description is correct! Just like the overriding of other dbt macros for things like namespacing, the user would be responsible to keep it updated. But it gives you the flexibility to add any metric aggregation that you are interested in (within reasonable limits).

I mention the reasonable limits because more complicated aggregations like window functions would probably fail due to the way we construct the sql but I haven’t extensively tested this issue.

I’ll close out this issue because the functionality exists but if you have any questions feel free to ping me or we can open up another issue!

[leoebfolsom]

@joellabes thank you for going through this, it makes sense! I think if we added custom macros, we’d call them median_custom_companyname or something to avoid the exact issue you mentioned. A little hacky, but feels like a reasonable practice to avoid collisions while still always inheriting the latest and greatest from the main package.