← ALL GUIDES

Link Tracking: The Complete Guide

Everything that happens between a click on your link and knowing which campaign made you money — redirects, UTMs, click IDs, conversions, bots, and why your numbers never match.

LAST UPDATED AUG 20, 2026 · 22 MIN READ

You run one campaign. Three tools count it. Your short link says 4,812 clicks, the ad platform says 5,390, and analytics reports 3,100 sessions. Nobody's lying. Everybody's measuring a different thing, at a different point in the chain, with different rules about what counts.

Most people show up here because of that gap. Fair. But the gap is the last thing you should fix, because it's a symptom of five or six things happening upstream that nobody explained to you.

So start at the beginning. A click is not one event. It's a browser request, a lookup, a redirect, a second request to your destination, and somewhere in there a set of decisions about whether that visitor was a person, whether a cookie survived, and which of your campaigns gets to claim them. That whole sequence takes about 50 milliseconds and every tool you use is sampling a different slice of it.

This guide walks the sequence in order. What happens on the click. How to tag links so the source is actually readable six months later. What click IDs do that UTMs can't. How a purchase gets matched back to the click that caused it, and why that matching quietly breaks more often now. Which click gets the credit when there were four. Which "clicks" were bots and previews and email scanners.

By the end you'll be able to say which campaign made you money, and explain the discrepancy in your dashboards without guessing.

Skip around if you already know a piece. The order is deliberate but not compulsory.

What actually happens when someone clicks a link

Someone taps your link. Roughly 50 milliseconds later they're on your landing page. Everything in this guide happens inside that gap, so it's worth knowing the steps.

Four hops:

  1. The browser resolves your tracking domain. go.yourbrand.com/spring isn't a page. It's a lookup key pointing at a redirect service.
  2. The service looks up the slug. spring maps to a destination URL stored in a database, and this is the only step that touches your infrastructure.
  3. The service records the click and answers with a redirect. Status code, Location header, done. Nothing renders. The visitor sees nothing.
  4. The browser requests the destination. The visitor lands.

Step 3 is where all your measurement comes from. That single request carries the user agent, the IP address, the referrer, the timestamp, and whatever tracking parameters you attached to the link. That's it. That's your entire dataset for the click.

Which means two things you should internalize now.

You only get one shot at capturing data. Once the browser moves on to the destination, the redirect service is out of the conversation. It never hears about the pageview, the add-to-cart, or the purchase. Anything you want to know later has to either be captured in that hop or handed off to the destination through the URL.

The handoff is the whole game. The redirect appends your tracking parameters to the destination URL so the analytics tool on the landing page can pick them up and continue the story. Break that handoff and you get two disconnected datasets. A shortener counts clicks, an analytics tool counts sessions, and nothing ties them together. Most "my numbers don't match" problems start right here.

Practical consequences:

  • There is no page at your tracking domain, so don't expect a pageview from it.
  • Don't strip query strings in your redirect config. That's the handoff you're deleting.
  • Don't assume every recorded click became a visit. Browsers abandon that second request all the time, and plenty of "clicks" were never a browser at all.

You don't need to know the difference between a 301 and a 302 to use link tracking. You do need to know it before you reuse a slug, because one of them gets cached in the visitor's browser and quietly stops reporting. When that becomes relevant, our breakdown of how link redirects work covers the status codes and what browsers strip on the way through.

Tagging links so you know where clicks came from

The redirect tells you a click happened. UTM parameters tell you where it came from. They're just extra bits stuck onto the end of your destination URL, and analytics tools read them automatically.

There are five. Most teams need three.

  • utm_source — which platform sent the click. newsletter, linkedin, partner-blog.
  • utm_medium — what kind of traffic it is. email, cpc, social, qr.
  • utm_campaign — which push it belongs to. spring-sale-2026, webinar-april.
  • utm_content — which version of the thing. Two buttons in the same email, or two creatives in the same ad set, and only when you actually plan to look at the comparison.
  • utm_term — the paid search keyword. Skip it unless you're running search ads without auto-tagging.

Tagged up, a link looks like this:

https://yoursite.com/pricing?utm_source=newsletter&utm_medium=email&utm_campaign=spring-sale-2026

Ugly, yes. Nobody sees it if the link is shortened, and every one of those values becomes a row in your reports, which is what the ugliness buys you.

Set source and medium on every link that leaves your building. Campaign on anything with a start and end date. Content only when you're actually comparing two versions and plan to look at the result.

Pick one spelling and never deviate. That single rule decides whether any of this works.

Analytics tools match on exact strings. Newsletter and newsletter are two different sources. email and e-mail are two different mediums. Nothing warns you. Your traffic just quietly splits into four rows that each look too small to matter, and six months later somebody concludes email doesn't convert.

So decide now, in writing, before anyone tags another link:

  1. Lowercase everything.
  2. Hyphens between words, never spaces or underscores.
  3. A short fixed list of allowed mediums. Five or six. Not fifteen.

That's it. The convention doesn't need to be smart, it needs to be the same every time, including when the intern builds a link at 6pm on a Friday.

If you want the full picture — where each parameter ends up in your reports, which ones ad platforms overwrite, and the mistakes that corrupt campaign data without any error message — our complete UTM parameter reference goes through all five properly.

Keeping your tags from turning into chaos

Your UTM data doesn't break. It rots, slowly, and nobody notices until the quarterly report looks wrong.

One person tags facebook. Someone else tags Facebook. The intern doing the holiday push writes fb. Reporting tools treat those as three separate sources, so your biggest channel shows up split into thirds and every one of the thirds looks unimpressive. Same with email and Email and newsletter and email-newsletter. Four rows, one channel.

Nothing warns you. There's no validation on a UTM parameter. Whatever you type is what gets recorded, forever, and you can't go back and fix six months of history.

So fix it at the input, not the report. Write down a convention, put it somewhere the whole team can see it, and keep it to four rules:

  • Lowercase everything. No exceptions, no judgment calls.
  • Dashes between words. Dashes or underscores, pick one, never mix.
  • A fixed list of sources, so nobody invents linked-in next Tuesday when linkedin is already on it.
  • Dates go in the campaign name. Not the medium, and not a mental note somebody keeps. spring-sale-2026.

That's it. A messy convention everyone follows beats an elegant one that three people ignore.

The part teams skip is enforcement. A document in Notion is not enforcement. That's why our free UTM builder checks names as you type them, flags capitals and mixed separators, and remembers the values your team has already used so the next person picks from the list instead of guessing. It takes about ten minutes to agree on a vocabulary and then it stops being a decision anybody has to make again.

If you want a scheme you can copy straight into your team's docs, complete with the per-field vocabulary and the checker that keeps everyone on it, that guide has it worked out in full.

Click IDs: tying a click to a specific visit

You've seen them. Someone clicks your Google ad and lands on a URL with ?gclid=Cj0KCQjw... stuck on the end. Facebook does the same with fbclid. Microsoft uses msclkid. TikTok, LinkedIn, Reddit, all of them append something.

That string is a click ID. It's not a campaign name or a source tag. It's a receipt for one specific click by one specific person at one specific moment, generated by the ad platform and handed to you as the visitor arrives.

UTM tags tell you a click came from your spring newsletter. A click ID identifies that click out of the four hundred others from the same campaign. That difference is the whole game once you start caring about revenue instead of traffic.

The platforms bother for one reason. When the visitor buys something, your site sends the click ID back, and the platform matches it against its own log of who saw and clicked what. Now Google knows the ad that produced a $340 order, and its bidding algorithm starts hunting for more people like that buyer. No click ID, no match, and the platform is optimizing blind.

Two kinds exist and you should be clear on which you're dealing with.

  • Platform-owned IDsgclid, fbclid, msclkid. The platform mints them, the platform reads them. You can pass one along, but you can't create it or interpret it yourself, and browsers strip them with increasing enthusiasm. When one gets stripped you have nothing.
  • First-party IDs — a click identifier your own link generates on redirect and stores against your own domain. It survives whatever a browser decides to remove from someone else's parameters, because it isn't someone else's parameter.

Run both. Platform IDs feed the ad platforms because that's the only thing they'll accept. First-party IDs feed your own reporting, which is the version you'll trust when the numbers argue with each other.

The mechanics of both, including what actually happens when a parameter gets stripped mid-journey, are worked through in click IDs explained in detail.

From click to sale: conversion tracking

Counting clicks is easy. Matching a click to the €89 order that came from it three days later is the part that breaks.

The basic mechanism hasn't changed in fifteen years. Someone clicks your tracked link, the click gets an identifier, that identifier gets stored in the visitor's browser, and when they hit your thank-you page a script reads it back and reports the sale. Click and purchase, stitched together by a value sitting in a cookie.

That stitch is what's failing.

Safari caps script-written cookies at seven days, often 24 hours. Firefox blocks third-party trackers outright. Chrome users install blockers at rates most marketers refuse to think about.

Add a purchase that happens on a phone after research on a laptop and your matching rate drops again. The conversions still happen. They just come back marked "direct" or don't come back at all, and your ad platform quietly under-reports the campaign that actually worked.

Watch for the symptom. Revenue is fine, attributed revenue is way down. That's a measurement failure, not a performance failure, and teams cut good campaigns over it every week.

Two fixes, in order of how much work they are.

First-party storage. Store the click identifier on your own domain instead of a third party's. Same idea, longer lifetime, survives the blockers that target cross-site tracking. This is the cheap version and it recovers a meaningful chunk on its own.

Server-side reporting. When the order gets confirmed, your backend sends the conversion, with its click identifier, straight to the ad platform or your own analytics. No browser, no cookie, nothing to block. It also means refunds and cancellations can be corrected later, which browser-side tracking can't do at all.

Do the first-party part now. Do server-side when the numbers justify the engineering, which for most stores selling more than a few hundred orders a month is already true.

The full picture, including what to send, when to send it, and how to handle a purchase that arrives with no identifier at all, is in conversion tracking without third-party cookies.

Which click gets the credit

One customer. Three ads. Same sale. Three different answers about what earned it.

The journey, and it's a common one:

  1. Tuesday — sees your Instagram ad, clicks, browses for 90 seconds, leaves.
  2. Thursday — searches your brand name, clicks the paid search ad above the organic result, reads a pricing page, leaves.
  3. Sunday — clicks a retargeting ad, buys the $400 plan.

Now run the same $400 through three attribution models.

First-click gives all $400 to Instagram. Nothing happens without discovery, so credit the thing that started it. Teams running top-of-funnel campaigns love this model, and they're not wrong to. But it also means your retargeting ads look like they generate nothing, forever.

Last-click gives all $400 to the retargeting ad. This is the default in most ad platforms and most analytics tools, which is exactly why so many teams over-invest in retargeting and brand search. Those channels sit closest to the purchase. They collect the credit for demand somebody else created.

Notice what last-click did to the brand search click on Thursday. Nothing at all. It's invisible in both models even though it's the click where the customer decided you were worth $400.

Multi-touch splits it. A simple linear split hands each ad $133. A position-based split might give Instagram and retargeting $160 each and leave the middle click $80. Pick whichever split you want, they're all arbitrary, and that's fine. The point isn't precision. The point is that no single channel gets to look like a hero or a failure on its own.

Don't agonize over choosing the "right" model. Pick last-click as your baseline because everyone else uses it and you'll need to compare notes, then look at first-click alongside it. When the two disagree wildly on a channel, that channel is doing work one of the models can't see. That gap is the interesting part.

The full breakdown of each model, when to switch, and how a lookback window quietly changes every number you're looking at is in attribution models in plain English.

The clicks that are not people

Some share of your click count never had a human attached to it. Not a rounding error either.

Where they come from:

  • Link preview fetchers. Paste a link in Slack, WhatsApp, Discord, or iMessage and the platform immediately requests the URL to build that little preview card. That request hits your tracking domain. It counts.
  • Email security scanners. Corporate mail gateways open every link in every message before the recipient sees it, checking for malware. Send a newsletter to a B2B list and a chunk of your "clicks" arrive within seconds of delivery, from data-center IPs, before anyone has read the subject line.
  • Crawlers and scrapers. Search engines, SEO tools, archive bots, and whatever someone built last week to harvest URLs.
  • Uptime and preview checks. Including, sometimes, your own monitoring.

The tell is timing. If you see a burst of clicks that lands in the first minute after send, spread evenly across every link in the email including the unsubscribe footer, that's a scanner working through your message top to bottom. Real people don't click the privacy policy and the hero CTA one second apart.

What to do about it:

  1. Check whether your tracking tool separates bot traffic from human traffic. If it only shows one number, that number is fiction.
  2. Compare raw clicks to unique clicks. A big gap on a single link usually means automation, not enthusiasm.
  3. Never report raw click counts to anyone who'll make a decision from them.

Don't panic about the share. Bot traffic is normal and mostly harmless as long as you're not counting it as demand. The damage comes from teams celebrating a 12% click rate that was really 7%, then buying more of the channel that produced the fake half.

The breakdown of which fetchers behave which way, how to spot them in your own data, and what filtering actually removes is in why your click counts are lying.

Why your numbers never match

Your shortener says 1,000 clicks. Google Analytics says 740 sessions. The ad platform says 1,150 clicks. Nobody is lying, and no amount of digging will make those three numbers agree.

They're counting different events at different points in the chain. The ad platform counts when someone taps the ad. Your link counts the request that reaches your tracking domain. Analytics counts a page that finished loading and ran a script. Between each of those, traffic leaks.

Four causes explain almost all of it:

  • Bots. They hit the redirect and never load a page, so they inflate the link count and never appear in analytics at all.
  • Redirects. Some people bail during the hop. Slow networks, an accidental back-tap, an app browser that chokes.
  • Blockers. Ad blockers and browser tracking protection stop the analytics script from firing. Real visit, no session recorded.
  • Consent. Decline cookies and most analytics setups don't count the session, though your redirect already counted the click.

Notice the direction. Every one of these makes the link count higher than the analytics count. That's expected. Panic when it goes the other way, because that usually means broken tags, a stray redirect stripping parameters, or a self-referral loop.

So stop chasing a match.

Pick a normal range instead. In most setups we look at, link clicks running 15-30% above analytics sessions is unremarkable. Write your number down, check it monthly, and treat movement as the alert. A campaign that suddenly sits at 60% is telling you something real. Bot traffic from one placement, a destination that's timing out, tags dropped in a redirect.

Same logic for the ad platform gap. Platforms count taps generously and dedupe on their own rules, so their number usually runs above yours. Fine. Consistency matters more than the absolute figure.

The per-cause breakdown, roughly how much each one accounts for, and how to diagnose which is hitting you is in why click counts don't match Google Analytics.

Tracking offline: QR codes

A QR code is a link. That's it. A camera reads the code, the phone opens a URL, and everything from the earlier sections applies: the redirect, the tags, the click ID, the conversion. The scan is just a click that started with a lens instead of a cursor.

Which means the code itself tracks nothing. Point a QR code straight at yoursite.com/spring-sale and you've printed a dead end. You'll see traffic to that page and no way to tell whether it came from the catalog, the shelf talker, or someone typing the URL from memory.

Put a tracked short link inside the code before you generate it. Tag it like any other campaign source, one code per placement:

  • Catalog page 12 gets its own link
  • The window decal gets its own link
  • The trade show badge gets one too, and so does the sticker on the receipt

Same destination, three links, three sets of numbers. Now "the catalog does nothing and the window decal does everything" is a sentence you can actually say.

One rule that's saved a lot of reprints. Never generate a static code that points at a URL you can't change later. Use a short link in the middle so you can repoint it after the boxes ship. Our trackable QR codes for print are built on short links for exactly this reason.

Scan data has its own quirks. No referrer, heavier mobile skew, and repeat scans from the same person at the same shelf. QR code tracking explained in depth covers what scan data can and can't tell you, and how to design codes people will actually point a phone at.

The link itself matters: branded domains

The domain in your short link is the only part of it a person actually reads. Everything after the slash is noise to them. So if the domain is a string of characters they've never seen, you're asking someone to tap a link from a stranger.

Use your own domain. go.yourbrand.com, yb.co, whatever you can get. Set it up once and every link you make from then on carries it.

Three things change when you do:

  • Trust. People click links from names they recognize, especially on mobile, where the domain is often all that's visible in a preview.
  • Deliverability. Generic shortener domains get abused by spammers, so email filters and messaging apps treat them with suspicion. Your domain carries your reputation instead of the pooled reputation of everyone else on a public shortener.
  • Attribution. A branded domain is yours. It doesn't disappear or get blocklisted over somebody else's campaign.

Don't overthink the domain choice. A subdomain of a domain you already own works fine and takes ten minutes to point at us. Buying a clever three-letter domain is a nice-to-have, not a prerequisite.

One caveat. A brand-new domain has no sending history, so give it a few weeks of normal volume before you put it on a million-recipient send. Ramp, don't dump.

Why generic short domains get flagged goes into the deliverability mechanics properly, including what filters actually check. On our side, branded short links with custom domains is part of every plan, and you can run as many domains as you have brands.

For developers: doing all this programmatically

If you're generating links in bulk, don't do it by hand. Create them from code, one call per link, with the destination, the slug, the UTM tags, and whatever internal IDs you want attached. That last part matters more than people expect. Stuff your own order ID or campaign row ID onto the link at creation time and every click event that comes back carries it, so you're not joining on fuzzy string matches later.

For click and conversion events, use webhooks rather than polling. Point them at your endpoint, verify the signature, drop the payload into a queue, and let your warehouse job pick it up. That gets you link data sitting next to your revenue tables, which is the only place attribution questions actually get answered. Endpoints, event payload shapes, retry behavior, all of it is in tracking links programmatically with our API. Read that one before you write any code.

Questions people actually ask

How do I track who clicked my link?

You don't, and you shouldn't try. You get a click record. Timestamp, rough location from the IP address, device type, browser, and where the click came from. That tells you a newsletter click came from an iPhone in Toronto at 9:14am, not that it came from Dave in accounting. If you want names attached, the person has to hand them over on the other end by filling in a form or logging in.

Why does my shortener show more clicks than Google Analytics?

Because they measure different things at different points. Your link counts every request that hits the redirect, including bots and previews. Analytics only counts visits where a browser loaded the page and ran a script that wasn't blocked, on a visitor who didn't bounce out in the first second. Expect the shortener number to be higher, always. A gap of 10-30% is routine; if you're seeing 3x, something's actually broken.

Are link clicks accurate?

Accurate as a count of requests, yes. Accurate as a count of humans, only after bot filtering. Raw click totals are the number nobody should be reporting in a meeting, because they include every scanner that touched the link. Filter first, then trust the number.

Can I track a link without the person knowing?

Technically the redirect is invisible, so nobody sees it happen. But "they didn't notice" isn't the same as "you're allowed". If you're in the EU, the UK, California, or selling to anyone who is, you need a privacy policy that says what you collect and, in a lot of cases, consent before you drop anything on their device. Aggregate click analytics without cookies sits on much safer ground than cross-site tracking, which is one of several good reasons to keep your setup first-party.

Do QR codes track people?

A QR code tracks scans, not people. The code holds a link; if that link is a tracked one, you get the same data any click gives you. Same rules apply. Location is city-level from the IP, and you don't get a name unless someone gives you one.

How long does it take to set up?

Creating a tracked link with proper tags takes under a minute. Getting conversions wired back to those clicks takes an afternoon, and it's the part most teams skip for six months and then regret. Do the links today, book the afternoon for later this week.

Where should I start?

Three things, in order.

  1. Tag consistently. Write the naming convention down, put it somewhere the whole team can see, and use it every time. Boring beats clever.
  2. Filter bots before you report anything. An unfiltered number is a guess dressed up as data.
  3. Measure the click-to-sale path. Clicks are a means. Revenue is the point, and you can't optimize what you haven't connected.

Everything past that is refinement. If you want the click side handled without building it yourself, Acturity's real-time click analytics covers the geography, device, and referrer breakdown out of the box, and you can go back to worrying about the campaign instead of the plumbing.