Fingerprint competitors and alternatives

The alternatives, briefly

Kaidn compared with Fingerprint

High-accuracy identification of a returning browser or device, with signals like VPN, bot and tamper detection alongside it.

Fingerprint does one thing extremely well: tell you that this browser is the same browser you saw before, accurately, and across deliberate attempts to prevent exactly that. It is a specialist tool, and specialists are usually better at the thing they specialise in.

We are not trying to beat them at device identification. We use it as an input.

Different unit of output#

Fingerprint returns a visitor ID plus Smart Signals: VPN, bot, browser tamper, proxy, jailbroken device, iOS simulator. You take those and decide what they mean.

We return a verdict. The device signals go in alongside the IP, the email, the phone, the velocity and the cross-operator graph, and what comes out is allow, review or block with the checks that fired and their weights attached.

If you want an identifier, they are the better tool. If you want a decision, that is us. Several teams reasonably run both, and that is a coherent architecture rather than a hedge.

Both of us return a confidence figure, and you should read ours#

Fingerprint returns confidenceScore on the visitor ID, which is 1 - falsePositiveProbability. That figure exists because everyone serious in this market knows the same thing: a raw browser fingerprint is an attribute hash, and attribute hashes collide. A default iPhone really is identical to another default iPhone.

We return the same class of number under a different name. Every scored event carries a resolved_id, the rung that produced it, and a collision_risk: the measured probability that the identity covers more than one natural person.

The numbers are measured on production traffic rather than modelled: 2.30 people per raw fingerprint on iOS Safari falls to 1.27 once the network is folded in, and 1.53 to 1.14 across all traffic. We publish the ones that do not flatter us too. iOS Safari lands at 0.21 even after that improvement, which is why an iOS Safari identity is never allowed into the cross-operator graph.

This is the honest version of the comparison. Fingerprint is better at rung 2, because a decade of work on probabilistic identification is exactly what rung 2 is. At rung 1 the two products do the same thing, because a signed cookie replayed by your own server is not a research problem. The question is which unit of output you want around it. Full mechanics in the device identity docs.

What the plans buy#

Their free tier is 1,000 API calls a month, with Pro Plus at $99 a month for 20,000 calls and $4 per additional 1,000. Ours is 10,000 events free and $99 for 250,000.

It is not quite like for like, because a Fingerprint API call is an identification and a Kaidn event is a scoring decision across every signal we hold. But the shape matters: their marginal cost above the bundle is meaningful at volume, and collection on our side is free because we bill the decision rather than the fingerprint.

Reading the identity, not just the id#

Both products hand back an identity and a number saying how much to trust it. The part teams skip is branching on the number. A scored event carries the rung that produced the identity and its measured collision risk, and a device-reuse verdict on a rung 3 identity does not deserve the same treatment as one on rung 1:

{
  "verdict": "review",
  "reasons": ["device_reuse"],
  "device": {
    "id": "8f1c2ae9d4b7c3e05a1f6b28d9074e3c",
    "resolved_id": "d2c1f0a7b93e4d5681ca07f4e2b91d38",
    "resolution": "probabilistic",
    "resolution_rung": 2,
    "collision_risk": 0.21,
    "account_count": 3,
    "account_count_same_network": 1
  }
}

const r = await kaidn.score({ event: "cashout", user_id, ip, email, device_id });

// A device link on a high-collision identity (iOS Safari sits at 0.21 even after
// the network is folded in) is a hint, not a finding. Corroborate it before acting.
const deviceOnly = r.reasons.length === 1 && r.reasons[0] === "device_reuse";
if (deviceOnly && (r.device?.collision_risk ?? 0) > 0.15) return allowWithFlag(r.event_id);

if (r.verdict === "block") return deny(r.reason_text);
if (r.verdict === "review") return hold(r.event_id);

account_count_same_network is the corroborator worth reading next to it: three accounts on one device across three different networks is a much weaker claim than three on the same one.

This is the same discipline confidenceScore exists for on their side. The failure mode it prevents is real and expensive: banning a cohort of ordinary iPhone users because their fingerprints agree with each other.

Running both#

Several teams should, and the wiring is undramatic. Their visitor id becomes the device_id on the scored event, so you keep their identification accuracy and get a verdict around it:

import { load } from "@fingerprintjs/fingerprintjs-pro";

const fp = await (await load({ apiKey: PUBLIC_KEY })).get();

// hand their visitorId straight to the scorer as the device identity
const { verdict, reasons } = await kaidn.score({
  event: "signup",
  user_id: user.id,
  ip,
  email: user.email,
  device_id: fp.visitorId,
});

Nothing in the scoring engine requires the id to have come from @kaidn/fp. If you already pay for better identification, use it.

Where we would send you elsewhere#

Their identification accuracy has years of focused engineering behind it, and if a returning-visitor ID is genuinely the thing you are buying, buy theirs. If you need native mobile, buy theirs. And if budget is the constraint, the open-source FingerprintJS is free and may well be enough.

The constraint both of us share#

We ran both engines side by side on the same page loads and published the numbers, including the ones that do not flatter us. Two findings worth reading before you choose either product: their agent did not execute at all on 21 of 24 privacy and anti-detect browser sessions, because EasyPrivacy and EasyList carry rules for their domains; and on a clean same-operating-system anti-detect profile, neither engine caught the session.

Full data, method and limitations: what a fingerprinting vendor sees when the browser blocks its agent.