Server-side tracking

Server-side tracking records an event on a server you control, rather than in the visitor's browser. The record is written before any browser code runs — so it does not depend on JavaScript executing, and a blocker has no tag to block.

That is the whole mechanism. Everything else on this page is about where it helps, and where it is oversold.

The gap it closes

Browser-based analytics counts an event when its tag fires. That tag frequently does not fire:

• Ad blockers and tracker-blocking extensions remove it before it runs.
• Apple ITP and other privacy features restrict what it can do and how long it remembers anything.
• In-app browsers — the one inside a social app — often break it outright.

None of those sessions vanish. The visitor still arrives. Only the record is missing. Your analytics does not report a gap; it reports a smaller number and says nothing. That is the failure mode that matters: it is silent.

A server-side count does not have that gap, because there is no browser step to interfere with.

Absence of data is not no data

The instinct when a session goes unrecorded is to treat it as lost. It isn't.

What is missing is missing in a pattern. The people who block trackers are not a random sample of your visitors — they skew by device, by browser, by technical literacy, by channel. Statisticians have a name for this: missing not at random (MNAR). It is the hardest kind of missing data to handle, and it is the only kind that carries information in its own shape.

That matters because it changes the question. "How many did I lose?" has no answer. "What kind of visitor is systematically absent from this number, and which way does that bias the decision I am about to make?" has several — and some of them are estimable.

Server-side counting closes the gap where the click passes through a redirect you control. It does not close it everywhere. For what remains, the honest response is to model the absence rather than report a smaller number in silence.

We wrote about this properly — MNAR, Bayesian imputation, GDPR's actual enforcement record — in The Arithmetic of Absence: blocking trackers doesn't make you invisible, it makes you missing data.

Where HikrLink does this

HikrLink counts clicks at the server redirect level, so clicks are recorded even when ad blockers or Apple ITP prevent browser-based tags like GA4 from firing.

The boundary, stated plainly: the property belongs to the redirect, not to the label. A click is counted server-side when it passes through a tracked redirect. Short and ad links do that by default.

Bio-page buttons are a different case, and worth being precise about. Every bio button is individually tracked — but by default that tracking happens in the browser, which means an ad blocker can stop it exactly like any other browser tag. A bio button earns the server-side property only when the URL behind it is itself a shortened tracked link: then the click lands on the redirect first and is counted before the browser gets involved. Today that is a manual step — you shorten the link, then add it. It is not automatic, and we are not going to describe it as if it were.

What server-side tracking does not do

It does not make you GDPR compliant

This is the claim to be most suspicious of, because it is the one most often sold.

Moving a tag to a server changes who executes it. It does not change what you collect or why. Counting a click with no persistent identifier is a different act from forwarding a user-level event to an ad platform — and the second needs consent regardless of which machine the code runs on. Routing it through your own domain first does not launder it.

That is not a limitation of the tooling. It is how the rules work, and we would rather say so than pretend. Anyone offering server-side as a consent workaround is describing a legal risk with a feature's vocabulary.

It does not recover what you already lost

Server-side counting is not retroactive. It starts working when you start using it.

It does not identify people

A more complete count is not the same as knowing who somebody is. Uniqueness derived from a hashed IP and user-agent is an estimate, and it is deliberately not an identity.

Server-side tracking vs server-side tagging (sGTM)

These get used interchangeably and they are not the same thing.

• Server-side tracking — the event is recorded on your server.
• Server-side tagging — the tag container that decides where events get forwarded runs on your server, usually sGTM on your own subdomain.

You can do the first without the second. Most of the ad-blocker resilience people want comes from the first.

What we have not built

Forwarding click and conversion events onward to Meta CAPI via sGTM is in progress and not shipped. There is no forwarding code in production today. We are listing this here, on our own page, because a page about honest measurement that quietly omits its own gaps is worth nothing.

When you actually need it

Server-side counting is worth it when the number is a decision input: paid traffic where the click count drives spend, mobile-heavy or social traffic where blocking rates are highest, or any case where "direct / none" has swallowed a channel you know is working.

If you run low-volume organic traffic and your analytics is directionally fine, this is not your bottleneck. We would rather say that than sell you something.

Questions

What is server-side tracking?

An event recorded on a server you control rather than in the visitor's browser. It does not depend on browser JavaScript running, so blockers cannot prevent it.

Why does server-side tracking count more clicks than Google Analytics?

GA4 counts when its tag fires. Blockers and ITP stop that tag in many sessions — especially mobile Safari and in-app browsers. A server-side count happens at redirect time, before the browser is involved.

Does server-side tracking bypass ad blockers?

For a tracked short or ad link, yes: the click is recorded at the server redirect and there is no browser tag to block. What decides it is whether the click passes through a tracked redirect. A bio-page button gets the same property only if the URL behind it is itself a shortened tracked link — a manual step today, not a default. A bio button pointing straight at its destination is tracked in the browser, and can be blocked.

Is server-side tracking GDPR compliant?

No, not by itself. It changes who runs the tag, not what you collect or why. Forwarding user-level events to an ad platform needs consent wherever the code runs.

If a click is blocked, is that data just lost?

No. A blocked session is missing in a specific, non-random way — the people who block differ systematically from those who don't (MNAR). That structure is a signal. Server-side counting removes the gap for tracked redirects; for what the browser still owns, model the absence rather than pretend the number is complete. See The Arithmetic of Absence.

What is the difference between server-side tracking and server-side tagging?

Tracking = the event is recorded on your server. Tagging (sGTM) = the container deciding where events are forwarded runs on your server. You can do the first without the second.

Every claim on this page traces to our public claim registry, including the ceilings on what it does not cover. Where something is not built, we say so.