charts "grouped by month" are mislabelled on the x-axis - crucial UX bug

[samuelstroschein]

Bug description

The grouped-by-month view in charts is hella confusing. The x-axis shows a date that does not reflect the value on the y-axis.

1. the y-axis shows the number for the END of the month
2. the x-axis reads as "beginning of the month"

Comparison with daily grouping

Compare the "group by month" view with "group by day". The x-axis labeling aligns with the y-axis values.

How to reproduce

1. Group a chart by month
2. select "unique events"

Proposal

1. easy fix - remove the "1." from the labelling

• will still confuse readers with "is this the beginning or end of the month"

2. correct fix - show end of month

• removes ambiguity from "is that the beginning or end of month"
• harder to implement because months have different end days

cc @jannesblobel

[samuelstroschein]

fyi this bug led to a "omg is posthog buggy" feeling.

this bug is a recurring problem when communicating metrics with the team. we don't understand why posthog never fixed this bug (we raised it via email). now, i understand everyone is busy. that's why we invested the time into this clear issue with proposals.

suggestion

1. release the quickfix now (should take 10 mins?)
2. implement the correct solution with a follow up update

[mariusandra]

Hey there, I guess nobody "fixed" this, as nobody out of all our users got confused so far 🙃.

We'll work on the "quick" fix, but to be clear, your confidently proposed "correct solution" in this case is incorrect, since different users look at different data, and this chart supports many sources, including custom SQL aggregations. "Average per month" for example would look really bad if shown with a end-of-month date.

In any case, thanks for flagging and we'll see for the "quick" fix.

[samuelstroschein]

Thanks for the quick resolution!

confidently proposed "correct solution" in this case is incorrect, since different users look at different data, and this chart supports many sources, including custom SQL aggregations.

correct me please. the graph is showing a timeseries. the x-axis shows the date. regardless of custom queries. the end of the month date e.g. Feb 29 2024 will always be on the same spot on the x-axis. (By not labeling the spot "correctly" e.g. Feb 29, ambiguity arises what the x-axis is displaying.)

"Average per month" for example would look really bad if shown with a end-of-month date.

This is precisely why we decided not to use the aggregation function provided by posthog for "monthly active users" :D It can be misleading.

[mariusandra]

This is precisely why we decided not to use the aggregation function provided by posthog for "monthly active users" :D It can be misleading.

What I read is that you agree that just showing months/years is the clearest way forward? :D

...

A bit of background context though: these charts are almost the same that they were literally a year ago. We've been very busy for over a year reworking the backend of the system. We even had to build our own query language (in public of course) to make the dream come true. Other than a general design refresh, we haven't prioritised the UI of product analytics at all. We are now in the final steps of migrating all our insights over to this new system. Here's the issue tracking the progress for trends.

Once that's all done, it'll unlock so many new things for us, and our immediate priority after is to actually make the experience of using product analytics a joy.

We all know things are meh around the edges, yet we must prioritise if we want to make progress. The fix to remove "1-" is indeed an easy one (though not 10min, mind you), so we'll get that in. However an intelligent method of determining "the 100% perfect" date is out of scope for now.

Thanks again for raising, and I hope my slight snark in the previous reply came off good humoured. We do appreciate feedback!

[mariusandra]

Ah, forgot to reply to the other question:

correct me please. the graph is showing a timeseries. the x-axis shows the date. regardless of custom queries. the end of the month date e.g. Feb 29 2024 will always be on the same spot on the x-axis. (By not labeling the spot "correctly" e.g. Feb 29, ambiguity arises what the x-axis is displaying.)

Well, yes, no and maybe. It's not so simple. If we have the first point on the chart, the one that intersects the Y axis, say "31 August", then it'll look confusing in a different way, as it'll feel like the data for 1-30 August has been omitted. I can bet you a bowl of lasagne we will get a lot more support requests this way. It might be more "technically" correct, but in my experience that's not the only thing that matters :).

[samuelstroschein]

We all know things are meh around the edges, yet we must prioritise if we want to make progress. The fix to remove "1-" is indeed an easy one (though not 10min, mind you), so we'll get that in. However an intelligent method of determining "the 100% perfect" date is out of scope for now.

Yep, thought so. The easy fix will lift the majority of the confusion!

---

No response is needed for the remarks below, but feel free to reply!

If we have the first point on the chart, the one that intersects the Y axis, say "31 August", then it'll look confusing in a different way, as it'll feel like the data for 1-30 August has been omitted. I can bet you a bowl of lasagne we will get a lot more support requests this way

I bet against it. If you are in NYC, I will happily invite you over for dinner if I lose. If you lose, I still invite you over but you have to buy the lasagne from the caterer around the corner ;)

1. The chart displays a time series. It is clear that labels from Aug 1-Aug 30 are missing to reduce noise indicated by the equal gaps between the dates.
2. The trendline indicates that even if it is not Aug 31, the values are projected to Aug 31.

[mariusandra]

Haha.. I'd be down for that, yet sadly I have no plans to fly over the pond in the near future (hi from Belgium), and an AB test of this kind is definitely not something we can justify in sprint planning... 😆

However my years in this industry have taught me that 1) what's clear to you is not clear to everyone, 2) what's not clear for you is definitely guaranteed to be confusing to someone else, 3) nobody is special

The solution you're proposing might be clearer in the context of a trends line chart, and for sure the "cumulative" trends line chart... but again only for some aggregations, which we'd need to determine in a clever way. You want a solution to your chart, yet as PostHog we have to figure out a solution to all types charts for all users with a huge variance in backgrounds (both technical and not). Aggregating over a full month and only showing one day inherently makes people pause and think, and we don't want that. The "year and month" solution is thus the best compromise in my book. (Again, I live in Belgium, we're experts in compromise here 😅)

PS. Looking at the modified screenshot, "30-Aug-2023" on a chart would for sure confuse me 🙈 😆