Identify a User Without Cookies

How to use DFP data to identify users when cookies are unreliable or cannot be used.

The Problem We Solve

Suppose you need to understand that the same user or the same device is interacting with your service. For example, you may need to:

  • count how many unique users saw an advertising campaign;

  • understand that one person completes the same survey several times;

  • find client devices whose activity on your resource is unwanted;

  • identify a user even when they return to the website from incognito mode.

Cookies are usually used for such tasks. But cookies are not always suitable: a user can disable or clear them, or visit in incognito mode. As a result, the same person can look like several different visitors.

You can also use an IP address, user agent, JA3/JA4, and similar signals. But these do not always help either. An IP address can be dynamic or hidden behind a VPN. A user agent is often the same for different users. JA3/JA4 describe network connection parameters, but they do not always describe the client environment accurately enough.

DFP provides a more reliable value: user_id. It is a persistent identifier of the client environment. It describes a browser-device pair and is resilient to changes. For example, if the user:

  • enables incognito mode;

  • enables a VPN;

  • updates the operating system;

  • changes the time on their computer;

  • updates the browser version.

user_id stays the same if the browser and device are the same.

As a result, user_id becomes a more accurate marker that you can use to calculate the metrics you need: unique users, repeated actions, or unwanted activity.

How to Configure User Identification Without Cookies

Preparation

Integrate DFP with your website by following the integration guide.

Backend Configuration

1. Decrypt the DFP response.

2. 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. The frontend must call DFP again, receive a fresh payload, and send it to the backend. If it cannot obtain a fresh payload, do not use this result to identify the user.

3. Get user_id from the DFP response.

4. Find records with this user_id in the database.

For this scenario, it is important to store records with an indexed user_id. The backend can then quickly find all events related to the same client environment.

For example:

Event user_id

visit_71a2

user_4b8c21

survey_answer_19d4

user_4b8c21

ad_click_83f1

user_91f03d

5. Process the request according to the database search result:

  • If records with this user_id already exist, you have seen this client environment before.

  • If no records with this user_id exist, this is a new client environment for your database. Process it as new, then store the current event together with user_id.

The next steps depend on your task. For example, if you:

  • run a survey, you can disregard a repeated response with the same user_id;

  • count unique users in an advertising campaign, you can treat several actions with the same user_id as activity by one unique user;

  • protect a resource from unwanted activity, you can store user_id values of devices that have already violated rules and check their later actions more carefully.

For this scenario, we also recommend considering bot_score.

High values may mean that the request is made by automation or that the user is trying to spoof client-side parameters analyzed by DFP. bot_score values:

  • Below 0.4: no automation signals.

  • From 0.4 to 0.5: a moderate automation risk. We also recommend checking hosting, bot_hosting, vpn, and incognito before making a decision.

  • Above 0.5: the request was very likely made by a bot.