1
2 Comments

Just shipped Link Analytics for my SaaS. Here is why it was harder than I thought. 📊

Hey IH! 👋

I’m currently building NanoURL [https://nanourl.link/], and I just shipped one of our most requested features: Granular Link Analytics.

Up until now, we only tracked a raw "Total Clicks" counter. But as users started using our tool for marketing campaigns, they needed to know exactly who was clicking their links and from where.

I wanted to share a quick "build in public" update on the process, because building a scalable analytics engine turned out to be a really fun architectural challenge.

The Challenge: Speed vs. Data
The core rule of a URL shortener is that redirects must be blazing fast. But gathering analytics (parsing User-Agents, resolving IP addresses to geolocations, writing to the database) is heavy.

If I put the analytics logic in the same synchronous thread as the redirect, the user experience would suffer.

The Solution
I ended up completely decoupling the two. Now, when a user clicks a short link, the server instantly fetches the destination, fires an asynchronous event to a background worker, and redirects the user immediately. The background worker then takes its time to process the data, extract the browser/device info, and safely store it in PostgreSQL.

Writing the SQL to aggregate time-series data for the React charts was a bit of a learning curve, but seeing the data populate perfectly on the frontend was incredibly satisfying!

(See the attached screenshot of the new dashboard!) 📸

We are currently tracking:

Click Volume over time (30-day timeline)

Unique Visitors

Top Referrers (Direct, Twitter, LinkedIn, etc.)

Device & Browser Breakdowns

Top Geographies (Country & City)

I’d love your feedback:
For those of you who rely on analytics for your own projects, are there any specific metrics or data points you find absolutely critical that I might be missing? Also, any feedback on the UI layout in the screenshot is highly appreciated!

Keep building! 🚀

posted to Icon for group Building in Public
Building in Public
on April 19, 2026
  1. 1

    The async queue approach for decoupling redirect speed from analytics write is the right call. The failure mode you avoided is the one where founders add instrumentation directly in the hot path and then wonder why p99 latency spiked. One thing worth thinking about next: are any of the referrer sources in your data linking to specific short links rather than the homepage, and if so, which of those links correlates most with trial conversions?

  2. 1

    Decoupling the redirect from the analytics logic is a smart architectural move, Rahul. Ensuring redirects stay "blazing fast" while handling heavy background processing is exactly what separates a side project from a production-ready marketing tool.

    I’m currently running a project in Tokyo (Tokyo Lore) that highlights high-utility technical builds just like NanoURL. Since you're focused on granular metrics and scalable infrastructure, entering your project here could be a perfect way to demonstrate your "Software Eng. @ Night" logic to a live field of founders.

Trending on Indie Hackers
The most underrated distribution channel in SaaS is hiding in your browser toolbar User Avatar 192 comments How are you handling memory and context across AI tools? User Avatar 107 comments I gave 7 AI agents $100 each to build a startup. Here's what happened on Day 1. User Avatar 101 comments Do you actually own what you build? User Avatar 64 comments Code is Cheap, but Scaling AI MVPs is Hard. Let’s Fix Yours. User Avatar 34 comments How to see your entire business on one page User Avatar 29 comments