How to Track Link Clicks: Methods, Metrics and Pitfalls

Counting clicks looks like the simplest measurement problem in marketing: something either happened or it did not. In practice, every number you see has been shaped by at least three decisions someone else made, about what counts as a click, which automated traffic was removed, and how long the data survives. Understanding those decisions is the difference between a dashboard you can act on and a chart you argue about in meetings.

This guide covers the four ways clicks are actually measured, what a single click event can and cannot reveal, the metrics worth watching, how bot filtering works, and the vendor limits that quietly determine what you are allowed to measure at all.

Four Ways to Count a Click

Redirect-side analytics

When a short link is clicked, the request hits a redirect engine before the browser goes anywhere. That engine sees the request in full and records it server-side, then answers with the redirect. Nothing depends on the destination page, on JavaScript, or on the visitor's cooperation.

This is the most complete method available for outbound links, and the only one that works when the destination is a site you do not control: an app store listing, a partner page, a client's website. It is also the only method that survives print, since a QR code scanned from a poster has no referrer and no session to attach to.

Its blind spot is everything after the redirect. It knows the click happened, not whether the page loaded or the purchase completed.

Campaign parameters plus web analytics

The complementary method. You tag destination URLs with campaign parameters, and the analytics platform on the destination attributes sessions and conversions to them. This is the only way to connect a click to revenue, and it is why the two methods belong together rather than in competition. The mechanics of naming and consistency are covered in our complete guide to UTM parameters, and the UTM builder enforces the naming rules that make the data joinable later.

The limitations are structural: it only works on destinations you control and can instrument, it loses everyone who leaves before the page finishes loading, and it is affected by blockers and privacy settings that vary by audience. Technical audiences suppress more of it than consumer audiences do.

Server logs

Every request to your own infrastructure is already recorded. Logs are exact, cannot be blocked, and are useful for verifying anything you doubt in another tool. They are also raw: no geolocation, no device parsing, no bot classification, and no interface. Treat them as an audit trail for reconciling disputed numbers rather than as a reporting system.

Pixels and client-side tags

A tracking pixel fires from the destination page, usually to build advertising audiences rather than to count clicks. Retargeting pixels attached to a link work slightly differently: an interstitial fires the pixel during the redirect so a visitor can be added to an audience even when you do not control the destination page. That is an audience-building mechanism, not a measurement one, and it should not be counted as click data.

| Method | Sees clicks to sites you do not own | Survives blockers | Sees conversions | Works for printed QR | | --- | --- | --- | --- | --- | | Redirect-side analytics | Yes | Yes | No | Yes | | Campaign parameters | No | Partly | Yes | Yes, if tagged | | Server logs | No | Yes | Indirectly | No | | Pixels and tags | No | Partly | Yes | No |

The practical answer for most teams is the first two together: redirect-side counting for reach and audience composition, campaign parameters for what happened next.

What a Single Click Actually Contains

At redirect time, before any page has loaded, the engine can record the moment of the click, the link and domain involved, the destination it routed to, the country, region and city derived from the network address, the device type, browser and operating system with versions parsed from the user agent, the referring domain when one is sent, the browser language, and any campaign parameters carried on the URL. Add the variant identifier when the link is running a split test.

City-level geography deserves a caveat that vendors rarely print: it is derived from network addresses, and it is accurate enough for regional patterns and wrong often enough that you should not build local campaigns on a handful of records. Mobile carriers and corporate networks routinely place a visitor a hundred kilometres from where they are.

What a click cannot contain is equally important. It does not identify a person. It does not tell you whether the destination page loaded, whether anything was read, or whether a purchase followed. And it says nothing about the same person's behaviour on another device. Every claim beyond the list above requires a second data source, which is exactly the job of campaign parameters.

The Metrics Worth Watching

Clicks versus unique visitors

Total clicks is a volume metric inflated by repeat taps, refreshes and multi-device users. Unique visitors is closer to reach, and how it is computed determines how much you should trust it.

The privacy-preserving approach, and the one LinkProfit uses, is to derive an identifier by hashing the network address, user agent and domain together with a salt that rotates daily, then store only the hash. The address is never written to the analytics store. The honest consequence of the rotating salt is that identity does not persist across days, so the correct label for the metric is unique visitors per day, and a monthly figure is the sum of daily uniques rather than a true count of distinct people. Any vendor reporting exact monthly uniques without cookies is either persisting an identifier for longer than they admit or estimating.

The scan-to-click relationship for QR

For printed campaigns, comparing scans against total clicks on the same link separates channels that share a destination. It is also the fastest way to detect a code that reproduced badly: a poster with thousands of impressions and a handful of scans usually means a contrast or size problem rather than an audience problem.

Decay curve

Most links do the majority of their work in the first hours, then decay on a predictable curve. Knowing the shape for your channels tells you when a campaign has finished rather than paused, and makes anomalies visible: a link that reactivates weeks later is usually being reshared, sometimes somewhere you would want to know about.

Referrer composition and the direct bucket

The referring domain shows where a link is being shared, which is often not where you published it. Expect a large direct bucket: messaging apps, email clients and apps that strip referrers all land there, and its size is a property of your channel mix rather than a problem to solve.

Bots, and Why Your First Hour Is a Lie

Automated traffic is not an edge case in link measurement. It is a significant fraction of the events in the minutes after publishing, and it comes in several flavours: security scanners that fetch every link in an email or message on delivery, social preview crawlers building cards, uptime monitors, search and SEO crawlers, and scanners looking for open redirects.

Filtering works on two signals. Network-level bot scoring classifies the request before it is served, and user agent heuristics catch the self-identifying crawlers. A correct implementation also handles two special cases: HEAD requests are served without counting a click, and a social preview crawler is answered with the page metadata rather than being routed and counted at all.

The design decision that matters is what happens to the filtered events. Deleting them makes anomalies invisible. Storing them and excluding them by default, with an option to include them, means you can investigate a suspicious spike instead of guessing. LinkProfit stores bot events with a flag and leaves them out of every default report.

Two habits protect you in practice. Treat any spike that begins before a human could plausibly have seen the link as automation until proven otherwise. And when a number looks wrong, compare it against the destination side: a large click count with almost no sessions is the classic signature of scanning traffic.

Privacy as a Design Constraint

Click tracking sits at exactly the point where measurement and personal data meet, and the architecture decides how much of a problem that is.

Not storing network addresses at all removes the most sensitive field from the system by construction, rather than by policy. Rotating the salt daily caps how long a derived identifier can be linked. Not setting a cross-site cookie for measurement avoids the mechanism most consent regimes were written about. And excluding visitor identifiers from API responses and exports keeps the derived value inside the aggregation layer rather than in a spreadsheet on someone's laptop.

This is a description of how the system is built, not legal advice: your consent obligations depend on your jurisdiction, your audience and what you do with the data afterwards. But a platform designed this way gives your legal review a much shorter list of questions to answer.

The Limits That Decide What You Can Measure

Two vendor limits govern the analytics you actually get: how many events are recorded, and how long they are kept. Both are usually further down the pricing page than the feature list.

| Vendor, as of August 2026 | Volume limit | Retention | | --- | --- | --- | | Rebrandly | Engagement data capped at 100, 10,000, 25,000 and 150,000 events per month by tier | Not published as a separate limit | | Short.io | 30 or more data points per click, no separate event cap | 26 months aggregated, 12 months raw clickstream | | Cutt.ly | Priced on links created rather than clicks | 30 to 730 days by plan | | BL.INK | Click limit per link, 7,500 to 60,000 | Not published | | Switchy | Click quotas by tier | Not published | | LinkProfit | 100,000 to 2,000,000 tracked clicks per month by plan | Up to 24 months, permanent per-link totals |

Rebrandly's model is the one to understand before signing anything, because it is the least intuitive: redirects are unlimited while the analytics are metered, so on the entry tier a link keeps working after 100 recorded events and simply stops reporting. If you are evaluating that trade-off, our Rebrandly alternative comparison lays out the tier-by-tier detail.

The principle generalises. Ask what happens at the ceiling rather than what the ceiling is. Redirects that keep working while measurement stops is a defensible design, provided you are told clearly; measurement that stops silently is how a quarter of campaign data disappears without anyone noticing until the review.

Pitfalls That Corrupt Otherwise Good Data

Redirect chains. Each additional hop is another opportunity to lose the referrer, drop campaign parameters, and add latency. Point links at final destinations and verify the chain when you inherit links from someone else.

Parameters lost in the redirect. If the destination strips or overwrites campaign parameters, the click is counted and the session is not attributed. Test one link end to end per campaign before launch; it takes a minute and catches the most expensive error in this article.

# The location header should carry every parameter you configured, in one hop
curl -sSI https://go.yourbrand.com/spring | grep -i -E 'HTTP/|location'

Comparing counts that were never comparable. Shortener clicks and analytics sessions measure different events. Track the ratio over time as a health signal, and stop trying to reconcile them exactly.

Timezone drift. Events are recorded in UTC while reports are rendered in a workspace timezone. Two people comparing daily numbers in different timezones will disagree forever unless the setting is explicit.

Counting previews and health checks. Preview crawlers and monitoring requests inflate counts on links that are checked frequently. Filtering handles most of it; if you monitor your own links, exempt the monitor.

Reusing slugs. Recycling a slug for a new campaign merges two histories permanently. Archive instead, and keep the old slug resolving.

A Setup That Holds Up

1. Publish every campaign through branded short links so redirect-side data exists for channels you do not control.
2. Tag every destination consistently, generated rather than hand-typed.
3. Keep the chain to one hop and verify it before publishing.
4. Leave bot filtering on by default and inspect excluded traffic when something looks unusual.
5. Label unique visitors as a daily metric wherever it appears in a report.
6. Check retention against the longest comparison you will want to make, not the current quarter.
7. Reconcile against the destination side once per campaign, and investigate large gaps rather than averaging them away.
8. Export or query the raw data through the API when the dashboard cannot answer the question.

Most measurement problems in this space are not analytical, they are plumbing: a lost parameter, an extra hop, an unfiltered scanner, a retention window shorter than the question. Fix the plumbing and the numbers become boring, which is what you want from them.

LinkProfit records more than a dozen dimensions per click, filters automated traffic by default, derives unique visitors without storing network addresses, and keeps data for up to 24 months while per-link totals never reset. See analytics for the full dashboard, or check any link with a public statistics page using the free click counter.