How link tracking works without cookies.

What you can count with no cookie.

When someone opens a short link, their browser sends a request. That request already carries a lot: the browser name, the language, the page that referred it, and the network address it came from. The host in front of the server adds the country and city it infers from that address. Counting needs nothing more, so nothing has to be placed on the visitor's device.

Each click is one row. Nothing is sampled, so a count is a count of rows. The city is worth a second look: it is looked up from the network address, so the address is used for a moment, and the city is kept. A city is coarse, but it is still location data and your notice should say so.

How a unique visitor is counted without an identifier.

To tell 100 clicks from 40 people you need something to compare. 1Namecard computes a SHA-256 hash from four things: a secret that stays on the server, the current date in UTC, the network address and the user agent. It keeps the first 32 characters of the result. The address and the user agent go into the hash and are not stored.

Because the date is part of the input, the same person produces a different value tomorrow. There is no table that maps a hash back to an address. So today's visitors can be counted, and yesterday's cannot be matched to them.

Read the numbers with that in mind. Daily unique visitors are reliable. A weekly figure made by adding seven days overstates people, because someone who returns counts again. Two colleagues on the same office network with the same phone model and software version can share a hash and count once. A visitor whose mobile address changes between clicks can count twice. It is an approximation, and good enough to compare placements.

What you cannot count, and what we store.

So you cannot count a person across days, a person across devices, how many times a named contact clicked or whether last week's visitor is back. If you need that, you need identification, and identification needs a lawful basis and usually consent. A lead form is separate: it holds what the person typed and the consent wording they saw, and it is kept until you delete it. It also records technical details of the submission, which only admins can see.

What the ePrivacy rules and the GDPR say.

Two laws matter, and they ask different questions.

Article 5(3) of the ePrivacy Directive covers storing information on a user's device, or reading information already stored there. It is not limited to cookies. Local storage, device fingerprinting and similar techniques can fall in scope, and it requires consent unless the storage or access is strictly necessary for a service the user asked for. A server that only receives what a browser sends anyway, and writes nothing to the device, is generally seen as outside it. But do not treat that as settled. The European Data Protection Board's Guidelines 2/2023 read the Article widely, name URL and pixel tracking, and say IP-based access can fall inside it in some cases. Ask counsel how your regulator reads it.

The GDPR asks a different question: is it personal data? Recital 26 says to consider the means reasonably likely to be used to identify a person. The Article 29 Working Party's Opinion 05/2014 on anonymisation treats hashing as pseudonymisation, not anonymisation. So a hash of an IP address can still be personal data in some views, even with a salt. The daily salt and the server secret make linking hard, and stop any link across days. They do not make the hash provably anonymous.

A cautious team therefore treats its click table as personal data. That means a stated purpose (counting visits to compare placements), a lawful basis you have written down, a retention period and a way to answer requests. The GDPR guide for events covers lead data, and the security page lists how 1Namecard hosts and separates data.

Filter bots and prefetchers, or the numbers lie.

1Namecard checks the user agent against a list of crawlers and preview fetchers, and checks the prefetch headers. A match is stored with a reason and left out of every count. Scanners that look like ordinary browsers can still pass. A useful sanity check is to compare clicks with leads: a link with 400 clicks and no form starts has a bot problem or a content problem.

Leave your own team out.

Staff test their own codes, show them to colleagues and open them from the admin. A stand with eight reps can produce hundreds of staff clicks. 1Namecard recognises visits from your own team and leaves them out of the counts. They are stored with a flag, and you can bring them back by ticking Include internal in Analytics or Funnel.

Carry attribution in the address, not in a cookie.

Without a cookie, the memory of where a visit came from has to live somewhere else. The answer is the address. A short link adds ?s= with its key when it sends a visitor to a card. The card page reads it and keeps it in the browser's session storage while the tab is open. When the visitor submits a lead form or meeting request, the placement goes with it, so the lead arrives with its source. Closing the tab clears it.

Be precise about this. Session storage is not a cookie, but it is storage on the device, and Article 5(3) is not limited to cookies. What is stored is a placement word and the buttons tapped, not an identifier. Whether that falls under the exemption for what is strictly necessary is for your counsel. The cookie policy says what 1Namecard stores. The limit is that attribution lasts for a visit: a prospect who scans on Monday, closes the tab and returns on Thursday without scanning has no placement. The UTM guide shows how to tag it as well.

What to tell your privacy notice.

Link the notice from every card and form, and keep it consistent with what you configure. The short link guide covers the other fields on a link. Review the notice whenever you change what you collect.