A confusing aspect of DS work is that your input is data and your output is... often also data
-
-
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.
Show this thread -
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
Show this thread -
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
Show this thread -
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
Show this thread -
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
Show this thread -
Creating useful metrics is a huge problem in its own right, but a design like this reduces some of the overhead (and potential tech debt) involved
Show this thread
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.

