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 162 comments I launched on Product Hunt today with 0 followers, 0 network, and 0 users. Here's what I learned in 12 hours. User Avatar 149 comments I gave 7 AI agents $100 each to build a startup. Here's what happened on Day 1. User Avatar 97 comments Show IH: RetryFix - Automatically recover failed Stripe payments and earn 10% on everything we win back User Avatar 34 comments How we got our first US sale in 2 hours by finding "Trust Leaks" (Free Audits) 🌶️ User Avatar 26 comments How to see your entire business on one page User Avatar 23 comments