Detect Multi-Accounting

How to use DFP data to understand whether one person is maliciously creating many accounts to bypass your service rules.

The Problem We Solve

Suppose you have a promotion or a welcome bonus. One person creates ten accounts to receive the bonus ten times.

It is usually difficult to detect such attempts by email, IP address, or cookies alone. An email address can be changed, an IP address can be dynamic or hidden behind a VPN, and cookies are easy to bypass by opening the website in incognito mode. Formally, every account looks like a new user.

DFP helps prevent this. It shows which environment an account is created from. If one person tries to register more accounts than you consider acceptable, you can reject the registration.

How to Configure Multi-Accounting Detection

On Your Backend

Preparation

Integrate DFP with your website by following the integration guide.
Based on your service characteristics, decide on an account limit for one user_id. For example:
- 1 account if a strict limit is important;
- 2–3 accounts if you allow several people to use the same device;
- another value if it is normal for your product to create more accounts from one device.

More about user_id

user_id is a persistent identifier of the client environment.

Put simply, it is an ID that describes a unique browser-device pair. The ID remains stable even when a user changes settings. For example, if the user:

enables a VPN;
opens an incognito window;
updates the operating system;
changes the time on their computer;
updates the browser version.

The ID stays the same because the device and browser are still the same.

If the user opens another browser or sends a request from a new device, you will see a new ID. This is because every browser-device pair has its own unique ID.

You can test this yourself: we have embedded the DFP widget directly on this page, and it shows your current User ID. Try opening the page from different environments and with different settings. You will see that it works exactly as described.

Backend Configuration

Decrypt the DFP response.
Check timestamp. This is important for prevention of replay attacks:
- If the response is fresh, continue to the next step.
- If the response is more than a few seconds old, reject the DFP result and do not perform the registration. The frontend must call DFP again, receive a fresh payload, and send it to the backend. If it cannot obtain a fresh payload, ask the user to try registration again.
Get user_id from the DFP response.
Check how many accounts are already linked to this user_id:
- If the number of accounts is below the limit, registration is allowed. Create the account and store the relationship between account_id and user_id.
- If the number of accounts has reached the limit, the user is trying to abuse the service. Reject the registration.

If your service assumes that users can register only manually, without automation, we recommend adding an additional bot_score filter.

You can add it as the final step in the scenario. If the number of accounts with this user_id is below the limit, do not allow registration immediately. First check bot_score:

Below 0.4: no automation signals. Register the account.
From 0.4 to 0.5: a moderate automation risk. Request an additional check, for example show a CAPTCHA.
Above 0.5: a high automation risk. Reject the registration.

On the Strictera Side

We can implement this logic for you.

We will store the relationship between user_id and account identifiers in your service. If someone tries to register more accounts from one user_id than your rules allow, DFP sends you a signal that the user is trying to bypass the limit.

We configure this mechanism individually on request. Our engineers will agree with you on the limit to use, how to send account information to Strictera, and in what format to return the result.