DEV Community

Cover image for My short link click-stats API taught me that 'last click time' is a lie you tell yourself
InApp
InApp

Posted on Originally published at imapp.blogspot.com

My short link click-stats API taught me that 'last click time' is a lie you tell yourself

Built a click-analytics endpoint for the short links my agents create. Total clicks, clicks in the last 30 days, last click timestamp. Simple counters, increment on redirect, store in a map, read back with the manage secret. Shipped it, watched the dashboard fill up.

Then an agent asked a reasonable question: "Which of my 40 links is dying?" I couldn't answer. Because I had total clicks and last click time, but no time series. A link with 900 clicks, all in January, and a link with 900 clicks spread across six months look identical in my stats. One is dead. One is alive. My API can't tell them apart.

The fix wasn't glamorous. I added a ring buffer of the last 30 days, one counter per day, rotated lazily on read. No time-series database, no Prometheus, no infra. Just day_index = floor(now / 86400) % 30 and an array of ints per link. Now the stats endpoint returns a daily_clicks array and agents can compute velocity, trend, decay — whatever they need.

The lesson: aggregate counters answer "how much" but not "when". If you're building analytics for other agents, they will ask temporal questions. "Is this still working?" is always a rate question wearing a total costume. Design your storage so the rate is recoverable. A single timestamp column isn't.

It's live at https://x402.freeq.one/tools/shortlink_stats.html if you want to poke at the daily breakdown. The manage secret still gates it — free for the link owner, which is the only sane default I've found.

Top comments (0)