Three tools rarely count the same event. A shortener logs a redirect request the moment any HTTP client hits it, an ad platform reports what it thinks led to that request, and a website analytics tool only counts a "click" once a browser has loaded a page and run a script. Those are three different moments in the same journey, so the numbers are supposed to disagree. The question is whether the gap is normal or a sign something is actually wrong.
What each layer is actually counting
Think of a single tap on a bio link as a chain of events: request sent, redirect served, destination page loaded, script fired, session recorded. Every tool in your stack sits at a different point in that chain, and each one only sees what happens from its position onward.
| Layer | What it counts | What it misses |
|---|---|---|
| Shortener or link tracker | Every HTTP request that hits the redirect, human or not | Whether the visitor ever saw the destination page |
| Ad platform (Meta, TikTok, Google) | Clicks it attributes to its own ad, based on its own tracking pixel or click ID | Clicks that happen outside its attribution window or get blocked by the browser |
| Website analytics (GA4, Plausible) | Sessions where the page's JavaScript actually executed | Anything blocked before the script runs: prefetches, ad blockers, in-app browser restrictions |
| Raydar link analytics | Every redirect request, with a first pass to separate obvious bot and prefetch traffic from human clicks | Behavior on your destination site after the visitor leaves the link |
Once you see it laid out this way, a mismatch stops looking like a bug. It's what you'd expect. Three tools measure three different things. The real work is figuring out which gap you're actually looking at.
The most common reason: link prefetching
The single biggest source of "my shortener shows more clicks than my analytics" is link prefetching, and almost nobody accounts for it. When you paste a link into iMessage, Slack, Discord, or WhatsApp, the app sends a real HTTP request to that URL before any human taps anything, purely to generate the preview card with the title and image. That request goes through your redirect and gets logged as a click at the shortener layer. It never reaches your destination site's analytics, because no browser page ever actually renders there.
This means the gap is front loaded. In the first few minutes after you share a link, expect the shortener count to run ahead of the analytics count by however many messaging apps generated a preview. After that window closes, the two numbers should converge as real humans start clicking. If your shortener count is consistently 10 to 20 percent higher than analytics and the gap shows up immediately after sharing rather than building over hours, prefetching is almost certainly the explanation, not a tracking failure.
Ad blockers and bot filtering cut the other way
Prefetching inflates the redirect count relative to analytics. Ad blockers and privacy extensions do the opposite: they let the initial redirect through (it is a server response, not a script) but block the analytics tag that would have counted the visit as a session. So a visitor can click your link, land on your page, read it, and never show up in GA4 at all, while your shortener logged them correctly. Estimates of ad blocker adoption vary a lot by browser and region, so it is not worth quoting a single figure, but the direction is consistent: analytics tools that depend on client-side scripts will always undercount relative to a server-side redirect log.
Bot traffic works against you in the shortener's direction instead. Crawlers, uptime monitors, and security scanners that follow links automatically generate requests that look identical to a real click at the redirect layer, but never run JavaScript and never convert. A link tool that does not filter this traffic will always report a higher, noisier number than one that does. This is the reason to check whether your clicks are real before trusting a raw total for anything that involves money, like affiliate payouts or ad spend decisions.
Clicks vs sessions vs unique clicks
Even inside a single tool, the label on the number matters. "Clicks" usually means every recorded request, including the same person clicking twice. "Unique clicks" collapses repeat requests from the same visitor, typically using a cookie or a short time window, into one. A "session" in an analytics tool is a different thing again: it is a bundle of activity (multiple pageviews, time on site, bounce or not) tied together by that tool's own session logic, and different tools define a session's timeout differently, which is its own source of drift. The distinction between unique clicks and total clicks is worth reading in full if you are trying to reconcile a shortener's number against a sessions-based dashboard, because comparing a raw click count to a session count is comparing two different units, not the same metric measured twice.
If you are trying to answer "how many people actually visited," the honest move is to standardize on one tool's unique visitor definition and treat the others as directional. Don't average three tools together hoping to land on a true number. There isn't one sitting underneath them waiting to be triangulated. There are three different, correctly functioning measurements of three different events.
How to reconcile the numbers, in order
Work through these checks in this order. Each one rules out a specific cause before you move to the next.
- Check the time window first. If the shortener count runs high right after posting and the gap shrinks over the next hour, that's prefetching, not a real discrepancy. Re-check a day later before assuming anything is broken.
- Compare unique clicks across tools, not raw clicks. A raw click total will never match a sessions metric, so pull the unique or deduplicated number from each tool if it offers one.
- Load the destination page yourself in an incognito window with dev tools open and confirm the analytics script actually sends a request. If it doesn't fire reliably, no amount of link-side accuracy will make GA4 match.
- Look at the traffic source breakdown. If most of the gap sits in one referrer, Instagram's in-app browser is a common culprit: in-app browsers frequently strip the referrer header before the destination page ever sees it, which can also make legitimate traffic look like it arrived with no source at all.
- Once prefetching, bots, and blocked scripts are accounted for, expect a small residual gap between a redirect-layer tool and a script-layer tool. That's normal. Track the direction and size of the gap over time instead of chasing it to zero.
Broader questions about why analytics tools disagree in general, beyond links specifically, are covered in why analytics numbers never match, which is worth reading if the mismatch you are seeing spans more than just click counts.
Where Raydar fits
Raydar's link analytics sit at the redirect layer, the same layer your shortener occupies, so its count will naturally run closer to a raw click total than to a destination site's session count. It separates first-touch and last-touch attribution and applies bot filtering before showing you a total, which narrows the gap against ad platform numbers, but it does not and cannot see what a visitor does on your website after they land there. If you need the two numbers to line up exactly, that takes consistent tracking end to end, plus an honest read of what each tool was actually built to measure. No single dashboard is the one true source. Getting three tools to agree on one number was never really the goal. Knowing what each number counts, and what it can't see, is what turns a gap into information instead of a reason to panic every time you open a second dashboard.