Katie Bauer!

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