DeviceFingerprintforData-drivenDecisions

Our billing is strictly transactional, on a per-request_id basis. You only pay for processed fingerprints and fully control volume: trigger fingerprint collection for every page visitor or only for specific user actions.

It helps you recognize returning devices, detect automated behavior, and enrich risk decisions without relying solely on cookies or IPs. /// It gives you clarity on whether a returning user is legitimate or hiding behind a new identity using specific tools.

Typical use cases:
• Multi-accounting and bot detection
• Spoofing and environment tampering signals
• Session continuity across page loads
• Fraud investigation with device context

1. The website embeds a snippet and loads the Fingerprint client.
2. The runtime gathers browser signals.
3. It calculates client-side identifiers and anomalies.
4. The backend enriches the request with environment data and resolves the request and device IDs.

No. This is a proprietary solution built from scratch (client + backend) that includes:
• Server-side enrichment (IP, ISP, proxy)
• Device ID matching across sessions
• Client and backend anomaly detection
• Behavioral biometrics
• Backoffice-managed integrations

Open-source libraries typically stop at a client-only hash and exclude this full identification pipeline.

Private mode is detected as an anomaly. Because browser storage is temporary, session_id continuity may be weaker. Anti-fingerprinting features can also reduce identifier stability.

No. Changing a VPN or IP has a very low probability of breaking core device identification, while we can still link activity. Proxy / VPN signals are also available in backend fields (proxy_type, proxy_isp, and related).

Anomalies are client- or backend-detected signals indicating that the environment is automated, spoofed, inconsistent or high-risk. They are grouped into categories with boolean results, for example:
{
"ab": false,
"bot": true,
"collision": false,
"dev_tools": false,
"fp_evasion": false,
"input_anomaly": false,
"ip_manip": false,
"is_bot": false,
"locale_manip": false,
"net_anomaly": false,
"private_mode": true,
"rdp": true,
"spoofing": true,
"tampering": false,
"vm": true,
"vpn": false
}

Yes. We detect bots and automated behavior using a combination of environment checks and behavioral biometrics.

Yes. Multi‑accounting investigation is supported by stable device_id linkage across accounts combined with anomalies like private mode, spoofing, automation, and storage tampering. You define specific business rules on your backend or risk engine.

The system analyzes JS runtime anomalies, missing APIs, and automated event sequences.

Yes. Virtualized environments (like AWS WorkSpaces or VMware) expose distinct CPU instructions, generic drivers, and software rendering. Our engine flags these anomalies when requests originate from non-standard hardware.

We combine network telemetry, TCP/IP fingerprinting, and RTT analysis. Conflicts between browser settings (like time zone or WebRTC) and IP geolocation, as well as matches with known data center structures, trigger proxy and VPN signals.

Tools like Multilogin spoof canvas data and user agents. The backend flags micro-inconsistencies when signals violate physically possible combinations (e.g., an iOS user-agent with Windows rendering).

The Behavioral Biometry System collects interaction data (mouse clicks, taps, swipe/mouse data points) and sends it for analysis. It can also detect biometric anomalies for unnatural keyboard/touch patterns.

The client-side script collects only browser and device attributes. The backend then adds network enrichment (IP, geolocation, ISP, and proxy classification).

It does not directly collect personally identifiable information (PII), such as names or emails. You can link these fingerprint identifiers to your own user records, but this association remains entirely under your control and compliance obligations.

Yes. Chrome on Android and Chrome/Safari on iOS/iPadOS are covered in the compatibility matrix. Some modules may be partial or unsupported on specific platforms (e.g., browser extensions on iOS, detected apps mainly on Windows).

No. While some privacy tools may attempt to block generic scripts, our solution uses dedicated integration URLs and CDNs issued for your organization. Our fingerprinting is not influenced by AdBlock.

No. The Fingerprint client loads asynchronously and never blocks HTML parsing or page paint. Fingerprint collection runs in the background. The public methods (window.aft.sid, window.aft.dfp, window.aft.send) are async and wait for readiness with a timeout (default up to 15000 ms). They do not freeze the UI thread, unlike synchronous blocking scripts.

1. Configuration and runtime discovery start early;
2. The session_id is created/restored early, so data gathering starts sooner.
3. By the time you need the device_id or backend_response, collection is already underway.

Async loading removes the blocking render risk. Top placement is about starting early, not about running a heavy sync script. The later you insert it, the later the session, fingerprint, and device readiness arrive.

Inserting the script early ensures that by the time the business calls `send()` (login, registration, payout, etc.), the fingerprint is already collected or nearly collected. This reduces latency on the critical step. Session is available earlier and independently of `send()`.

With **AUTO_SEND**, `send()` happens as part of the normal runtime flow; device id still appears only after a successful backend response.

The processing speed depends on the user's internet connection. Our benchmarks show the full fingerprint response is typically ready in 0.5 to 1.5 seconds. Specific API wait timeouts are clearly defined in our documentation.