# Link Tracking Guide: Clicks vs Visitors vs Sessions vs Conversions > Clicks, visitors, sessions, and conversions measure different layers and never quite agree. Learn what each means and what to act on instead. - **Author**: George Borelli - **Published**: 2026-08-15 - **Category**: Marketing - **URL**: https://heyzinc.com/blog/link-tracking-guide --- ```tldr Clicks, visitors, sessions, and conversions are four measurements taken at four different layers, so they never quite agree. Clicks can be inflated by preview bots, visitors are probabilistic, sessions time out and get estimated, and a conversion is only as trustworthy as the event you defined. The one signal you can act on while it matters is the active-now state -- a visitor on your site right now -- which none of the four retrospective metrics captures. ``` You share a link in a Reddit reply. You send one in a cold email. You drop another into a DM after a call. Then you open your dashboard. The link tracker says twelve clicks. Your analytics says seven sessions. Your CRM says one conversion. Three tools, three numbers, same link. Most founders do what I did for a long time: pick the number that feels right, ignore the rest, and move on. That works until you start making decisions on it. Then the gap between those numbers starts to matter, because each one measures something different, and each one breaks in its own way. This is a guide to the four numbers you see when you track a link -- clicks, unique visitors, sessions, and conversions -- plus the supporting cast that decides whether those numbers are usable: preview bots, redirects, attribution windows, and the present-tense signal none of those four capture. ## Clicks: what gets counted when a link is requested A click is a server-side hit recorded when a tracked link is requested. That is the precise definition. Notice what it does not say: it does not say a human arrived. It says a request hit the redirect. That matters because a click is the loosest of the four numbers, and it inflates in two directions. First, it overcounts. When you paste a link into Slack, iMessage, an email, or a social reply, the receiving app often fetches the URL to render a preview card. That fetch is a server-side request, and a redirect-based tracker can record it as a click even though no human touched anything. Apple runs a crawler called Applebot that fetches URLs to power Safari, Spotlight, and Siri previews, and it advertises an identifiable user-agent -- but plenty of preview fetches are quieter. Whether a preview shows up as a click depends on your tracker's bot filtering and the client doing the fetching, so treat this as a measurement limitation, not a universal rule. The point is: a "click" can be a machine reading your URL to draw a card. Second, it undercounts. Google's own guidance on the gap between ad clicks and analytics [sessions](https://support.google.com/analytics/answer/14452452) points out that if someone clicks an ad or link and closes the tab before the destination page's tracking tag loads, you get a click and no session. The click happened. The visit, in analytics terms, did not. So a click count is a request count. It is a leading indicator, not an arrival count. If you want the mechanic behind a tracked link's token and the server-side context it carries, the [tracked links versus UTM parameters](https://heyzinc.com/blog/tracked-links-versus-utm-parameters) deep dive covers it. Here, the point is narrower: a click is the first, loosest layer. ## Unique visitors: a probabilistic headcount A unique visitor is not a headcount of humans. It is a count of distinct identities your tool managed to recognize over a window, and it depends entirely on a surviving identifier -- a first-party cookie, a tracked-link token, or an authenticated session. Google Analytics does not even ship one "visitor" number. It has [four user metrics](https://support.google.com/analytics/answer/12253918): total users, active users, new users, and returning users, and only active users appear in standard reports. An active user is one who had an engaged session or fired a first-visit or engagement-time signal. So when a tool says "unique visitors," it is already picking one of several definitions. The deeper problem is that the identifier is fragile. Cookies get evicted. Private browsing modes strip tracking parameters and add noise to fingerprintable signals, as WebKit documents for Safari's tracking prevention. The same human opening your site on their phone and their laptop can count as two visitors. Two people sharing a machine can count as one. The honest read: a unique-visitors figure is a lower bound on humans when privacy configs are hostile, and an overcount when devices are shared. It is a useful approximation, not a census. Treat it as "recognized identities," not "people." ## Sessions: the grouped visit that times out A session is a grouped period of interaction. In GA4, a session starts when someone views a page or screen and no session is already active, and it times out after thirty minutes of inactivity by default. There is no upper limit on how long a session can last. This is where clicks and sessions visibly diverge, and Google documents the reasons directly. If a user clicks your link twice within thirty minutes without closing their browser, analytics may register one session, but the ad or link platform counts two clicks. If a user returns to your site directly during the lifetime of a campaign, that is a new session attributed to the last-known campaign -- a session with no matching click. If someone bookmarks a URL that still carries a tracking parameter, every visit from that bookmark is a session without a click. There is also a quiet detail: GA4 counts [sessions](https://support.google.com/analytics/answer/9191807) by estimating the number of unique session IDs, using an approximation algorithm called HyperLogLog++ since October 2021. The UI number can differ slightly from an exact count in BigQuery. In other words, even the session count is an estimate, not a tally. On top of the raw session there is the engaged session -- one that lasted ten seconds or more, or had a conversion, or had two or more page views. That is the quality filter. A session and an engaged session are not the same number, and the engaged one is usually the more honest reflection of attention. ## Conversions: an event you defined, credited by a window A conversion is a key event you configured. A signup, a purchase, a booked call. It is not an objective category of human behavior; it is a line you drew in your analytics. That means a conversion is only as trustworthy as the event definition and the path that credited it. Two things make conversions slippery. The first is the attribution window. GA4 credits a conversion within a lookback window -- ninety days by default for key events -- and uses non-direct last click for session attribution. Other tools use other windows. So the same purchase can be credited to the cold email in one dashboard, to the community reply in another, and to "direct" in a third, all on the same day, because each tool looked back a different distance and applied a different rule. The second is causality. A click did not necessarily cause the conversion, and the last click before a conversion did not necessarily earn it. A prospect is often touched by several messages across channels before they convert. For the full path from a single message to a customer -- and the limit that a click does not prove causal lift -- [tracking which message generated a customer](https://heyzinc.com/blog/track-message-generated-customer) covers it. The measurement point here is simpler: pick one attribution model, define your conversions narrowly, and stop expecting cross-tool conversion counts to agree. A practical discipline: define the conversion event as the actual committed action, not an intermediate step. A "signup" that fires when someone merely opens the form is not a conversion; it is a pageview wearing a costume. The narrower the event, the more honest the count. ## Why the numbers never agree Put the four together and the disagreement is structural, not a bug. Clicks count requests. Visitors count recognized identities. Sessions count grouped interactions. Conversions count defined events credited by a window. They live at four different layers, so they are supposed to differ. The redirect makes it worse. A tracked link is usually a redirect, and redirects strip parameters before the destination can read them. Google's troubleshooting guidance notes that a landing-page redirect can drop the GCLID or UTM parameters before the analytics tag identifies the traffic source -- and once those are gone, the visit collapses into the bucket Google calls ["(direct) / (none)"](https://support.google.com/analytics/answer/15258820). URL shorteners and ad blockers do the same thing. The result is that a chunk of your tracked traffic shows up as direct, with no source, in your analytics. The referrer does not save you. The web's default [referrer policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy) sends only the origin -- not the path or query string -- for cross-origin requests, and some configurations suppress the referrer entirely. So even when a visit is attributed, "referrer" is origin-level at best, and it tells you "reddit.com," not "the specific thread where you answered a question." This is why [direct traffic hides your best marketing channels](https://heyzinc.com/blog/why-direct-traffic-hides-best-marketing-channels), and why a lot of teams end up relying on a first-party tracked-link token rather than referrer data. The lesson is not that these tools are broken. It is that they answer different questions, and the redirect-and-privacy layer between them loses information in transit. ## Active now: the one signal you can act on Every metric above is retrospective. None of them tells you a visitor is on your site right now. The active-now state is a different kind of signal -- present-tense, per-visitor -- and it is the only one you can act on while it still matters. Engagement is only possible while the visitor is still there. Once the tab closes, the conversation moves from "right now" to "follow up later," and follow-up is a much weaker position. A click report tells you the visit happened. An active-now signal tells you it is happening. This is where the layers connect. A HeyZinc tracked link records the click and the source conversation server-side -- which reply, which post, which DM created the visit. When the visitor lands, the dashboard can flag them as active-now, and a companion or mobile alert can notify the team. A teammate can then continue by text or a live website call. Treat all of that as a vendor capability, configuration-dependent, not a universal guarantee -- the active-now state and mobile alerts depend on your workspace setup and device. The point is not to interrupt every visitor. The point is to make the moment visible when the context is still useful, so you can decide whether to start a conversation. By default, bot and scraper traffic is filtered out of visitor notifications, so the active-now signal is not polluted by crawlers hitting your links. For the full real-time signal picture -- page flow, repeat visits, geo, device -- [real-time visitor tracking](https://heyzinc.com/blog/real-time-visitor-tracking) is the deeper read. ## What link tracking can't tell you It is worth being explicit about the limits, because the category attracts overclaim. A click is not an identity. A tracked link attributes a visit to a conversation or a source, not to a named person, unless the visitor identifies themselves. Keep three things distinct: who the visitor is (identity), what they are doing right now (behavioral intent), and which conversation brought them (attribution context). Conflating them is how you end up pretending to know more than the data proves. If you want the identity layer, that is a separate problem -- [how to identify website visitors](https://heyzinc.com/blog/identify-website-visitors) covers it. A click does not prove a conversion. Conversation-level conversion claims need attributable internal data or a controlled result. Seeing a visit and seeing a conversion is not the same as proving the visit caused the conversion. No link format is immune to privacy tooling. A custom first-party token is a narrower target than known advertising parameters, so it is less likely to be stripped by rules aimed at UTMs -- but a determined privacy tool can still remove, rewrite, or block any tracking. The accurate claim is "less exposed," not "invisible." And the live signals are configuration-dependent. Active-now and mobile alerts depend on your workspace and device setup, not a universal delivery guarantee. ## From a click to a conversation Measurement literacy is the prerequisite. The payoff is acting while the visitor is still on your site. The four numbers are worth understanding precisely because they disagree -- each one tells you something the others do not, and each one breaks in a way you can predict once you know which layer it lives at. But none of them, on their own, hands you a conversation. They hand you a record. HeyZinc connects the record to the moment: a tracked link remembers the source conversation, the dashboard shows the live visit, and a teammate can pick it up by text or a website call while the intent is still warm. If you want the full mechanic -- the token, the server-side context, the dashboard -- the [tracked links versus UTM parameters](https://heyzinc.com/blog/tracked-links-versus-utm-parameters) post is the deep dive. If you want to try it on your own outreach, HeyZinc is [here](https://heyzinc.com). ## Sources The analytics definitions and discrepancy explanations are based on Google's guidance on [Analytics sessions](https://support.google.com/analytics/answer/9191807), [user metrics](https://support.google.com/analytics/answer/12253918), the [clicks and sessions discrepancy](https://support.google.com/analytics/answer/14452452), and [(direct)/(none) traffic](https://support.google.com/analytics/answer/15258820). Referrer behavior is from [MDN's Referrer-Policy documentation](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy). Crawler and preview-fetch behavior is from Apple's [About Applebot](https://support.apple.com/en-us/119829). --- - [More Marketing articles](https://heyzinc.com/blog/category/marketing) - [All articles](https://heyzinc.com/blog)