Every link-in-bio competitor ships a cookie banner on the public page. Linkette never wrote a cookie — and the analytics still work. Here's how, exactly.
Open Linktree in a fresh browser session. Click any creator's public page. The cookie banner unfolds at the bottom of the screen, asking you to choose between accept all, reject all, and the third option — the small grey link buried in the middle, manage preferences — that nobody clicks. Bento behaves the same way. So does Beacons. So does every link-in-bio platform I have tested, including the European ones that should know better.
Linkette does not show you a banner. We do not show one because we have nothing to ask permission for. We never wrote a cookie. The public page sets zero cookies on first visit, sets zero cookies on tenth visit, sets zero cookies after you click a link and come back. You can verify this in twenty seconds with the developer tools panel in any browser. You can verify it with curl -I from your terminal and observe the absence of any Set-Cookie header.
I want to explain how the analytics work without cookies, and why I think this design choice is more honest — both to the GDPR and to the visitor — than the consent-based pattern that has become standard.
The mechanism, in detail
When a visitor arrives at a Linkette page, the server needs to count two things: total page views, and unique visitors per day. Total page views is easy — increment a counter on every request, nobody cares. Unique visitors is the part where most analytics systems reach for a cookie.
We do this instead. On every request, we compute a hash. The inputs to the hash are: the visitor's IP address, a salt that rotates daily at midnight UTC, a server-side pepper held in a Scaleway secret that no application code can read at runtime, and the page id being visited. We run those inputs through SHA-256, take the first twenty-four characters of the resulting hex string, and use that twenty-four-character token as the visitor identifier for the day.
The token is stable within the day: if you visit the same page three times in an afternoon, all three requests produce the same token, and we count you as one unique visitor. The token is unstable across days: tomorrow's hash of your IP is different from today's, because the salt has rotated, so we cannot link your visit on Tuesday to your visit on Wednesday. The token is also tied to the page id, which means your visit to creator A is not linkable to your visit to creator B even within the same day.
We store the twenty-four-character hash. We do not store your IP. We do not store the salt or pepper anywhere accessible from application code. There is no path, even for me as the operator, to reverse the hash back into an IP address. The hash is a one-way function and the inputs are unrecoverable.
Why this is more GDPR-compliant than consent banners
The standard counter-argument is that consent banners are the GDPR mechanism, the one prescribed by the regulation, and that engineering around them is somehow clever but legally unnecessary.
I think this misreads the regulation. The GDPR's general principle is data minimization: do not process more personal data than the purpose requires. A cookie that identifies a visitor across pages and across days, even with consent, processes more data than is required to count unique visitors per day per page. The cookie banner asks the visitor to permit a kind of processing the operator does not actually need.
Banner fatigue compounds this. The current research literature on consent banners — there is a strong body of it now, ten years after the e-privacy directive — finds that the overwhelming majority of users click accept all without reading, because the alternative is friction they have no incentive to absorb. Consent under those conditions is, in any meaningful sense, not informed. A regulator looking at it strictly might call it fraudulent consent. The visitor did not actually agree to be tracked; they agreed to make the banner go away.
A platform that processes no personal identifiers and asks no permission is, in my reading, more aligned with the spirit of the regulation than one that processes everything and asks the visitor to rubber-stamp it.
I am not a lawyer. I had a CNIL-aligned audit done in week seven of building Linkette. The auditor agreed with this framing.
The trade-off we accept
The honest cost of this design is that we cannot do certain things that cookie-based analytics can do.
We cannot tell you that visitor X came to your page on Monday and again on Friday — to us, Monday-X and Friday-X are different tokens, and we have no way of knowing they are the same person.
We cannot offer a retargeting pixel that lets you advertise to visitors who landed on your Linkette page. There is no persistent identifier to retarget.
We cannot build a cohort analysis that says visitors who arrived in March returned at a rate of fourteen percent in April. We can build a much weaker version of that question, but the precise individual-level cohort is not available to us.
I think those things are fine to give up. Linkette is a link-in-bio platform. The job of the public page is to route a visitor from a social media post to the creator's actual destination. The creator does not need to know the visitor's name; the creator needs to know which link converted and how many people came. That, we measure precisely.
The numbers, verified
Three concrete data points from the production system as it stands today.
Zero cookies are set on the public Linkette page. You can verify this with the browser's storage inspector or with curl -I https://linkette.eu/<any-slug> — there are no Set-Cookie headers in the response.
Zero third-party scripts load on the public page. No Google Tag Manager, no Meta Pixel, no Google Analytics bootstrap, no Hotjar, no Intercom widget. The page is one HTML document, one stylesheet, the page's image assets, and a small inline script that handles click tracking by sending a beacon to our own endpoint.
Page weight on a typical creator page is under sixty kilobytes including the avatar image, on a cold cache. The page is interactive in under one second on a 4G connection from anywhere in Europe, because BunnyCDN edge nodes serve the cached HTML from a point of presence near the visitor.
Speed is not the goal of the cookie-free design, but it is a happy consequence. Every analytics tag a competitor loads is a tag we do not. Every third-party domain is a TCP handshake we do not perform. Pages that do less, faster.
A small note on the click-tracking endpoint
Click tracking — knowing which link the visitor clicked, so the creator can see which destinations are working — runs on the same principle. When you click a link on a Linkette page, a tiny POST request fires to /api/click with two fields: the link id, and the same daily-hashed visitor token described above. We never store a referrer. We never store an IP. We never set a cookie in the response. The link itself is a standard HTML anchor; if our analytics endpoint is unreachable, the link still works. Analytics never blocks navigation.
Why I think this matters beyond Linkette
A small platform like ours has the freedom to design analytics this way from the first commit. Larger platforms, the ones that built their analytics around cookies five or ten years ago, would face a serious migration to do the same. Most will not. The cookie banner has become, for them, a kind of compliance theatre: it is the cheaper-than-rebuilding answer to a problem that has a better engineering solution.
I would like, modestly, for the European link-in-bio category to converge on cookie-free as the default. There is no technical obstacle. There is institutional inertia, and there is the comfort of a familiar banner that lets the company say we asked, the user agreed. The user agreed because the banner was in their way. That is not consent. That is friction.
If you are running a creator platform and you'd like to walk through how this works in detail — the salt rotation, the pepper handling, the hash construction, the audit trail — write to me at founder@linkette.eu. I am happy to share the implementation. The whole point of this approach is that it should not be a competitive moat. It should be the default.