Skip to main content
Assuming you have your JavaScript agent installed and initialized, you can start analyzing visitors. This involves calling the agents get() function or its equivalent in your chosen SDK. This triggers an identification request that sends the collected browser signals to the Fingerprint Platform API and receives a response containing the visitor’s visitor ID and other metadata. This guide focuses on when and how to identify visitors on the web. To explore the JavaScript agent API further, see its API reference. If you are looking to identify mobile devices instead, see Android and iOS. The most common approaches to browser identification are:

Identify on page load

This is the simplest way to get started. Call get() (or your SDK equivalent) as soon as the JavaScript agent loads. Use the result immediately or save it for later.
HTML
Note: The code snippets in this guide assume you have already set up some kind proxy integration for Fingerprint. Proxying requests through your own domain or subdomain like metrics.yourwebsite.com instead of connecting to Fingerprint servers directly helps avoid ad blockers and increases accuracy.See Installing the JavaScript agent and Evading ad-blockers (proxy integrations) for more details.

Identify on demand

Your use case might require (or allow) identifying the visitor only when they perform a specific action. This just-in-time approach avoids using your billable API calls unnecessarily or allows you to only identify visitors when they have given the required consent. For example, to prevent account takeover, you can install the agent only on your login page and get the visitor ID just before logging the user in. We recommend always using a fresh visitor ID for sensitive actions and security use cases to minimize the potential for replay attacks.
HTML
See Optimizing the JavaScript agent to learn more about deploying Fingerprint effectively.

Response

The get() function returns a promise of a response object with the visitor ID and other metadata.
await fp.get()
// response:
{
  "event_id": "8nbmT18x79m54PQ0GvPq",
  "visitor_id": "2JGu1Z4d2J4IqiyzO3i4",
  "suspect_score": 0,
  "sealed_result": null // or BinaryOutput when Sealed Results are enabled
}
JavaScript agent response limitationsNote that the response received by the JavaScript agent is limited on purpose. Since client-side code can be tampered with, we recommend consuming Fingerprint results securely through one of our server-side integrations. The full identification event including the visitor’s Smart Signals is available through the Server API, Webhooks, or Sealed results.See Protecting from client-side tampering to learn about getting Fingerprint results securely to your server.

Linking and tagging information

The visitor_id provided by Fingerprint Identification is especially useful when combined with information you already know about your users, for example, account IDs, order IDs, etc. You can follow user actions, track logged-in devices, and recognize malicious behavior. You can pass a linkedId or tag parameters to the get() function (or its equivalent in your SDK) to associate your own metadata with the visitor ID.
HTML
  • linkedId is a string you can use to filter identification events in the Dashboard or to filter visitor history using the Server API.
  • tag is a JavaScript object of any shape allowing you to store structured metadata. It is not indexed, you cannot use it to search for events.
For more details, see Linking and tagging information.

Caching the visitor ID

If your use case demands highly accurate identification, we recommend identifying the visitor on demand and always using a fresh visitor ID without caching. Depending on your use case, you can choose to cache (store) the visitor ID in the browser to:
  • Improve the responsiveness of your application.
  • Stay within the limits of your monthly allowance of API calls.
Caching visitor IDs for extended periods can significantly reduce identification accuracy. Make sure to understand caching best practices and implications before caching visitor IDs.

Caching using JavaScript agent

JavaScript agent provides caching out of the box but is disabled by default. To use it, you need to specify the cache option when initializing the agent.
HTML

Cache expiration time

We strongly recommend a maximum cache expiration time of 1 hour. The properties (e.g. browser version, extensions, screen resolution, IP address, etc) that Fingerprint collects from a browser often change over time. When these incremental changes are captured as soon as they occur, Fingerprint can identify a returning browser with industry-leading accuracy. Using a longer expiration time leads to:
  • Lower identification accuracy. Fingerprint can miss out on the incremental changes thus increasing the risk of incorrectly identifying a returning browser as new.
  • Outdated Smart Signals information returned from the Server API.
  • Increased risk of replay attacks.

Cache location

We strongly recommend using sessionStorage to cache the visitor ID. Our data indicates sessionStorage is the best option to minimize the impact on identification accuracy compared to both localStorage and cookies.
Note: A cached visitor ID stored in sessionStorage, localStorage, and cookies will not be available if the user switches to or from Incognito mode.

What’s next