Prevent multiple accounts and promo abuse, one device at a time.

To prevent multiple accounts, promo abuse and free trial abuse, put your limit on something an abuser cannot reset for free. Accounts, email addresses and usernames cost nothing to create, so a limit per account stops no one. A limit per device does, because a device is the one thing an operator has a finite supply of.

This playbook covers how to count per device with Fingerly, where to check, what a starting policy looks like, and how to stay fair to households that genuinely share a phone.

#Why do per-account and per-email limits fail?

Because the thing being limited is free to replace. A first-order discount meant for one customer gets redeemed on ten new accounts. A referral reward is claimed by referring yourself. A free trial starts again every month under a fresh address. Each account looks new, with a new email address, yet the device behind them usually is not.

More determined operators reach for modified or anti-detect browsers and for emulators to look like many unrelated customers. Fingerly reports those too, as evidence you can weigh next to the device count.

#How does a visitor ID help you prevent multiple accounts?

Every identification returns a visitor ID for the device behind the session. It is issued once, recognised on later visits, and stays the same when cookies are cleared, a private window opens or the network changes. The SDKs write nothing to the browser, so there is nothing for the visitor to clear.

The response also says whether the device is new, how confident the identification is on a scale from 0 to 100, and whether it was identifiable at all. A visitor ID names a device, not a person, and it is scoped to your organisation: the same device visiting another Fingerly customer is a different visitor there.

#Where should you check?

Check wherever being many customers pays off, and bind each identification to the action with a tag.

• Signup, before the account exists, with a tag such as signup.
• Trial or free allowance activation, if it is separate from signup.
• Coupon redemption, with the code in the tag, so a request ID from a harmless page cannot be spent on a promotion.
• Referral reward claims, so you can compare the claiming device with the referrer’s.
• Payouts and withdrawals, where a connected cluster of accounts turns into a loss.

#How do you enforce one redemption per device?

Read the event on your server with a secret key, then enforce the limit in your own database. Fingerly returns the visitor ID; it does not keep your counters, so store the visitor ID with every account, trial, order and redemption.

For promotions, add a unique index on the promotion and the visitor ID, so two redemptions racing each other cannot both succeed. For signups, count accounts per visitor ID over a window you choose. A starting policy from the Fingerly docs:

• The device created three or more accounts in 30 days: refuse, or create the account without its free benefits.
• Device farm, emulator, cloned app or automation findings: create the account on hold for review.
• The device already has an account, or the level is above low: ask for verification, such as a phone number, before granting benefits.
• The device hides too much to be identified, or identification failed: ask for verification, because the device cannot be counted.
• Otherwise: allow.

#What about shared devices and households?

Shared devices are ordinary, so prefer verification and review over outright refusal. Families share a tablet, shops share a till and students share a lab computer. Two accounts on one device is rarely abuse; twenty is not a household. Choose a limit that fits your product and read the count together with the other evidence.

Many accounts on one device is far more telling when that device is an emulator, a cloned app or part of a device farm. On the cross-device side, Fingerly counts distinct similar devices behind one network and compares them with your own traffic, after learning for seven days. Tell customers in the promotion’s terms that the limit is per device, so a real customer who is refused knows why.

#How do you investigate accounts after the fact?

Because the visitor ID is stored with each account, the accounts that share a device are one query away. Use it when you ban an account, to review its siblings, and when you look into abuse after it happened.

Events can also be read through the API for 30 days, including a list for one visitor ID in a window you choose. To connect accounts over a longer period, rely on the visitor ID you stored when the account was created, and keep your own copy of the events you may need later, for example through webhooks.

#How do you roll it out without hurting real customers?

• Observe first. Log the decision the policy would have made next to what happened, for a week or two.
• Tune. Look at the sessions it would have stopped and adjust risk weights and your own limits.
• Enforce gradually. Turn on friction a real customer can pass, such as verification, before you turn on refusals.
• Keep an appeal route, and measure how many legitimate claims the rule touches before tightening it.