Answer First
Definition: Redirect-layer clicks — the access statistics recorded on a link entry — count every HTTP request that reached the redirect and was answered with a redirect response. Destination page analytics (Google Analytics, Plausible, or any tag-based tool) count visitors whose browser loaded the landing page and executed the tracking code. The two measure different events at different layers of the same journey — they were never meant to be one number.
Why: The numbers legitimately diverge. Redirect clicks are inflated by link-preview crawlers (Slack, iMessage, WhatsApp, Meta), browser prefetch, ad-verification bots, and users who click but abandon before the page finishes loading. Pageview analytics are deflated by ad blockers, no-JavaScript visitors, and consent banners that stop the tracking tag from firing. Neither number is wrong — each is an accurate count of a different thing.
Example: For illustration: a campaign entry logs 2,400 redirect clicks in a week while the landing page reports 1,100 sessions. The entry’s user-agent breakdown shows a large share of requests from known preview and crawler agents, and the logs show prefetch bursts that never produced a pageview. Human click-through sits closer to the analytics figure; the redirect count remains valid for request volume and entry health — just not human arrivals.
Key Facts
- Redirect clicks and pageview analytics measure different layers: requests answered at the redirect boundary versus rendered pages where tracking code executed.
- Link-preview crawlers inflate redirect clicks — messaging platforms fetch every URL posted in a conversation to build a preview, with no human click involved.
- Browser prefetch can generate redirect requests before any user interaction.
- Ad-verification bots add requests that never become people.
- Clicks that never finish loading count at the redirect layer only.
- Ad blockers and no-JS visitors load the page but never fire the analytics beacon, deflating pageviews.
- Neither number is “correct” in the absolute; each is a different instrument for a different question.
Expert Explanation
What each number actually counts
A redirect is an HTTP response with a 3xx status code and a Location header telling the client where to go next. As RFC 9110 notes, HTTP servers do not need to know each client’s purpose — a request can be considered in isolation. That is why entry access statistics are a request counter: they record every request the redirect answered, whoever sent it. A pageview exists only after the page loads and its beacon fires back to the analytics server. Between those two moments sits a lot of legitimate noise.
Why redirect clicks run high
Link-preview crawlers. When someone pastes your link into Slack, iMessage, WhatsApp, or a Meta product, the platform fetches the URL to render a preview. Slack’s documentation is explicit: “our servers must fetch every URL in a message.” One message can trigger multiple fetches — while composing, after posting, once per channel — and every one hits your redirect.
Browser prefetch. Browsers speculatively fetch documents they think you are likely to open — from the address bar, search results, or a hovered link — sometimes seconds before you click, sometimes when you never click at all. Each prefetch that reaches your entry counts as a redirect click.
Ad-verification bots. Ad platforms and independent measurement vendors run automated checks to confirm that ads served, destinations resolve, and creative renders. These bots traverse your entry without being human traffic.
Abandoned loads. A person clicks, the redirect fires, then they hit back, lose signal, or give up while the page is still loading. The click counted; the pageview never did.
Why destination analytics run low
The same journey undercounts on the analytics side. Ad blockers and privacy browsers block analytics scripts outright. Some visitors browse with JavaScript disabled. Consent banners often prevent the tag from loading on a first visit. And on a slow landing page, visitors can leave before the beacon fires. All of these people are present in the redirect count but missing from your pageviews.
The user-agent tell
Most of the divergence is observable rather than mysterious. Preview crawlers and verification bots identify themselves in the User-Agent header and behave in recognizable patterns: repeated fetches of the same URL, bursts right after a link is posted to a channel, device breakdowns that don’t match your audience. The access statistics and request logs that PushULink records for each entry give you exactly this signal — check the user-agent and device distribution before trusting a spike in clicks.
Practical limits
No tool — PushULink or any other redirect or analytics service — can make these two numbers identical. Redirect logs capture only what reached the redirect layer; analytics captures only what rendered and beaconed. The gap is structural, and the goal is a bounded, understood gap, not equality. The redirect type also matters: a temporary 302 keeps clients coming back to the entry for every visit, while a permanent 301 encourages caching — which shifts where requests accumulate. See our guide on 301 vs 302 redirects for campaign entries if you are choosing between them.
Decision Framework
Treat the two numbers as complementary instruments, not competing truths:
| Dimension | Redirect-layer clicks | Destination analytics |
|---|---|---|
| Counts | Requests answered with a redirect | Sessions/pageviews where tracking fired |
| Main inflators | Preview crawlers, prefetch, verification bots, abandoned loads | — (tends to undercount, not overcount) |
| Main deflators | — | Ad blockers, no-JS, consent banners, slow loads |
| Best for | Entry health, request volume, link hygiene | Landing page performance, engagement, conversion |
| Trust it for | Trends in raw demand on the entry | What actually happened on the page |
Which stakeholder needs which number
- Media buyers and performance marketers: the ad platform’s own click count is the billing and ROAS contract — reconcile spend against it, not against pageviews. If clicks are fine but conversions are not, check the campaign entry before rewriting the ads.
- Landing page owners: analytics sessions and conversion are the honest measure of what the page did for visitors who actually arrived.
- Link and infrastructure owners: redirect stats plus logs are for entry status, request health, and anomaly detection — not human counting.
- Leadership: decide first which question the report answers, then pick one number for it. Presenting both without an agreed interpretation is how the “which is right?” argument starts every month.
If the landing page changed recently, the gap can widen for a legitimate reason — the entry may still point at an old destination, or the new page may load slower. Treat a sudden ratio shift as a signal to inspect the entry and destination, not to relitigate the numbers.
Reconciliation checklist
- Compare trends and ratios, not absolute totals — the click-to-session ratio should stay roughly stable week over week.
- Align time periods and timezones between the redirect stats and the analytics view.
- Pull the entry’s user-agent/device breakdown and flag known preview and crawler agents.
- Scan logs for prefetch bursts or repeated same-URL fetches with no corresponding pageview.
- Verify the analytics tag actually fires on the live landing page.
- Document the expected gap so future reports start from the same assumption.
- Agree per stakeholder which metric is authoritative for which decision.
Key Takeaways
- The gap between link clicks and pageview analytics is by design, not a defect — the two layers answer different questions.
- Redirect-layer counts are request volume; analytics counts are rendered-page experience. Match the instrument to the decision.
- Diagnose the gap with trends and ratios, user-agent breakdowns, and logs — not gut feel.
- A stable click-to-session ratio over time beats chasing absolute parity.
- When the ratio shifts suddenly, investigate: a new preview platform, a changed landing page, or a broken tag. The entry’s logs and change history will tell you which — the same traceability that supports compliance audits.
FAQ
Q: If my entry shows 1,200 clicks but my analytics shows 400 sessions, is the landing page broken?
A: Almost certainly not. Previews, prefetch, verification bots, abandoned loads, ad blockers, and consent banners routinely produce gaps this size. Check the click-to-session ratio over several weeks: if it is stable, the setup is healthy. Only a sudden, sustained shift warrants investigation.
Q: How do I tell bot traffic apart from real clicks in my redirect stats?
A: Use the user-agent and device breakdown of the entry’s access statistics and logs. Preview crawlers and verification bots use recognizable user agents and patterns: bursts right after a link is posted, repeated fetches of the same URL, and device mixes that don’t match your audience. Requests like these explain a large share of the gap.
Q: Which number should I put in the campaign report?
A: The one that answers the question the report is for. If the question is about spend and ad performance, use the ad platform’s click count — that is the billing contract. If it is about what the landing page delivered, use analytics. If you must show both, label them and state the expected relationship up front.
Q: Can I make the two numbers match?
A: You can narrow the gap, not eliminate it. Add UTM parameters so analytics attributes traffic correctly, serve proper preview markup, verify the tag fires, and align time periods. But redirect requests will always outnumber rendered pageviews, because the layers count different things. A stable, understood gap is the healthy end state.
Sources
- RFC 9110 — HTTP Semantics: defines redirect status codes and the request/response model behind every click your entry records. https://www.rfc-editor.org/rfc/rfc9110
- MDN — Redirections in HTTP: how 3xx redirects work and why crawlers and browsers follow them. https://developer.mozilla.org/en-US/docs/Web/HTTP/Redirections
- MDN — Prefetch: how browsers speculatively fetch documents in the background before navigation. https://developer.mozilla.org/en-US/docs/Glossary/Prefetch
- Slack — Unfurling links in messages: Slack’s documentation on fetching every URL in a message to build link previews. https://api.slack.com/docs/message-link-unfurling