Engineering · Privacy Analytics
Redirect Analytics Done Right: Why We Separate /go Redirects from Short Link Clicks
When you run a privacy-first redirect service, every number you surface in your dashboard carries a philosophical weight: is this metric useful enough to justify collecting it, and can we collect it without tracking anyone?
We recently shipped a change to our admin analytics that sounds small but reflects a design principle worth unpacking. TraceNull now separates /go redirect counts from short link click counts — and displays them as distinct metrics alongside a new "active shorts" counter. In this article we'll explain what these two redirect types are, why lumping them together was misleading, and how we built the split without storing a single IP address or user identifier.
Two Redirect Paths, Two Different Use Cases
TraceNull offers two ways to pass traffic through its referrer-stripping infrastructure:
1. The /go Endpoint (Instant Referrer Stripping)
Anyone can visit tracenull.cc/go?url=https://example.com and be redirected to the destination with all Referer headers stripped. No account needed, no short link created. This is TraceNull's core public utility — a stateless referrer laundry for the open web.
2. Short Links (Shortened URLs)
Users create a short link like tracenull.cc/a7xQ that maps to a destination URL. These links have slugs (2, 4, or 6 characters depending on your plan), optional TTLs, optional passwords, and optional click analytics. They also strip the referrer on redirect — but they persist in the database and serve a different purpose than the raw /go endpoint.
Key distinction: /go is ephemeral and stateless. Short links are persistent and configurable. Both strip referrers, but they serve fundamentally different audiences and workflows.
Why We Used to Combine Them (And Why That Was Wrong)
In our original admin stats implementation, we had a single "redirects" counter. Every time TraceNull sent a user onward — whether through /go or through a short link slug — the number went up by one.
This felt clean. One service, one metric. But it created problems:
- Signal noise: A spike in
/gotraffic (say, someone shared the endpoint on a forum) would inflate the redirect count and make it look like short link usage had surged — when it hadn't. - Capacity planning blindness: Short links consume database rows and have TTL schedules. The
/goendpoint consumes zero storage. Knowing how many of each type helps us understand infrastructure load. - Feature prioritization: If 90% of redirects are
/goand 10% are short links, that tells us something very different about what users value than a 50/50 split.
A combined counter answered the question "how busy is TraceNull?" but failed to answer "how is TraceNull being used?" — and that second question is the one that drives good product decisions.
What the New Dashboard Shows
The updated admin stats panel now surfaces three distinct metrics across four time windows (today, 7 days, 30 days, and 365 days):
| Metric | What It Counts | Storage Impact |
|---|---|---|
| /go Redirects | Hits to the /go?url= endpoint | None (stateless) |
| Short Link Clicks | Hits to a slug like /a7xQ | Row lookup in SQLite |
| Active Shorts | Short links that haven't expired yet | Current DB row count |
The "Active Shorts" metric is new too. It tells us at a glance how many short links are live in the system — which directly maps to database size and TTL cleanup workload.
How We Count Without Tracking
Here's where privacy-first engineering gets interesting. Counting redirects is trivial if you're willing to log request data. It's harder when your entire value proposition is not logging request data.
Our approach uses aggregate-only counters:
Increment, don't log. When a redirect fires, we increment an integer counter in SQLite. We do not store the timestamp of the individual request, the source IP, the User-Agent, or any other request metadata. The counter goes up by one. That's it.
Bucket by day, not by request. Counters are bucketed into date-level granularity. We can tell you "there were 847 /go redirects on July 8th" but we cannot tell you when during that day any individual redirect happened, or who triggered it.
Separate the type at write time. When the redirect middleware fires, it already knows whether the request hit /go or a slug route. We use that to increment the correct counter column. No post-hoc classification needed, no request logs to parse.
Roll up with SQL, not analytics tools. The time-window views (today, 7d, 30d, year) are simple SUM() queries over the date-bucketed counters. No external analytics pipeline. No data warehouse. Just SQLite doing what SQLite does best.
The privacy test: If our server were seized tomorrow, could anyone reconstruct a single user's browsing behavior from our analytics data? No. They'd find integer counters grouped by date and redirect type. That's the standard we hold ourselves to.
What This Means for Business Plan Users
If you're on TraceNull's Business plan and using the API to create short links at scale, this separation matters for you too. Your per-link click counts have always been isolated from /go traffic — but now the system-level stats reflect that separation as well.
This means:
- Cleaner campaign measurement: When you check how many clicks your short links received this month, that number isn't polluted by unrelated
/goredirect volume. - Better capacity awareness: The "Active Shorts" counter helps you understand how many of your links are live versus expired, which matters when you're managing hundreds of campaign links.
- Trust in the data: Every metric we show you can be explained in one sentence. No black-box "engagement scores," no sampled estimates, no metrics that require a PhD to interpret.
The Bigger Principle: Metrics Should Justify Their Existence
Most analytics platforms default to collecting everything and letting you filter later. That's the surveillance model applied to your own product. We take the opposite approach: every metric must justify its existence before we build it.
Before adding the redirect-type split, we asked three questions:
- Does this metric help us make a specific decision? Yes — it tells us whether to invest more in the
/goendpoint or in short link features. - Can we collect it without storing personal data? Yes — it's an integer counter increment with no PII attached.
- Would removing this metric make the product worse? Yes — the combined counter was actively misleading.
If a proposed metric fails any of these three questions, we don't build it. This is how you keep a privacy-first product honest over time — not through policy documents, but through engineering discipline at the moment of implementation.
A note on vanity metrics: We deliberately do not surface "total redirects all time" as a headline number. It's a vanity metric that incentivizes growth-at-all-costs thinking. Time-windowed counts are more useful and more honest.
What We Removed (And Why)
Alongside adding the redirect-type split, we removed the "Short Links" tab from the admin panel. This tab listed individual short links in the system — and while it contained no user data, it was redundant with database-level tooling and added UI clutter without adding insight.
Removing features is as important as adding them. Every element in a dashboard competes for attention. If a panel doesn't drive a decision, it's noise — and noise is the enemy of clarity in privacy-respecting analytics.
Try It Yourself
The redirect-type split is live now. If you're using TraceNull's /go endpoint for referrer stripping or creating short links through our dashboard or API, your clicks are being counted accurately — and privately — with the new separated metrics.
Privacy-first link shortening with transparent analytics
Create short links that strip referrer headers and count clicks without tracking users. Free tier available — no account required for /go redirects.
Start Shortening LinksPrivacy isn't just about what you strip from outbound headers. It's about what you choose not to record in the first place. Separating redirect types gave us better data by being more precise — not by collecting more. That's the kind of trade-off we'll take every time.