Two small things that annoyed people daily. Analytics no longer scrolls back to the top when its data refreshes, and Chat no longer flashes an empty screen before showing your conversation.
What changed
Analytics refreshes its figures periodically so what you are looking at stays current. The refresh was rebuilding the page rather than updating the numbers in place, and rebuilding the page sent you back to the top of it.
If you were reading a campaign halfway down a long list, you were returned to the top, and you scrolled back. Then it happened again. On a long analytics page this could interrupt you every thirty seconds, which is often enough to make reading it properly genuinely difficult.
The refresh now updates the numbers where they are. Your scroll position stays put, and the figures change under you without moving anything.
Chat had a different problem with the same shape. Opening a conversation showed the empty state, the one that says you have no messages yet, for a fraction of a second before the messages arrived and replaced it.
That flash was harmless and looked broken. On a slow connection it lasted long enough to read, and the first impression of an empty conversation is unsettling when you know you have been talking to it for a week.
Chat now shows nothing until it knows whether there is anything to show. Genuinely empty conversations still show the empty state. Loading ones show a loading state, which is what they are.
Why it matters
Neither of these lost data or broke a workflow. Both made the product feel careless, and they did it on screens people use every day.
There is a practical cost too. Losing your scroll position while reading a comparison across campaigns means starting the comparison again, and after the third time most people stop trying and export the data instead.
The flash cost less but happened more often. Every time you opened a conversation, a moment of the product telling you something wrong.
Why bugs like this survive
Both are invisible in testing and obvious in use. A test that opens Chat and asserts the messages appear passes, because the messages do appear. The flash before them is not something an automated check notices.
The scroll jump is worse, because it only shows up when you are far enough down a long enough page during a refresh. Nobody encounters that while testing a change to analytics. Everybody encounters it while reading analytics.
This is the category of problem that only surfaces from people using the product for real, which is why reports of small annoyances are worth more than they usually get credit for.
What else this touched
The analytics fix applies to every screen that refreshes on a timer, not only the campaign list. Any page where numbers update while you read them now keeps your position.
The Chat fix applies to the same loading pattern wherever it appears, so other screens that briefly showed an empty state before their content no longer do.
Fixing the shared behaviour rather than the two reported cases means the sibling instances nobody had reported yet went with them.
Why small things get fixed
There is always a temptation to spend every hour on the large problems, and by any measure of severity these two rank near the bottom. Nothing was lost, nothing was blocked, no data was wrong.
But the daily cost of an annoyance is not measured by its severity, it is measured by its frequency multiplied by how many people hit it. A half second of wrongness every time somebody opens Chat adds up across a team across a month into something worth an afternoon of work.
There is also what small breakage signals. A product that gets the small things right earns trust on the large ones, because the two are usually built by the same hands with the same care.
What a loading state should do
The rule these two fixes follow is that the interface should never assert something it does not yet know. An empty state is a claim: there is nothing here. Making that claim while still fetching is simply wrong, and the fact that it corrects itself within a second does not make it right.
A loading state makes the honest claim instead: something is coming. It is less satisfying to design and it is what the situation actually is.
The same reasoning covers the scroll position. Refreshing data is not the same event as navigating to a page, and only one of those should move you.
Reporting things like this
Both of these came from people mentioning them rather than from any monitoring. Nothing in a log flags a page that scrolled to the top, and no error rate moves when an empty state flashes.
Small annoyances are worth reporting for exactly that reason: they are invisible from our side and obvious from yours. If something in the product irritates you daily, that is worth a message even when it feels too minor to mention.
What we changed in how these get caught
Both fixes came with a check that fails if the behaviour returns, which is more useful here than it sounds. Interface regressions are easy to reintroduce, because the code that causes them is usually a reasonable change made somewhere else.
The scroll behaviour in particular is fragile. Any future change to how analytics refreshes could plausibly bring it back, and without a check, the way we would find out is somebody mentioning it again in a month.
Neither check replaces using the product. They catch the specific regression, not the next annoyance of the same shape.
Availability
Live now on all plans. Nothing to enable.