How to detect multiple accounts from one person.

To detect multiple accounts from one person, link your accounts by something the person cannot change for free. Email addresses, usernames and even phone numbers are cheap to replace, so they make poor evidence on their own. The device behind each signup and login is far harder to swap, which is why a stored device identifier is the backbone of multi-accounting detection.

This guide is about finding duplicate accounts you already have and catching new ones as they appear, including sockpuppet accounts in communities and repeat offenders returning after a ban.

#What does multi-accounting look like in practice?

It looks like one operator wearing many faces. A gamer opens extra accounts to farm a welcome bonus. A seller posts fake reviews from accounts that are all theirs. A banned user returns under a new username to evade the ban. A community member runs a handful of sockpuppet accounts to make an opinion look popular. In every case the accounts look unrelated, with different emails and names, while the device behind them stays the same.

Not every case is abuse. Families share a tablet and people use a work laptop and a phone. A rule that treats every shared device as fraud will hurt real customers, so the goal is to find clusters worth a human look rather than to ban on a match.

#How do you link accounts to a device?

Run an identification at signup and at login, and store the returned visitor ID with the account. With Fingerly, the visitor ID is issued once for a device, recognised on later visits, and stays the same when cookies are cleared, a private window is opened or the network changes. The identification also says whether the device is new to your organisation and how confident the match is, on a scale from 0 to 100.

Read the event on your server with a secret key, not in the browser, and keep the visitor ID in your own database. Fingerly returns the identifier but does not keep your account graph. Once the ID sits beside every account, the accounts that share a device are one query apart. A visitor ID names a device, not a person, and it is scoped to your organisation, so it cannot follow someone across companies.

#What steps find existing duplicate accounts?

Start with the identifiers you already have and work towards clusters. A workable sequence:

• Add a visitor ID column to your accounts table and fill it at every signup and login from now on.
• Count distinct accounts per visitor ID over a window such as 30 days, and list the devices above a threshold that fits your product.
• Join those clusters with your own data: payment methods, phone numbers, delivery addresses, referral links and password reset emails. Two shared links beat one.
• Look at the behaviour inside each cluster: accounts that vote, review, claim rewards or message each other are more suspicious than accounts that never interact.
• Add the device context from the event: automation findings, emulators, cloned apps or tampered browsers inside a cluster strengthen the case.
• Send clusters to a reviewer with the evidence attached, and record the decision so the next case is consistent.

Events can be read through the API for 30 days, including the events for a single visitor ID in a window you choose. For connections over a longer period, rely on the visitor ID you stored at account creation, and keep your own copy of any events you may need later, for example by receiving them through webhooks.

#How do you catch new duplicates and ban evasion?

Check at the moment of signup and decide before the account exists. If the device already holds several accounts, or belongs to a banned account, treat the new signup differently. For ban evasion, store the visitor ID of every account you ban and compare each new signup against that list.

• Banned device: create the account on hold, or require verification before it can post or claim anything.
• Many accounts on one device: allow the signup but withhold free benefits until a verification step passes.
• New device with a high suspect score: send it to manual review.
• Returning device with a low score: allow it through with no friction.

Fingerly never asks the visitor for anything and does not block anyone. It returns evidence, and your application decides, so each of these actions lives in your own code and you can change it without an app release.

#What about sockpuppets, Sybil attacks and fake reviews?

They are the same pattern in another costume. A sybil attack is one actor posing as many to gain influence, and a sockpuppet network does it in a community. The detection idea is the same: many identities, few devices. Count identities per device, and weigh heavily the clusters that interact with each other, such as accounts that upvote, follow or review one another from the same device.

Serious operators try to look like many unrelated customers by using emulators, modified browsers or farms of devices, and Fingerly reports those as evidence next to the device count. On mobile, the identity is a random ID created for the app installation, so a determined person with many phones will look like many devices; combine the device view with the other links in your own data rather than expecting a single answer.

#How do you avoid punishing households and shared devices?

Prefer verification and review to outright refusal. Two accounts on one device is rarely abuse and twenty is not a household, so set your limit by product, read the count with the other evidence, and keep an appeal route. A shared computer in a library or a lab will cluster legitimately, and a customer who is refused should be able to find out why and ask for a second look. Say in your terms that limits are applied per device.