Katie Bauer!

But not all types of data are the same. I've been trying to think of a way of explaining it to non-DS, and the mental model I'm currently working with has three main layers: records, summaries and metrics

Records are the foundation. They're extremely literal data--event logs of prod systems, snapshots of user states and server configurations, etc. Data scientists may use them in their work and advise on what records are needed, they aren't directly responsible for creating them

You CAN do all your analysis by querying records but it's not very efficient, particularly as the size of your dataset grows. This is where summaries come in.

Summaries get called a lot of things (facts, aggregates, rollups) and they're also pretty literal. They're often counts of particular types of records, used to precompute the results common queries and ensure the relevant slice dimensions and join keys are available

A well-curated set of summaries gives you a lot of analytical power. You've got a lot of computational heavy lifting done, and you can dynamically combine different summaries to answer a lot of business questions.

You can even use them to cheaply interrogate your assumptions about a system. Think about how often you expect a user to take action X on a given day, then use your summaries to see if it's higher or lower.

If the number you find doesn't match your expectations--congrats, you may have just found a user problem and have a new data-driven roadmap item that you can brag to your friends about

But sometimes a summary isn't detailed enough. Maybe you need to filter for certain subsets of your user base, or chain their actions into a known user journey, or look at their actions over specific windows of time... This is when you need metrics.

Metrics are where business logic lives. They're a way of formally encoding the relevant dimensions of a business problem you've decided to solve, and if you want to have an extensible, modular system for doing analysis, you will want to decouple business logic from summaries

Once a summary of what happened in a system is generated, it doesn't change unless something happens to the underlying records the summaries are based on. Business logic, on the other hand, constantly evolves

Company strategies are tweaked as the market evolves, users react and adapt their behavior to new product features, once-important projects get deprioritized... All of these things can impact the usefulness of your metrics

Thanks to the modularity granted by separating summaries from metrics, it's much easier to change the business-logic-enforcing code to calculate your metrics. It's also a lot easier backfill historical values for new metric definitions, or two maintain a v1 and a v2 of a metric