Device ID persistence: test recognition and collisions

Device ID persistence describes recognition across repeated observations under a defined scope. A useful test also measures whether separate devices are incorrectly merged. Evaluate persistence and collisions together: a system that recognizes every visit by assigning one identifier would have perfect repetition and useless separation.

Use known devices, recorded conditions and legitimate controls. Keep a changed identifier, an incorrect match and an unavailable result as three different outcomes. This makes your results interpretable when browser storage, network routes or software versions change.

Define the unit before repeating a visit

Write down what the product is intended to recognize. The scope might be a browser, a device under supported matching conditions or a provider-specific visitor concept. Do not assume that identical labels from two products describe identical relationships.

The FingerprintJS repository distinguishes its client-library approach from hosted Fingerprint identification. Inspect the selected version and service before comparing persistence. A local browser identifier should not silently become a claim about a physical person or universal cross-browser recognition.

Also define the observation window. A result repeated within a short session and a result recognized weeks later answer different operational questions. Preserve the provider, client version and plan so future tests can explain a change rather than rewriting the earlier record.

Build a small case ledger

Give your own test devices private labels, such as Device A and Device B. Keep the ledger in your controlled environment. The labels establish ground truth for the pilot; they are not product-generated identities.

Start with a few cases that you can reproduce. Increasing the request count before checking the ledger can multiply an ambiguous experiment. A thousand retries from one environment are not a thousand independently known devices.

Change one condition at a time

Test normal storage, a private window, a permitted storage reset and a network change as separate cases. Where a provider supports more than one browser or native client, use a separate test group for each scope. Do not aggregate different channels before confirming that the identifiers are meant to connect.

Record legitimate causes of change, including a browser upgrade or changed display configuration. Keep intentional test modifications separate from naturally occurring changes. That distinction helps the integration owner understand whether a split reflects the planned condition, collection failure or a different client configuration.

The Fingerprint playground and open-source demo can provide a first look at repeated outputs. Use the appropriate service and documented access for a production evaluation; the two demonstrations are not equivalent products.

Count false splits and false merges separately

A false split occurs when a known same-device relationship is not recognized under the tested matching scope. A false merge occurs when known distinct devices are incorrectly associated. Keep denominators explicit: same-device test cases for splits, distinct-device comparisons for merges.

Report availability separately. An unfinished collection should not count as a clean result, a new device or a correct rejection. If you exclude unavailable cases from one performance rate, publish the excluded count in the internal evaluation record so the integration impact remains visible.

Matching confidence can help interpret a result but does not replace the ledger. A high-confidence incorrect association is still incorrect for the known test relationship. A low-confidence output may be operationally useful if the workflow handles it appropriately, but that is a separate application outcome.

Interpret uniqueness cautiously

EFF Cover Your Tracks examines browser tracking and fingerprintability. Its privacy perspective is useful for understanding exposed characteristics. A uniqueness result in a test population does not measure your hosted service's long-term recognition or account-fraud performance.

Likewise, a distinctive browser configuration is not an authenticated identity. Avoid connecting private customer records to a public diagnostic merely to create a more impressive test. Use only environments and data you are authorized to inspect.

For a new implementation, retain a minimal repeatable test suite that can run after relevant client or SDK updates. Preserve the old results with their conditions. That creates a useful regression record without implying that a single pilot guarantees permanent recognition across future browser changes.

Work through a small split-and-merge example

Suppose Device A repeats ten permitted test visits. Nine produce the expected association and one produces a new identifier. Before calling that last result a false split, inspect whether the collection completed and whether the changed condition belongs to the supported matching scope.

Now inspect a separate Device B.

If B incorrectly receives A’s association, record a false merge against the known distinct-device case. Keep this finding beside the repetition results. It may carry a different consequence: asking A for another verification and connecting B to A’s private account history are different application failures, even if both start with a matching error.

Turn the results into a buying decision

Choose tolerances based on the protected workflow. A false merge that connects unrelated accounts can have a different consequence from a split that asks a legitimate user to complete another verification. Record the operational effect alongside matching performance.

Use the platform comparison to inspect scope and the evaluation guide to add integrity, account context and user outcomes. Recognition is one layer of a broader assessment; keep its performance visible on its own terms.

FAQ