Answer First
Definition: An email link click tracking discrepancy is the gap between the click count your email platform reports for a campaign and the click count your link-level or landing-page analytics record for the same link. It is usually not a sign that tracking is broken. The difference is dominated by automated requests: email security scanners, mail gateways, and client prefetching generate hits that look like clicks before any person opens the message.
Why: Email platforms and link-level analytics count different things. An email platform usually registers a “click” when its own tracking domain receives a redirect request — that is, whenever something, human or not, follows the link it rewrote. Your forwarding entry’s access log counts every request that reaches your branded subdomain, automated or not. Because scanners and prefetching fire requests without a human click, the email-side number is typically larger than the link-side number — and both are larger than the true human-click count.
Example: You send a campaign whose call-to-action is go.yourbrand.com/spring-sale, wrapped by your email platform’s tracking link. The platform reports 340 clicks. Your link-level analytics, from the forwarding entry’s access statistics, show 210 requests. A quick look at the logs explains part of the gap: a burst of requests in the first minutes after send from addresses that identify themselves as security products, plus a few prefetch requests that completed a GET but were followed by no page view. None of those involved a human.
Key Facts
- Email click counts are request counts, not human counts. Any client — a scanner, a cache, a prefetch engine — that follows the tracking redirect increments the counter.
- Security scanning is the usual inflation source. Corporate gateways such as Microsoft Defender for Office 365 wrap links (the familiar safelinks.protection.outlook.com prefix) and can check them at delivery and again at time of click; consumer providers like Gmail run URL reputation checks on inbound mail. Those checks are real HTTP requests to your domain.
- Prefetch happens before anyone clicks. Browsers and clients preload URLs based on heuristics or explicit hints (link rel=“prefetch”, prerendering, speculation rules), producing requests with no navigation behind them.
- Scanner hits leave signatures: bot-like or empty user agents, unusual referrers, same-second bursts, HEAD requests, and repeat hits from one IP.
- A gap of email clicks above link clicks is expected and permanent. The reverse — more link hits than email clicks — is also common when recipients forward messages or copy the raw link.
Expert Explanation
Where the email click count comes from. Most email platforms do not track the destination; they rewrite every URL to point at their own tracking domain and count a click when that domain receives a request and issues an HTTP redirect. This is efficient but blunt: a redirect is a machine-readable instruction any HTTP client can follow (RFC 9110 defines GET semantics; MDN documents how 301 and 302 responses work). The platform cannot see who or what followed it.
Who else is asking for your link. Three categories of automated traffic hit campaign links:
- Delivery-time scanning. Mail security checks URLs before or as messages land. Safe Links, for example, scans incoming mail and can rewrite or wrap links with a safelinks.protection.outlook.com prefix, and may hold the message until URL checks complete. Similar reputation checks run in consumer mailboxes. Any check that fetches the URL is a request in your logs.
- Time-of-click verification. Wrapped links are re-checked when clicked — Safe Links immediately checks the URL before opening the website. A single human click can therefore produce several requests: one through the email platform, one through the wrapper, one at your entry, and one at the landing page.
- Prefetch. Browsers and clients prefetch and prerender resources they predict will be needed, before the user navigates. Prefetch requests are ordinary GETs — they appear in your logs like any other visit, sometimes with a Sec-Purpose: prefetch header.
Why it shows up in your forwarding logs. Your branded entry sits in the middle of this chain. Every hop — email tracking domain, Safe Links wrapper, your entry, landing page — records a request. The email platform counts the first hop; your access log counts the requests that reach your entry. Scanner and prefetch requests reach your entry too, so your log contains “clicks” nobody made.
How to recognize scanner hits in access logs
| Signal | Scanner / prefetch hit | Human click |
|---|---|---|
| User-Agent | Empty, generic, or security/bot product strings; mail-protection domains | Standard browser strings (Chrome, Safari, mail-client preview engines) |
| Referer | Absent, or a scanner/wrapper domain | Your email platform, landing page, or none |
| Timing | Same-second bursts; spikes within minutes of send; repeated identical requests | Spread over hours or days; one or a few hits per visitor |
| Method | HEAD requests; GETs not followed by landing-page activity | GET followed by page asset requests |
| Volume | Same entry hit many times from one IP | Typically one hit per IP per session |
These are probabilistic signals, not proof. A human on a shared office IP or with privacy extensions can match several “scanner” traits, and a scanner can look human. Use the table to triage, not to pass judgment per request. Because redirect status changes caching behavior — and cached redirects change how often your entry is hit — our guide to 301 vs 302 for campaign entries is worth reading before you change anything.
Decision Framework
A checklist for comparing email clicks against link-level statistics:
- Define what each number means before comparing. Email platform clicks are redirect requests through its tracking domain. Link-level clicks are requests to your entry. Write both definitions down.
- Use the same measurement window. Pull your access statistics for the same send date, and give the window a full day after it closes before drawing conclusions.
- Verify the entry itself first. Check the entry’s status and that the redirect does what you configured — a misconfigured entry creates its own discrepancy. Our article on ads that get clicks but no conversions warns against rewriting anything before you check the campaign entry; the same instinct applies here.
- Pull the logs and scan for automation using the table above. Expect scanner bursts and prefetch hits, not a bug.
- Only then attribute residual differences to creative, audience, or landing-page changes — and remember the destination may have changed mid-campaign, which itself distorts comparisons.
- Report ranges, not false precision. “Between 210 and 340 tracked clicks, with automation likely near the top of that range” is honest. “340 human clicks” is not.
Practical limits. You cannot derive an exact human-click count from HTTP logs alone. IP-based deduplication is unreliable (NAT, shared addresses, VPNs); scanner behavior changes without notice; and some platforms expose no raw logs at all. Both sides of the comparison can also undercount: mail clients that block tracking pixels reduce email-side click events, and landing-page analytics that count only JavaScript-enabled sessions miss some visits. Treat the email platform number as an upper bound, your link logs as a second view of the same traffic, and accept that the truth sits between them.
Key Takeaways
- An email link click tracking discrepancy is expected behavior, not broken tracking: automated scanners and prefetch generate requests that outnumber human clicks.
- Email platforms and link-level analytics count different requests at different hops; they will rarely agree, and that is fine.
- Scanner hits are recognizable — user agents, referrers, request methods, and timing bursts let you triage your access logs.
- Compare like for like: same window, defined counting rules, entry status verified — and report a range.
- Keep campaign entry links stable and choose your redirect status deliberately, because caching and scanners interact with both.
- Your logs are evidence. Because every change to a forwarding entry is traceable, your audit trail can show what a link pointed at when each request arrived — useful for campaign reviews and for compliance audits.
FAQ
Q: Why does my email platform report more clicks than my link logs?
A: The two systems count different requests. Your email platform counts redirect requests through its tracking domain; your link-level logs count requests that reach your forwarding entry. Both include automated traffic — security scanners, mail gateways, and prefetching — that fires without a human click, so the email-side number is usually larger. The tracking is working; the counting definitions differ.
Q: How can I tell scanner or prefetch hits from real clicks in my access logs?
A: Combine signals: user agent (empty, generic, or security-product strings), referer (absent or a wrapper domain), request method (HEAD, or GETs not followed by page views), and timing (same-second bursts or spikes right after send). No single signal is proof, but when several line up, automation is the likely explanation.
Q: Do scanners actually fetch my campaign links before anyone opens the message?
A: Yes. Mail security products check URLs at delivery — Safe Links, for instance, scans inbound mail and can wrap links with a safelinks.protection.outlook.com prefix — and some clients prefetch URLs in the background. Any of these produces a real HTTP request to your entry, logged as if it were a click.
Q: Can I get an exact human click count?
A: Not from HTTP logs alone. You can filter obvious automation, deduplicate cautiously, and report a defensible range, but no log-based method separates humans from machines with certainty. Document your methodology, use consistent windows, and treat every reported number as an approximation — including your email platform’s.
Sources
- RFC 9110 — HTTP Semantics (IETF): GET semantics, safe methods, and the User-Agent header field.
- Redirections in HTTP — MDN Web Docs: how 301/302 redirects work and why each redirect hop costs a request.
- Safe Links in Microsoft Defender for Office 365 — Microsoft Learn: URL rewriting/wrapping and time-of-click scanning.
- Speculative loading — MDN Web Docs: prefetch, prerender, and preconnect generate requests before navigation.