Hi Jared, 

Thanks for the relevant question - there is no proper best practice here, as it does not impact performance or overall architecture.

As of today, here are a few pros and cons:

Properties

• appear in groupings in the pivot panel
• are easier to type in in a formula (typing simply Dimension.Property)
• can be chained (Dimension.'Grouping 1'.'Grouping 2'.'Grouping 3')

Metrics

• do not “pollute” the pivot panel
• are easier to manage if you have a lot of them (e.g. more than 30-50 in your dimension, depending on your tolerance) and can be stored in folders / subfolders
• are very easy to migrate should you want to update the structure, if you decide your grouping changes over time.

This last one means that if you use a metric to store the Employee’s Country and want that to be dependent on time, all of the metrics that use it will auto-update after changing the structure of your mapping metric.

While your app grows, it’s normal to go from the easiness of the property to the versatility of the metric at some point, but Pigment makes it easy to migrate from one to the other.

Hope this helps!

What a terrific answer @francois !! Thank you. I’ll need to explore the metrics a bit more. Do you think the overuse of metrics could lead to some modelers creating duplicates, meaning performing the same calculation more than once because they didn’t remember they already created a metric to do the same thing?

I hope not! On larger app creation, I see it can be common to create multiple flows that are quite similar - but with a good folder structure, this should not happen too much.

I guess this is not different to any other calculation process where you always run the risk of computing things twice, especially when your app goes above a size where you can remember what all blocks do - but this is not unique to metrics either, this also applies to properties too. If a dimension has more than, say, 100 properties, you also run the risk of forgetting what each does.

As for performance, Pigment tries to prioritise the calculation of the most “active” blocks, e.g. those that are displayed, or are part of a chain of calculation that will be displayed somewhere. There are active developments to make sure that dead ends (e.g. blocks that are calculated but not used in important dashboards) are less likely to be computed first, to make Pigment run the most important blocks first, always.

It’s better to not compute them in the first place, but if you end up with duplicates it’s not the end of the world.

I crisply salute you @francois - thanks for the answer.