You ship updates. Maybe a changelog widget, maybe a "what's new" page, maybe just a post that says "we shipped X." And then you have no idea if a single person read it.
That is the uncomfortable part of shipping in public. You put the work in, you announce it, and the announcement disappears into the void. Views are vanity. What you actually want to know is whether anyone cared enough to click through and look.
You can measure that. Here is the setup I use.
The problem with raw view counts
Most changelog tools and update feeds will happily tell you how many times a page was loaded. That number lies to you in two directions:
- Bots, prefetchers, and your own reloads inflate it.
- A "view" tells you a page rendered, not that a human read a word of it.
The signal you actually want is intent. Someone read an update, and it mattered enough that they took the next step and clicked the link in it. That click is worth a hundred passive views, because a human chose to make it happen.
So the trick is simple. Make every link you put in an update a measured link.
Wrap your update links in tracked short links
Whenever an update contains a link (to the new feature, to a doc, to a demo), do not paste the raw URL. Run it through a short-link tool that records analytics on the redirect. Now every time someone follows that link, you capture:
- Referrer, so you know whether the click came from the in-app widget, the hosted page, an email, or somewhere you did not expect.
- Device and browser, so you know if the feature you built for developers is actually being opened on phones.
- Country, which feeds timing and localization decisions.
- Unique vs repeat, so you can tell ten curious people apart from one person clicking ten times.
None of that requires a heavy analytics stack or a cookie banner. It is just a redirect that counts.
Reading the data (this is the part that changes what you do)
A tracked link turns a vague feeling into a decision. A few patterns that show up in real data:
- Clicks cluster on the hosted page, not the in-app widget. Your in-app placement is too quiet. Move it.
- High clicks, but all repeat visitors. Your existing users care, but the update is not reaching anyone new. That is a distribution problem, not a product one.
- A feature you were proud of gets almost no clicks. Before you assume nobody wants it, check whether the announcement itself was clear. Often the feature is fine and the release note was the noise.
- One channel massively outperforms the rest. Now you know where to spend your next announcement.
The point is not the dashboard. The point is that "did anyone read it" stops being a shrug and becomes something you can answer and act on.
How I wire this up
Full disclosure, both tools here are mine, which is exactly why I built this loop for myself.
I keep my product's release notes in a changelog widget. I build Patchlog, a drop-in changelog widget, so that part is easy for me. Every link that goes into an update, I route through a short link with analytics. I also build Swyfty, so I use that. The result is that when I ship something, I am not guessing whether it landed. I can watch the clicks come in, see where they came from, and see whether it was the same five people or someone genuinely new.
You do not need my tools to do this. Any changelog surface plus any short-link tool that exposes referrer and device data will get you there. The habit is the valuable part. Never ship an update with a naked link in it, and read the clicks a week later like a scoreboard.
Shipping is only half the job. Knowing whether the shipping was heard is the other half, and it turns out to be cheap to measure once you set it up.
Top comments (0)