Enable Metrics to work against Models like they work against Data Models

[likeshumidity]

Is your feature request related to a problem? Please describe.
From a user perspective, there is ambiguity between Models and Data Models. There is an expectation that functionality of one would be available in the other. But both have functionality that is implemented mutually exclusively.

By using a Model, user's gains model caching, cleaned up data models and meta data that can be used as a standard basis, but they lose the ability to use Segments and Metrics. Due to the similar functionality names (Models and Data Models), this can be confusing as to why Segments and Metrics don't work on Models.

Describe the solution you'd like

• Add Metrics that work on Models like the Metrics that work on Data Models

Describe alternatives you've considered
All of the below have wide scopes:

• Add all Model functionality to Data Models - this would require admin scope for everything or require change to permissions
• Add all Data Model functionality to Models - there are a few things that should only happen on the first layer on top of the database
• Moving Metric and Segment functionality to Models instead of at the Data Model level - requires new management UI and potentially permissions as none exists outside of Admin

How important is this feature to you?

• Customer requested.
• Additional parity between Data Models and Models or clearer boundaries between them would reduce user confusion when determining which to use.

[fabiodesousa]

As a customer, this would be immensely helpful. It's very frustrating right now that we have to choose between building with Models or building with Metrics/Segments. Both sets of features are great, but hampered by the lack of the other.

[beefstew]

What about allowing table-defined Segments to percolate through and become available on the Models that source data from those tables?

Two caveats:

1. I may be designing for a use case that is unimportant if users are coached to start their experience using models rather than against tables. Right now, however, the onboarding workflows encourage a user to build everything against tables... which creates configuration debt if they should be really using models.
2. There may be permissions obstacles, but I have not yet learned anything about permissions (thankfully!?).