Identification

TRACIO's identification system generates a stable visitor identifier from 300+ browser signals. The identifier persists across sessions, incognito mode, VPN changes, and cookie clearing. This page explains the complete identification pipeline.

Signal Collection

The client collects 303 distinct browser signals across 15 categories. Each signal probes a different aspect of the browser and device, from hardware characteristics to rendering behavior. See How It Works for the per-category breakdown.

What matters for identification is not which category a signal belongs to but how stable it is over time — that is what decides whether it can carry identity.

Signal Stability Tiers

Not all signals are equally useful for identification. Signals are classified by stability:

• Tier 1 (Frozen): Hardware and rendering signals that almost never change. Canvas fingerprint, WebGL renderer, audio fingerprint, GPU parameters, font enumeration, math operations, architecture byte.

• Tier 2 (Semi-stable): Signals that change with browser updates or configuration changes. User-Agent, Client Hints, plugins, CSS media queries, storage capabilities.

• Tier 3 (Volatile): Signals that change frequently. Screen resolution (monitor changes), timezone (travel), language preferences, connection properties.

Tiered Hashing (V3)

The visitor ID is computed using a three-tier hashing system that balances stability with extensibility:

Visitor ID = [Tier1Hash][Tier2Hash][Tier3Hash]
              20 chars   10 chars   10 chars
              ────────   ────────   ────────
              base62     base62     base62

Tier 1: Identity Core (20 characters)

Tier 1 uses only frozen signals that are inherent to the hardware and rendering engine. These signals change only when the user switches to a different physical device or makes significant hardware changes.

Signals included: Canvas fingerprint hash, WebGL renderer (unmasked), WebGL vendor (unmasked), audio fingerprint, font enumeration hash, WebGL parameters hash, math operations hash, architecture byte (ARM vs x86).

Algorithm:

1. Extract Tier 1 signal values
2. Build a canonical string: key1=value1|key2=value2|... (keys sorted alphabetically)
3. Hash with MurmurHash3-x64-128
4. Encode the 128-bit hash in base62 (20 characters)

Tier 1 is intentionally frozen. New signals are never added to Tier 1, ensuring that the identity core remains stable across server updates.

Tier 2: Browser Context (10 characters)

Tier 2 captures the browser and OS environment. These signals change when the user updates their browser, installs extensions, or modifies system settings.

Signals included: User-Agent data, Client Hints (brands, platform, architecture), navigator properties (vendor, platform, languages), plugin list, screen color depth, device memory, hardware concurrency.

Tier 3: Session Context (10 characters)

Tier 3 captures volatile signals that may change between sessions. These are used for confidence scoring and fuzzy matching but do not affect the core identity.

Signals included: Screen resolution, timezone, language, DOM blockers, storage capabilities, CSS media query responses, connection properties.

MurmurHash3-128

Each tier is hashed using MurmurHash3-x64-128, a fast, non-cryptographic hash function that produces 128-bit output. The algorithm:

1. Processes input in 16-byte blocks
2. Applies multiplication and rotation operations per block
3. Finalizes with avalanche mixing (fmix64)
4. Produces two 64-bit values (h1, h2) that form the 128-bit hash

MurmurHash3 provides excellent distribution (every bit of input affects every bit of output) and is fast enough for real-time computation. It is not cryptographically secure, but that is not required for fingerprint hashing.

Input: "canvas=abc123|webgl_renderer=ANGLE|audio=0.04852"
       ↓ MurmurHash3-x64-128
Output: 0x7f4a8c2d1e3b5f6a 0x9d8c7b6a5e4f3d2c
       ↓ base62 encode
Result: "X7fh2Hg9LkMn3pQr5tBv"

That 20-character string is one tier's hash, not a visitor ID. The value your integration receives is all three tiers concatenated — 40 base62 characters.

Confidence Scoring

The confidence score (0.0 to 1.0) represents how certain the system is about the visitor identification:

Cookie Match: 1.0

When the _vid_t cookie matches a known visitor, confidence is set to 1.0. The cookie holds the visitor's UID, which the server validates against its records. This is the fastest and most reliable identification path.

First Visit: 0.90

New visitors with no prior record receive a confidence score of 0.90. There is no risk of false matching since there are no existing records to compare against.

Returning Visitor: 0.85-0.99

For returning visitors without a cookie match, the system computes confidence from:

1. Signal frequency weighting (IDF): Signals that are more unique across the global population receive higher weight. A rare WebGL renderer is more identifying than a common screen resolution.

2. Fuzzy matching: The system compares the current fingerprint against stored fingerprints using bit-level Hamming distance. Signals are grouped by tier, and each tier's match score is weighted independently.

3. Historical consistency: If a visitor's signals have been stable across multiple visits, confidence increases. If signals fluctuate frequently, confidence decreases.

Confidence Breakdown

Cookie Persistence

TRACIO uses a first-party cookie (_vid_t) to maintain visitor identity across sessions:

• Name: _vid_t
• Value: the visitor UID (a UUID; not encrypted)
• Expiry: 365 days
• Attributes: SameSite=Lax, and Secure on HTTPS (not HttpOnly — the agent reads it client-side)
• Domain: Set on the broadest possible parent domain using domain probing

The cookie is issued both server-side (via the Set-Cookie response header) and client-side by the agent, and the UID is also mirrored to localStorage as a fallback when cookies are blocked.

Domain Probing

The server attempts to set the cookie on progressively broader domain scopes:

app.example.com → example.com → com

The broadest domain that successfully sets the cookie is used. This ensures the cookie persists across subdomains.

Cross-Browser Identification

TRACIO can identify the same person across different browsers on the same device when Tier 1 signals produce matching hashes. Since Tier 1 relies on hardware and rendering characteristics (canvas, WebGL, audio, fonts), these signals are often identical across Chromium-based browsers on the same machine and degrade across engines (Chromium vs Firefox vs Safari). Matching a desktop visitor to a mobile visitor is not expected — the hardware and rendering surfaces differ.

Cross-browser matching is inherently a lower-confidence operation and is treated as such in scoring.