Planning your implementation

Before adding Fingerprint to your platform, it’s important to plan how you’ll use device intelligence to meet your needs. Fingerprint gives you the data, but you decide how to use it. It’s flexible and easy to integrate, but you’ll need to figure out where to apply it and what actions to take based on the insights. This guide covers the key steps to consider for a smooth implementation.

​

Assess key device intelligence touchpoints

To make the most of Fingerprint, it’s important to know where it will be most useful on your platform. Are you focusing on stopping fraud or improving user experiences? Begin by finding the pages or actions on your site that need visitor identification. These are usually places where sensitive actions happen or where it’s important to understand user behavior. Common areas include:

• Entry pages: Recognize anonymous visitors before they identify themselves, which supports personalization and gives you earlier context on who is using your site or app.
• Login pages: Protect against account takeover and credential stuffing by recognizing known visitors without friction while reserving step-up authentication for unfamiliar or suspicious ones.
• Signup pages: Catch repeat sign-ups from the same device or automated signups from bots, and block registrations from devices you have already banned.
• Transactions and checkouts: Catch payment fraud and card testing at high-value moments, and keep the device record as chargeback evidence.
• Account updates: Re-check the device when someone changes a password, email, or payout details.

Decide how you want to treat AI traffic at each of these touchpoints. Fingerprint can detect AI agents and assistants and expose their identity verification status, so you can allow verified agents while applying custom logic to unverified or spoofed traffic. You will also need to decide when and how often to make identification requests. The general best practice is to identify on demand, when the visitor takes the action you care about, rather than on every page load. For sensitive actions like logins, sign-ups, and payments, always identify visitors in real time, but for lower-risk activities, caching the visitor ID can help to avoid unnecessary API calls. However, frequent identification is important for maintaining accuracy, as it allows small changes in browsers and devices to be noticed over time. Additionally, consider common patterns that apply to most sites and might also apply to your environment. These include comparing current and past visitor IDs to check if users are returning. You can also count visitor IDs linked to a single user to detect account sharing or unauthorized access. Another option is to check how many data points, such as account or transaction IDs, the visitor ID links to. Use these patterns to understand where visitor identification fits your platform’s needs. An easy way to support these patterns is to link Fingerprint’s visitor IDs to identifiers you already have. You can do that within your own data stores or by passing a linked ID and tags with every identification request.

​

Establish baselines for visitor behavior

Next, you should analyze your visitor traffic to understand what normal behavior looks like for your platform. You can do this by analyzing your current general analytics data, or by adding Fingerprint to a few key pages and identifying visitors without acting on the results, so you start collecting identification data right away. For example, is it normal for many devices to access a single account? If so, how many devices is typical? Do most users log in from the same device every time? Knowing these baselines helps you understand what’s normal and know when to raise red flags. The Fingerprint dashboard is a quick way to get oriented: the Overview page shows usage and unique visitors, while the Smart Signals page shows how often each Smart Signal fires. You can also export identification events to CSV or use the Server API to analyze them in your own tools. For deeper analysis, store identification events in your own systems, alongside the outcomes you already monitor, so you can join them together and look for real patterns. Consider what device characteristics are more unusual for your users. For instance, if most of your users don’t use VPNs or incognito mode, you may consider those behaviors as risky. Other signals worth checking your traffic against include residential proxies, anti-detect browsers, rare device configurations, and, on mobile, rooted or jailbroken devices and emulators. One way to evaluate these signals is to use Suspect Score, which rolls them into a single risk value. Once you have collected identification data, you can label past identifications with your own fraud outcomes, upload that to the Fingerprint dashboard, and get scoring weights tuned to your traffic, showing which signals actually predict fraud for you.

​

Define responses for flagged activity

After you understand what normal and suspicious behavior looks like on your platform, the next step is to decide how to respond. Having a range of responses based on the level of risk helps balance security with user experience. Based on the data you get from Fingerprint, here are some options:

• Allow the action: For visitors with no signs of suspicious behavior, allow the action to proceed without adding extra steps, like MFA. This keeps the experience smooth for legitimate users.
• Add extra friction: If something seems off, you can add steps to verify the action. For example, if a user tries to make a purchase from an unfamiliar device, you could send a one-time passcode before completing the transaction.
• Block the action: Stop the action completely for high-risk behavior, like a malicious bot trying to change account settings. This helps prevent unauthorized access or fraud.
• Manual review: In some use cases, it may make sense to flag the activity for manual review. This allows your team to look into the situation before making a final decision.

​

Prepare for data storage and system integrations

When implementing Fingerprint, plan how to store, manage, and integrate the IDs and device signals it provides. Fingerprint only retains visitor history for a limited time, ranging from 30 days to 90 days or longer, depending on your plan. In the dashboard, identification events are available for 3 months, and aggregate statistics are available for 12 months. Decide if this works for you or if you need to store the data longer in your own data storage. Decide up front how you will measure whether Fingerprint is working, so you can tell what to adjust later. Set clear metrics, like the number of account takeovers prevented or fraudulent purchases stopped. Tie those to business impact where you can, such as the revenue recovered from fewer false positives or the support hours saved. Review these metrics often to adjust your logic and rules. For more guidance on ways to analyze Fingerprint data and outcomes, see Test 3 from How to evaluate fingerprinting accuracy in the real world. Consider how Fingerprint data will fit into other systems. This might mean sending device signals to your Web Application Firewalls (WAFs) or fraud detection models. Look for areas where Fingerprint can improve security or enhance the user experience. If your team investigates fraud by hand, the MCP server connects your identification data to AI assistants, enabling them to query event data and investigate suspicious activity in natural language.

​

Map out installation and API usage

A quick way to get started is the Fingerprint CLI. Run npx fingerprint from your project root, and it will sign you in, detect your frontend and backend frameworks, provision your API keys, and write the integration into your code one step at a time. To integrate manually, add the JavaScript agent to your website’s frontend code, either through the CDN or an SDK for your framework. For mobile apps, there are SDKs covering both native apps and multi-platform frameworks. From there, choose how to safely get Fingerprint results to your server: the Server API, Sealed Client Results, or Webhooks. The Server API can be accessed directly or through one of the backend SDKs. Requests should be made from a backend server that can securely store and access secret keys. With Sealed Client Results, you get a fully encrypted response payload from the JavaScript agent or mobile SDKs. This payload contains the same data available through the Server API, so you can skip the extra API call and decrypt it on your backend to reduce latency. Fingerprint can also send you identification data using webhooks. If you choose this option, you’ll need to create an endpoint on your server to receive and handle these webhook events. Webhooks provide a great way to store the full historical record of your event data. You should also decide where your response logic lives. You can choose to write it directly in your application code, or you can use the Rules Engine. The Rules Engine lets you define rules in the dashboard and returns a rule action for each identification event, so your fraud team can adjust them as needed without waiting for a code change. The Rules Engine decides the outcome, but your application applies it. If your site runs on Cloudflare, Flow goes a step further by deploying a worker that handles the identification setup described above, with little to no changes to your application code. You can pair it with a ruleset to enforce your rules at the edge, or run it on its own to collect identification data without taking any action.

​

Choose an ad blocker evasion strategy

To ensure you can properly identify all visitors to your site, it’s important to prevent ad blockers from blocking identification requests. You can set up a custom subdomain pointing to Fingerprint’s infrastructure to reduce request blocking. You can also use one of the available cloud proxy integrations for Cloudflare, Akamai, CloudFront, and other cloud providers. Both methods protect identification requests from getting blocked by proxying them through your own domain.

​

Getting started

Ready to get started now that you’ve planned out your implementation? Fingerprint support is here to help you take the next step. Get started with identifying browsers and mobile devices, or explore the demos to see Fingerprint in action. You can also review the use case tutorials for step-by-step implementations of common fraud scenarios. Here are a few to help you hit the ground running:

• Account takeover
• Chargeback dispute
• Web scraping