How to Build a Custom Cookie-Less Ad Tracking Network

With browser engines blocking third-party tracking cookies by default, the digital advertising industry is seeking alternative methods to maintain attribution accuracy. While some platforms adopt Google’s Privacy Sandbox, other applications require direct, independent conversion verification systems.

To meet these requirements, software engineers can build a Custom Cookie-Less Tracking Network. By combining server-side event loops, device fingerprinting calculations, and cryptographic hashes, you can track marketing conversions without storing cookies or violating user privacy guidelines.

This project blueprint details the code architecture, fingerprinting calculations, and database layouts needed to construct a custom cookie-less tracking network.

---

Technical Concept: Identity without Local Storage

Cookie-less tracking relies on calculating a unique Device Fingerprint Hash using standard request parameters sent by the browser. Because this fingerprint is calculated entirely server-side, it requires zero browser database storage (no local storage, indexDB, or cookies).

The tracking architecture operates as follows:

[ User Device ] === (HTTP Request Headers) ===> [ Tracking Server ]
                                                      |
                                                      v
                                            [ Generate SHA-256 Hash ]
                                            (User Agent + IP + Accept-Language)
                                                      |
                                                      v
                                            [ Query Database Matches ]

When a user clicks an ad:

1. The tracking server logs the request headers, generating a unique SHA-256 identity hash.
2. The user is redirected to the destination site, with an ad click ID appended to the URL.
3. If the user converts later, the target server generates the same identity hash and matches it in the database to credit the source ad campaign.

---

Calculating a Stable Fingerprint

A stable fingerprint must contain enough data variance (entropy) to uniquely identify a user device, while remaining stable as network settings change.

1. Entropy Sources

We combine the following request values:

• User-Agent: OS version, browser engine, device model.
• Accept-Language: Regional locales.
• Screen-Resolution / Time-Zone: Sourced via client-side scripts.
• IP Address Subnet (CIDR /24 or /48 for IPv6): Using subnets rather than the full IP address prevents fingerprint decay when mobile devices switch cells.

2. Hash Generation

Generate the identity hash using a server-side cryptographic function (Node.js example):

const crypto = require('crypto');

function getIpSubnet(ip) {
  if (!ip) return '127.0.0';
  // Truncate IPv4 to /24 (first 3 octets)
  if (ip.includes('.')) {
    return ip.split('.').slice(0, 3).join('.');
  }
  // Truncate IPv6 to /48 (first 3 blocks)
  if (ip.includes(':')) {
    return ip.split(':').slice(0, 3).join(':');
  }
  return ip;
}

function generateFingerprint(req) {
  const ipSubnet = getIpSubnet(req.ip);
  const userAgent = req.headers['user-agent'] || '';
  const acceptLang = req.headers['accept-language'] || '';
  
  const rawString = `${ipSubnet}|${userAgent}|${acceptLang}`;
  return crypto.createHash('sha256').update(rawString).digest('hex');
}

---

HTTP ETag Tracking: Utilizing Browser Caches

Another advanced method utilizes HTTP ETags (Entity Tags), which are unique identifiers used by browsers to check if a cached file has changed.

In an ETag tracking setup:

1. The tracking server serves a tracking image with a unique ETag header (e.g. ETag: "user-98765").
2. The browser stores the image and ETag in its cache.
3. On subsequent visits, the browser sends a request with an If-None-Match: "user-98765" header to check if the image has changed.
4. The server reads this header, identifying the user without setting a cookie.

---

Tracking Technologies Comparison

The following table compares the capabilities of different tracking setups:

Tracking Method	Local Storage Required	Session Stability	Ad Blocker Resistance	Compliance Complexity
Traditional Cookies	Yes (Sets cookie keys)	High	Low	High (Requires cookie banners)
Subnet Fingerprinting	No	Medium (IP changes decay hash)	High	Medium (Requires IP masking)
ETag Cache Tracking	No	High (Until cache is cleared)	Medium	High (Hidden tracking concern)

---

Key Takeaways

• No Local Storage: Cookie-less systems generate device profiles server-side using request headers, bypassing browser storage controls.
• Subnet Hashing: Truncating IP addresses to subnets stabilizes user fingerprints as devices transition between networks.
• Cache Identification: HTTP ETags leverage standard browser cache validation headers to track user identities without local keys.

---

FAQ

Here are answers to the most frequently asked questions about this topic:

Is fingerprinting legal under GDPR?

GDPR rules apply to any data that can identify an individual. Because device fingerprints and IP subnets are considered personal data, you must get explicit user consent before generating hashes, and you should hash and mask IP addresses to protect privacy.

How stable is subnet-based fingerprinting?

If a user updates their browser or switches from home Wi-Fi to mobile data, the fingerprint hash will change. This makes fingerprinting best suited for short-term conversion attribution (under 48 hours) rather than long-term profile tracking.

---

Related Inquiries

• Learn more about Content Decay Audit: Restoring Traffic to Old Publications.
• Learn more about loss functions.