Hello everybody Trick question here: Assuming tha...
# product-management
Hello everybody Trick question here: Assuming that our product is for internal use, and the company does not work 24x7, does we have to exclude weekends in the products metrics like DAU? ps: I'd love comments, but a quick interaction with đź‘Ť or đź‘Ž will be great either
I would say that the classic answer will work here - it depends 🙂 I would personally advice using the more-common definition of DAU which includes all the days. The rationale is that other parts of the company may use the same metric and it can be really confusing if they will have different definitions. But it may be that a metric is really specific to your area and tracking weekends will complicate your analytics and decision-making. Then it makes sense to exclude weekends. But I would consider selecting some unique names for your metrics so there is less room for potential confusion around definitions.
Spotting non-zero DAU on weekends could be instructive… Also, adding complexity to the definition introduces risk of errors in implementation and interpretation. Finally, answering properly requires that you examine the requirements. Who is looking at your product metrics, and why? What decisions will be made based on reported DAU? Shameless plug: read https://docs.google.com/document/d/1K0UvJyr0WkzlUm6rZvqscac_ds5TwSD5rJKzwPNth_s/edit?usp=sharing)
I’d suggest that averaging obscures your story. What does the graph of DAU over a few weeks look like? How do those numbers compare to WAU? (Do you have the same 37 users every day? Or 150 people using it once a week?) This is based on one of Edward Tufte’s guiding principles, “Enforce Comparisons”. Thanks for the compliment about my notes! Connecting to that, who cares if your numbers go up or down? Why do they care? What is the link between DAU and making developers’ lives easier?
Good Question, @David Schweizer, but we assume that if more devs are using the platform every day, is becouse it has meaningful things to consult, means that it's part of his daily life as a dev in our company
I'll read more about
Edward Tufte's guiding principles, "Enforce Comparisons".
It sounds interesting.