# Use cases

> Where device signals help, which parts of the WhiskerJS result matter for each problem, and what your server still has to decide.

Source: https://whiskerjs.com/use-cases/ (last updated 2026-10-26)

> **In plain words:**
>
> Fraud and abuse often come down to one question: is this the same device we saw before, or a device that is trying hard to look like someone else? WhiskerJS measures the browser and device and hands you the result. It never says “fraud” or “not fraud”. These pages show, problem by problem, which parts of that result are worth looking at and what your own server has to do with them.

## The parts of a result you will use

Every use case below draws on the same four parts of one `collect()` result:

| Part | What it gives you | Read more |
| --- | --- | --- |
| `visitorId` | one 128-bit hash over the 37 stable components: an exact-match key for a browser setup | [Identifiers](https://whiskerjs.com/docs/identifiers/#visitorid) |
| `structuredId` | seven short hashes, one per signal group, so you can see which part of a device changed | [Comparing two results](https://whiskerjs.com/docs/identifiers/#comparing-two-results) |
| `integrityFlags` | names of checks that saw signs of automation or changed browser functions | [Integrity checks](https://whiskerjs.com/docs/integrity/#the-flags) |
| `binding` | your server’s nonce and timestamp, bound to the result with a digest, so an old result cannot be replayed | [Anti-replay binding](https://whiskerjs.com/docs/integration/#anti-replay-binding) |

The 47 `components` are there too, each with a status and, when not `ok`, a reason code. They let you explain a decision later and compare devices signal by signal. See [Signals](https://whiskerjs.com/signals/).

## The problems

- [Fraud prevention](https://whiskerjs.com/use-cases/fraud-prevention/): Device signals as one input among many in a fraud decision.
- [Account takeover](https://whiskerjs.com/use-cases/account-takeover/): A known account, an unknown device: spotting the change at login.
- [Multi-accounting](https://whiskerjs.com/use-cases/multi-accounting/): Many accounts from one browser setup, and setups that only look different.
- [Bonus and promotion abuse](https://whiskerjs.com/use-cases/bonus-abuse/): Repeat claims of offers meant once per person.
- [Bot and headless detection](https://whiskerjs.com/use-cases/bot-detection/): Integrity flags as hints, with their known false positives.
- [Payment fraud](https://whiskerjs.com/use-cases/payment-fraud/): Device context at checkout, beside your payment provider's checks.

## What is the same in every case

- **Signals, not verdicts.** WhiskerJS has no scoring code. A rule or model on your server weighs the result together with account history, request headers, the IP address and velocity.
- **A browser setup, not a person.** Two identical devices with identical settings can share a visitorId, and one person with two browsers has two. Treat an id as evidence about a device, never as proof of who is behind it.
- **Anything from the client can be faked.** The integrity checks catch careless tools and the binding stops replay, but a determined attacker can send a hand-made result. Never let the result alone grant access or money. See [What never to trust from the client](https://whiskerjs.com/docs/integration/#what-never-to-trust-from-the-client).
- **Versions matter.** Compare ids only within the same `signalsVersion` and `idVersion`. Store both with every id. For one release after a version bump the result also carries the previous ids, so you can link a new id to the one you stored; see [previous ids](https://whiskerjs.com/docs/identifiers/#previous-ids-linking-across-a-version-bump).
- **Privacy still applies.** Device signals can be personal data. Read [Privacy and compliance](https://whiskerjs.com/privacy/) before you deploy.

## No accuracy figures yet

None of these pages gives detection rates, false-positive rates or uniqueness figures for WhiskerJS, because none has been measured. A head-to-head measurement against other libraries has not run yet. The only observations so far are an early, small sample at signalsVersion 1 (four device and browser pairs, each kept one id across a few runs), which is not a benchmark. Measure on your own traffic before you rely on any rule.

## Questions and answers

### Does WhiskerJS stop fraud on its own?

No. WhiskerJS is a collector: it returns signals, two identifiers and integrity flags. Your server combines them with what it already knows (accounts, history, request data) and makes the decision.

### Which use case should I start with?

Start where a device signal adds something you do not already have, usually at login or sign-up. Store the result per event first, look at your own traffic, then add rules.

### Are there accuracy figures for these use cases?

Not yet. No head-to-head measurement of WhiskerJS has run, so these pages describe what each part of the result means, not how well it performs.

## Related pages

- [Integration](https://whiskerjs.com/docs/integration/): Sending results to your server, storing ids, recommended checks.
- [Integrity checks](https://whiskerjs.com/docs/integrity/): Every flag, what it means and its false positives.
- [Identifiers](https://whiskerjs.com/docs/identifiers/): visitorId, structuredId and how to compare two results.
- [Guides](https://whiskerjs.com/guides/): Add WhiskerJS to a page and verify the binding on your server.