You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 metricflow functionality, rather than a Big Idea better suited to a discussion
Describe the feature
In a real business environment it happens that we might have multiple widely used names for the same metric. It should be possible to define aliases for metrics so that users could query the metric by either name. For example:
metrics:
- name: subscription_revenue
label: Subscription Revenue
alias: premium_revenue
alias_label: Premium Revenue
description: We have a subscription business called "premium", this metric shows the revenue from the subscription a.k.a. premium product
type: simple
type_params:
measure: revenue
Describe alternatives you've considered
Defining one metric and a derived metric on top of that metric, to be able to give the derived metric a different name, although there is no calculation involved. This option would create unnecessary complications in the compiles SQL and inflate the number of metrics in the glossary.
Who will this benefit?
All MetricFlow users.
Are you interested in contributing this feature?
With testing and feedback, yes
Anything else?
No response
The text was updated successfully, but these errors were encountered:
Is this your first time submitting a feature request?
Describe the feature
In a real business environment it happens that we might have multiple widely used names for the same metric. It should be possible to define aliases for metrics so that users could query the metric by either name. For example:
Describe alternatives you've considered
Defining one metric and a derived metric on top of that metric, to be able to give the derived metric a different name, although there is no calculation involved. This option would create unnecessary complications in the compiles SQL and inflate the number of metrics in the glossary.
Who will this benefit?
All MetricFlow users.
Are you interested in contributing this feature?
With testing and feedback, yes
Anything else?
No response
The text was updated successfully, but these errors were encountered: