The click your dashboard filed under “direct”

Server-side click attribution means recording a click where the link is served — on the redirect — instead of where the page is rendered, so the record exists before the browser gets a chance to drop it.

That is the entire idea behind HikrLink. This piece explains the mechanism, the one thing it deliberately refuses to do, and what happened when we wired it to our own analytics tracker.

The failure is quiet

Most attribution doesn't fail loudly. Someone clicks your ad, your partner's post, your QR code. The browser strips the referrer, an extension blocks the tag, Safari caps the cookie, the consent banner is dismissed without a choice. The page still loads. The dashboard still fills. The visit is filed under direct.

Nothing in that chain looks broken. That's why it stays broken. If you run paid or partner traffic and have ever wondered why “direct” is your best-performing channel, this is the reason.

Record the click before the browser has a say

A HikrLink link is a redirect. The click is recorded on our server at the moment of the redirect — the destination, the time, the country, the referrer if there is one — and only then is the visitor sent on.

At that moment we also mint a click ID, hkclid, and append it to the destination URL. It's in the same family as the click IDs ad platforms already append to your landing pages, and it works the same way: it's a URL parameter. Anything that can read a URL parameter can store it.

That is the design in three sentences:

The click is recorded at the link. The key rides the URL, not the device. Identity is bound only when someone fills in a form.

Because the key is on the URL and not in a cookie, it survives the things that kill cookies: Safari's storage limits, tracking-protection extensions, a visitor who never engages with the banner. The click already exists in your link data before the page even asks.

One ceiling, stated plainly: this holds for tracked short links and ad links. It does not hold for links on a bio page yet. If you see us demonstrate it, it will be with a tracked short link.

What it refuses to do

It does not follow a visitor across devices. Phone click, laptop purchase — HikrLink does not know that was one person. There is no fingerprint, no probabilistic matching, no cross-site graph. We looked at building that branch and killed it, because every version of it is the thing the rules were written against. This is the trade, and it is the reason a click ID on a URL does not need a banner. Nothing to cross-reference means nothing to consent to.

Forwarding to ad platforms will always need consent. Sending events to Meta or Google is third-party sharing by definition, regardless of where your server sits. That's not a limitation of ours; it's how the rules work, and we'd rather say so than pretend a server location fixes it.

We are not GDPR-compliant yet. We're building toward a mode where click measurement is consent-free by construction and any platform forwarding is a separate, opt-in switch. Until that ships, “not yet” is the status. This article is the architecture, not the badge.

The other half, and what we broke

A click ID is only half of attribution. The other half is something on your site that reads the token and remembers what the visit did. We build that too — a first-party tracker called Hikr — and it's in private beta, which is the honest way to say it works on our own sites and we're not done.

On our sites it runs cookieless: nothing written to the device, a visitor key derived server-side and rotated daily so it can't be linked across days. It reads hkclid off the landing URL and stores it against pages, actions, form submits, and — through the payment provider — the purchase and any refund. The click from the link and the outcome on the site share one key, and that key never touched a cookie.

Here is what we found when we audited the wiring between the two.

The conversion call landed nowhere. The tracker posted conversions to the base URL it had been configured with, assuming every endpoint lived on one service. The conversion receiver was on another. The call failed, and the tracker swallowed the failure in an empty error handler. Both halves were “shipped.” Neither had ever met. A measurement whose failure mode is silence is not a measurement.

First click of the day won. In cookieless mode the visitor record is created on first sight and the token set at creation. A second tracked click from the same visitor that day found the record already there and was dropped. We had built first-touch attribution without deciding to.

Written, never read. The click ID was stored on every event. The purchase carried it. The refund inherited it. And nothing queried it — no report, no window, no join. Built, not wired. The read side is what the beta is for, and we're saying so here so the follow-up has a referent.

None of those three is on the link side. The link recorded the click and minted the token every time. The bugs lived where we were joining it to the page — which is, conveniently, the part still in beta.

A short aside on missing data

A suppressed click is not a click that didn't happen. It's a missing value with a known cause: a blocker, a browser policy, a declined banner, a region where person-level tracking should stay off. Missing-for-a-reason is a different statistical object from missing-at-random, and treating them the same is how dashboards lie with confidence. We've written about that distinction before, in The Arithmetic of Absence.

We read a 2026 paper on Bayesian imputation with uncertainty for exactly this problem. Then we read the Stan manual's chapter on missing data — “missing values are just parameters” — and it fit better, because it assumes you know why your data is missing, and we do. Our most sophisticated tool for the problem, so far, is a column that says suppressed. We think that column is worth more than an imputed number nobody can audit.

Questions people ask

Does this replace GA4 or my ad platform's reporting?
No. It gives you a click record that exists independently of the browser, and a key on the URL you can join to whatever you already run.

Do I need Hikr to use the click ID?
No. It's a URL parameter. If your analytics or CRM can capture one, it can capture this. Hikr is the half that reads it natively, and it's in private beta.

What about Google Ads, where you can't redirect through a third domain?
Google prohibits a cross-domain redirect from the final URL and requires parallel tracking, so the click ID has to be minted where the landing page is served instead of at a redirect. That's a design we have and haven't shipped.

Can I see a number?
Not in this piece. The join between link and site exists in the schema and not yet in a report. When it does, the number will come with the query that produced it.

What we're claiming

1. A click recorded at the redirect exists before the browser can drop it. That is the whole advantage, and it applies to tracked short and ad links only.
2. A join key carried on the URL survives cookie limits and blockers because it never depends on device storage — and anything that reads a URL parameter can store it.
3. Cross-device tracking is refused, not pending. Ad-platform forwarding always needs consent. We are not compliant yet and will say so until we are.
4. The tracker that reads the key is in private beta. We found three wiring bugs between link and site; none was on the link side. We're publishing the fixes as they land.

HikrLink has a free tier. Start with one tracked link on a campaign you already run, and look at where the clicks were before the page loaded.

---

Bouletteproof builds HikrLink and Hikr and uses both on its own sites. Nothing above is legal advice.