How to track who clicks your short link

To track who clicks your short link, the honest answer is: you can see when the click happened, the country it came from, the device and browser it ran on, and the source it was shared from — and you can tie a click to a specific person only when you set it up that way before the click happens. A redirect on its own does not produce a name. Anyone telling you otherwise is selling something they cannot ship.

This post walks the actual data a short-link redirect captures per click, the three legitimate ways to bridge the gap from anonymous click to known person, and the privacy boundary that turns "useful campaign measurement" into "the thing that gets you fined". By the end you'll have a realistic picture of what's trackable, what isn't, and the specific moves that turn a click log into an attribution chain you can decide from.

What a short link click actually records#

Every short-link redirect — your own, Bitly's, Rebrandly's, anyone's — captures the same small set of fields the moment the click lands on the server. The redirect doesn't pull a name out of thin air; it reads what the browser hands over in the HTTP request, derives a few useful things from those headers, and writes one row.

The row looks roughly like this:

• timestamp — when the click hit the redirect, to the millisecond.
• slug — which short link was clicked (/m/spring-sale, not the long destination).
• referrer — the page the user was on before they clicked, when the browser hands it over. Most social apps and email clients now strip this; expect it to be missing on 40-60% of clicks.
• user-agent — a long string that identifies the browser, version, OS, and rough device class (phone, tablet, desktop).
• IP address — the network address of the request, used (and immediately discarded by privacy-aware tools) to derive country and approximate region.
• UTM parameters — utm_source, utm_medium, utm_campaign (and optionally utm_content, utm_term) parsed off the destination URL.
• accept-language — the browser's preferred language, useful for routing but rarely an identifier on its own.

From that row, the redirect derives the user-facing fields you'll see in any dashboard: country, region, city (rough), device class, browser, OS, referrer host, and the four UTM dimensions. The full guide to those derived fields and how each one shows up in a dashboard lives in the click analytics docs. The primer on how to track QR code scans covers the same row structure for the scan side — the data model is identical because a scan is just a click that started with a camera.

What clicks don't tell you, by default#

The honest part of the answer is the part most tools hide.

You don't get a name. A click has no name field. No "first_name", no "email", no "customer_id". Those don't exist in HTTP. If a vendor's dashboard shows you a name attached to a click, ask them where they got it — they pulled it from a join on something else (a logged-in session, a per-recipient slug, a cross-site tracker), and that join either happened with consent or it shouldn't have happened at all.

You don't get a reliable identity from IP alone. An IP address tells you which network the click came from. For a residential broadband connection that maps to a household, sometimes a single person, sometimes a router shared by ten people. For a mobile carrier it maps to whichever pool of users that carrier rotated through that IP in the last hour. For a corporate or VPN connection it maps to a building or a country. Country is reliable. City is rough. "This specific human" is not in the bag.

You don't see the same person twice unless you can join clicks. Without a session cookie or a logged-in user record on the destination, two clicks from the same person on different days look like two strangers to the redirect log. The dashboard's "unique visitors" count is a best-effort dedupe on ip + user-agent + day, which is good enough for trend lines and wrong enough that you shouldn't use it for billing.

You don't beat the bots without filtering. Corporate email security gateways pre-fetch every link in every message. iMessage and Slack preview links before the user taps. Some browsers prefetch hovered links. Raw click count includes all of that. The short link not tracking clicks debug guide walks the eight specific places where counts get inflated or undercounted; treat the headline number with that lens.

You don't see what the destination platform sees. A short-link click and the action it produces on the destination are two different events. The clearest case is video — a click to YouTube tells you the redirect fired, never whether the watcher played the video, much less finished it. The analytics-gap walkthrough for QR codes pointing at video covers why a "scan-to-watch" campaign that only counts scans is reading half the funnel and what to pair the click log with to close the gap.

The three legitimate ways to link click → person#

To turn a click into a known person, you need an identifier that's attached to the click before it happens or recovered after it lands. There are three honest patterns. Pick the one that fits the channel; don't try to fake the others.

1. Per-recipient UTMs in newsletters#

This is the highest-trust pattern for email campaigns. Each recipient gets the same short link, but the long URL it forwards to carries a utm_content (or a custom subscriber_id parameter) that's unique to that recipient. Your email tool already knows who's on the send list — it just has to write the right identifier into each version.

https://yourdomain.com/m/may-promo
   → redirects to → https://you.com/lp?utm_source=newsletter&utm_medium=email
                       &utm_campaign=may-promo&utm_content=sub_4912

When the click lands on the destination, your analytics tool reads utm_content=sub_4912 and joins it to the subscriber record. Now the click is tied to a specific person — by their consent (they're on your list) and through a transparent, named identifier. The UTM parameters that actually matter for short links post covers the naming patterns that hold up across multi-channel sends, and the broader privacy boundary on this pattern lives in tracking links in email — what you can know.

The trade-off: per-recipient identifiers in URLs are visible if anyone inspects the link. Most recipients don't, but you should disclose the practice in your privacy policy honestly — "we tag clicks per subscriber to measure engagement" — and not bury it in "industry-standard analytics" language.

2. Authenticated landing pages#

The cleanest identity-capture path is the one that happens after the click. The short link redirects to a page on your own site behind a login. If the visitor is signed in, the page knows who they are from the session cookie, and your tracker (server-side or first-party JS) records the click → user_id join on the landing-page side, not on the redirect side. The redirect log is still anonymous; the join lives where consent has already been given.

This works perfectly for transactional emails (password resets, receipts, magic links, in-app deep links), in-app referral campaigns, and any flow where the recipient is already a user of yours. It does not work for cold outreach, ads to non-customers, or print-to-stranger flows — because the visitor never signs in.

3. Explicit form completion#

When neither of the above fits — the recipient isn't on your list, isn't signed in, and the channel is a public ad or a print surface — the only honest way to learn who clicked is to ask. The short link sends them to a landing page with a form, the form ties the answer to the source they came from, and now you have a name plus the context.

The UTM bundle gives you the upstream half (which campaign, which channel, which placement). The form gives you the downstream half (who they are, what they want). The two get stapled together in your CRM as one record. The conversion tracking with QR codes and short links walkthrough covers the full pipe from print surface through to a row in the CRM that says "yes, this person filled the form, and it started on the spring magazine ad".

A short link doesn't know who's clicking. It knows what it was told before the send.

The click-trackability scorer#

Plug your real setup into the widget below. It estimates what fraction of clicks you can realistically tie back to a known person, what fraction stays aggregate-only, and the single biggest fix for the gap. The numbers are conservative — pulled from the public attribution research below — and they update as you change the inputs.

The number at the top is the realistic ceiling for your setup. The most common pattern — newsletter to a non-authed landing page with no per-recipient identifier — sits around 15%, because the only thing tying clicks to people is whichever fraction of subscribers re-authenticate after they land. Add a utm_content=sub_id and a form, and that ceiling jumps to 70%+ without crossing any privacy lines. Almost every operator who runs the scorer once realises the gap is closeable in an afternoon.

The GDPR and PII reality#

A short paragraph the SEO-listicle versions usually skip: under EU and UK data protection law, IP addresses count as personal data when they can identify a natural person, and per-recipient identifiers in URLs are personal data full stop. The 2016 Breyer ruling at the Court of Justice of the European Union set the precedent that dynamic IPs are PII when held by anyone who can combine them with other data to identify the user. Most short-link platforms can — they have the IP and the click record, and a court order can join those to whatever authentication log lives elsewhere.

What that means in practice:

• Logging IP is lawful with a basis. "Legitimate interest" with disclosure (your privacy policy says you log clicks for analytics) covers most aggregate measurement. "Consent" is the higher bar for per-person joins.
• Retain the derived fields, not the raw IP. Country and region derived from the IP at the moment of redirect, then drop the raw IP. The Article 29 Working Party guidance and follow-on EDPB opinions all converge on this pattern: minimum necessary, time-bounded, justified.
• Per-recipient identifiers need disclosure. A unique slug per subscriber is fine when your privacy policy says "we attach an identifier to your links so we can measure which campaigns earn the most engagement". It is not fine when you describe it as "industry-standard analytics" and bury the practice.
• California (CCPA / CPRA) and most US state laws are softer than GDPR but converge on "tell people what you do, let them opt out, don't sell the data". Click logs that stay on your own systems and feed your own marketing are usually fine. Selling them to data brokers is not.

The honest framing: most operators are not creepy because they want to be — they're creepy because they used a tool whose defaults include open pixels, third-party trackers, and raw IP retention, and they never opened the privacy section. The fix is to pick a tool that stores derived fields by default and to write a privacy policy that names what you actually do. The privacy boundary on tracking links in email covers the full GDPR/CCPA/CAN-SPAM split with the per-jurisdiction details, and the hidden cost of not tracking your short links covers why aggregate measurement is still worth doing even when the per-person layer is off.

What a useful click dashboard actually shows#

Once the data is clean, the dashboard you want is small and answers four questions.

When did the clicks happen? A timeline chart with one bar per day, hourly resolution on hover. Spikes line up with sends; flat sections tell you the campaign's tail is over. The live read on real-time link analytics covers the sub-second case where you want to watch a launch hour as it happens, not the day after.

Where did they come from? Country breakdown for geography, referrer breakdown for "which platform", UTM breakdown for "which campaign and channel". Three tables, one screen.

On what? Device class (mobile, desktop, tablet), browser, OS. Useful for "we lost half our clicks at the conversion step on Android — is the form broken there?" diagnoses.

Which campaign? UTM source / medium / campaign as filterable dimensions, sortable by clicks and (when the conversion postback is wired) by conversion rate.

That's the dashboard the click analytics docs describe. Notice what's not on the list: a "who" column. The dashboard doesn't pretend to have names it doesn't have. When it does have names — from the three legitimate joins above — those live one layer up, in your CRM or email tool, not in the click log.

The simplest first step#

If you came here looking for "how do I know who clicked", the smallest move that closes most of the gap, in under an hour:

1. Audit your top three channels. Newsletter, primary social, primary paid. For each, ask: is the destination URL tagged with utm_source, utm_medium, utm_campaign? Mint a test slug in the no-signup short-link generator and watch the breakdown a single tagged click produces — it's the fastest way to see exactly which fields land where.
2. For your newsletter specifically, add utm_content=<subscriber_id> to the long URL. Your email tool can merge-tag this in. Now the click is tied to the subscriber by your own consented identifier.
3. For paid and cold flows, add a form on the landing page. Even a one-field email capture turns the click → person join from "impossible" to "explicit".
4. Drop any open pixels and any raw-IP logging your tool defaults to. You don't need either for the answers you're actually after, and both add privacy debt you'll have to manage later.
5. Review the click log weekly. Sort by source. The patterns become obvious within the first two weeks.

The point isn't to know everyone. It's to know enough about the people you're allowed to know about that next quarter's budget moves on signal, not vibes.