Fingerprinting on the way out – what's next?

For years, experts have been warning about it: fingerprinting for user identification is a cat-and-mouse game between tracking technologies and the providers of operating systems and browsers. With the announcement of iOS 26, Apple now appears to have put an end to this game. Instead of merely reducing the amount of transmittable parameters, Apple is now using so-called noise data injection* by default. The resulting random interference makes fingerprinting practically useless.

*Noise data or noise data injection refers to the deliberate insertion of random, false, or distorted information into a dataset in order to reduce or prevent its usability.

In the context of fingerprinting, this means: when the browser is queried for technical parameters such as screen resolution, installed fonts, or color depth, it does not only return the actual values, but mixes in randomly generated variations. This makes it impossible to create a unique “fingerprint,” as the data becomes inconsistent and non-reproducible.

In other words: Apple has won the match.

Why user identification remains essential in marketing

For successful online marketing, stable and long-term user identification is essential. It forms the basis of accurate web analytics. Without this connection, marketing teams are essentially flying blind — we no longer know where a user came from, which path they took, or which interactions ultimately led to a conversion.

The industry faces a dual challenge:

• Theoretical data protection through legal requirements such as GDPR or ePrivacy

• Practical data protection through technical restrictions in browsers and operating systems

Both make precise measurement more complex than ever before.

Levels of user identification quality

Let’s imagine a visitor interacting on different days using different devices:

• once via smartphone

• once via laptop

• once from their office computer

Each time, they add products to their cart, submit an inquiry, and eventually complete a purchase. The question is: how can we recognize these separate sessions as belonging to the same user?

In web analytics today, several levels of user identification can be distinguished:

Cross-Device Tracking

This method captures the entire customer journey across different devices.
Technically, this is particularly challenging, as devices generally have no knowledge that they are being used by the same person. Even if this information exists – for example, through a Google login on multiple devices – it is usually not shared with website operators.

There are methods to implement cross-device tracking nonetheless, but they often only work for a portion of visitors. The rest is extrapolated or captured at a lower quality level.

Cross-Domain Tracking (3rd and 2nd Party)

The goal here is to identify a visitor across different domain boundaries – on the same device.

There are two scenarios:

• 3rd Party Tracking: The domains belong to different organizations.

• 2nd Party Tracking: The domains belong to the same organization.

Technically, there is no difference. In both cases, identical methods are used.
The difference lies in data protection regulations and organizational aspects:

Example of 2nd-Party Tracking:
A visitor accidentally lands on the German version of your website, although they actually intend to buy in Austria. You redirect them to the Austrian domain (e.g., shop.de → shop.at) and want to recognize them across this domain boundary. In many cases, this can be implemented both technically and legally without major issues.

Example of 3rd-Party Tracking:
A user sees an ad on google.de and then lands on your website shop.de. Since different organizations are involved here, different data protection rules apply – and the implementation is organizationally much more complex.

Single-Domain, Cross-Session Tracking

Probably the most commonly used method in practice: tracking is limited to a single domain, but it still recognizes visitors across multiple sessions – even if they take place on different days.

However, if a user switches devices or visits another domain, these touchpoints are no longer linked.

For many use cases, this level of tracking quality is sufficient. With modern server-side tracking setups, it can also be implemented relatively easily and in compliance with data protection regulations.

Single-Session Tracking

One level below is single-session tracking. Here, recognition is limited to a single visit. On their next visit to the website, the user is technically considered “new.”

For comprehensive marketing tracking, this method is hardly suitable. It is mainly used in specialized contexts – such as UX analyses, where only behavior within a single session is relevant.

Hit Tracking

The lowest “quality” of user tracking is, strictly speaking, no user tracking at all. Here, each individual page view (hit) is measured anonymously and without any link to a person. This can be useful for technical metrics such as load testing or performance statistics – but is generally useless for marketing purposes.

From theory to practice: How does user identification actually work?

Now that we know the different quality levels of user recognition, the question arises: what methods are actually available to implement them?

In principle, we distinguish between deterministic and probabilistic methods.

• Deterministic methods work with unique identifiers that allow for a secure match, such as login data, email addresses, or device IDs.
• Probabilistic methods are based on probability calculations. They combine parameters such as IP address, browser configuration, time of day, or language settings and use them to determine, with a certain probability, whether it is the same user.

The challenge of storage: Why the web forgets

Even if a user has been identified, this information must also be stored – persisted. The problem: the web was originally designed as a stateless system. Neither browsers nor servers inherently remember who visited a website. This gap was only closed in 1994 by Lou Montulli at Netscape – with the invention of the cookie. Almost 30 years later, we at JENTIS had the opportunity to interview him personally:

• The Origin Story of the Web Cookie and the Struggle for the Free Web
• The Rise and Fall of Third-Party Cookies

Methods for permanently storing and recognizing a user ID

There are various ways to store a user ID long-term and read it again later. Each method has its own technical requirements, advantages, and disadvantages.

First-Party Cookie

A cookie allows a website operator to store a small piece of information in a visitor’s browser and retrieve it when needed. A first-party cookie is always stored in the context of a specific domain and user and can only be read by that domain. In most browsers, client-side cookies in a first-party context have a maximum lifespan of 7 days. Server-set cookies have an advantage here – in a first-party context, they can often persist for several years.

Third-Party Cookies

In principle, they work like first-party cookies, with the difference that they can also be read by other domains. This makes them particularly suitable for storing information across domains. However, this method should no longer be relied upon today, as most browsers and ad blockers block third-party cookies by default, meaning support is minimal.

You can read about how first-party and third-party cookies differ in this blog article.

URL Decoration: Another way to transfer information between pages is through URL decoration. A well-known example is the gclid that Google adds to the URL when a user clicks an ad, allowing the click to be identified on the landing page. This method can be used not only for advertising but also within your own domain or during a domain switch to recognize users within a session. However, there are limitations: it does not work for recognition across multiple sessions, every link must be adjusted (increasing implementation effort), and browsers like Firefox and Safari have already announced they will act against this method.

Fingerprinting: One of the most controversial methods, as it works without cookies or other additional tools and can still recognize users – in some cases even across domains. It evaluates parameters related to a user’s settings, such as screen resolution, color depth, installed plugins, and more. The combination of these values is often unique enough to be equivalent to a user ID. The weak point is that the browser must allow access to these data points; if parameters are blocked or falsified, fingerprinting quickly loses its effectiveness.

Apple’s announcement: The end of fingerprinting?

With its recent press release for iOS 26, iPadOS 26, and macOS 26, Apple announced a new feature with major implications: Advanced Fingerprinting Protection will be enabled by default. The key difference is that until now, parameters were simply reduced to make fingerprinting less accurate. Now, noise data will be introduced – deliberately false values randomly mixed with the real ones. The result is that the data needed for fingerprinting is no longer reliably usable, rendering the method practically useless. Since Apple has been a pioneer in blocking third-party cookies, it is likely that other browser vendors will soon adopt this measure.

Cross-device tracking is only possible if you yourself ensure deterministic user recognition – for example, through a login. If you have identified the user on both devices, you can then use normal cross-domain methods to store and read this information. Cross-domain tracking via URL decoration only works if there is a direct click from one domain to the other. If the visitor leaves the domain and, for example, returns to the second domain a day later, you cannot identify this user across domains using URL decoration.

Which user identification methods still work today?

After recent developments, the key question is: which methods for user identification, storage, and recognition remain reliable today?

Cross-device tracking is still only possible if the user clearly identifies themselves – for example, through a login or an email address. For cross-domain and cross-session tracking, there will be no way around server-side tracking in the future. This technology allows for the setting of server-side cookies while also using URL decoration to capture user data across domain boundaries.

Concrete action steps

• Implement server-side tracking

• Set server-side cookies – including proxy solutions for Safari 16.3 and newer

• Use URL decoration for cross-domain tracking

• Develop your own login solution and consolidate the resulting data in a server-side backend user storage