Device ID

About Device ID

Volterra/Shape Device ID is a real-time, high-precision device identifier that utilizes advanced signal collection and proven machine learning algorithms to assign a unique identifier to each device visiting your site. Deployment is simple, with immediate benefits for the security, networking, fraud, and digital teams. Never has understanding the unique devices visiting your applications been so easy.

Device ID leverages Device ID JavaScript (JS) for the data collection. Device ID JS is a lightweight JavaScript deployed asynchronously on the web pages of the application. This JS collects all the required data fields, makes a client-side API call, the unique device identifier is generated, and a response is sent back. The response contains two identifiers that are written in the cookie, and the origin server can consume this cookie.

Volterra recommends deploying Device ID JS on all the web pages of your application.

The diagram below shows the basic data flow for Device ID.

did hl arch
Figure: Basic Data Flow for Device ID

Device ID Data Flow

  1. During page load, Device ID JS is loaded asynchronously to collect all the required telemetry with minimum performance impact.
  2. Device ID JS sends an API request with telemetry to the Device ID service on the Volterra cloud. The device identifiers are computed on the Volterra cloud and sent back to the client in the API response.
  3. Device ID JS writes the response in a cookie.

Device ID Dual Identifiers

Volterra/Shape Device ID includes two identifiers – a residue-based identifier and an attribute-based identifier. The residue-based identifier is based on local storage and cookies. The attribute-based identifier is based on signals collected on the device. The two identifiers always have different values.

The residue-based identifier will change whenever local storage is deleted, such as when a user clears cookies. We expect this identifier will have lower persistence and hence high divisions, that is, the same device might appear to have different residue-based identifiers over time. On the other hand, because the residue-based identifier is a sufficiently long random string, there is nearly no chance of collision (that is, when one identifier is shared by more than one device).

The attribute-based identifier, based on signals collected from the device, is more persistent in that it will remain the same even when the user clears local storage. However, the attribute-based identifier could change when certain events occur such as a browser update, configuration change, or hardware change. Device ID continuously strives to base the identifier on the most persistent of signals, those least likely to change.

The attribute-based identifier, however, does not guarantee persistence. It is possible for two devices to share an attribute-based identifier if the devices are sufficiently similar. Again, Shape performs continuous research to collect signals that will minimize collisions.

All device identifiers, no matter the vendor, will have the problems of collision and division. Our constant research into signals, its massive data set, and its advanced AI enables us to minimize these undesired traits to offer the very best identifier.

The Device ID JS writes both the residue-based and attribute-based identifiers in a single, first-party cookie called _imp_apg_r_. The _imp_apg_r_ cookie is URL encoded with the following format:

%7B%22diA%22%3A%22AT9cyV8AAAAAd60uXCtYafPTZGLaVAku%22%2C%22diB%22%3A%22ASJ4gFmzPo%2Fa8AHJceWhykudRoXeBGlP%22%7D

This cookie can be decoded via: https://www.urldecoder.org/ to get the response in clear text. The decoded cookie has the following format:

{ 

 "diA": "AT9cyV8AAAAAd60uXCtYafPTZGLaVAku"
 "diB": "ASJ4gFmzPo/a8AHJceWhykudRoXeBGlP"
 
}

Here, diA represents the residue-based identifier and diB represents the attribute-based identifier.

Note: The cookie name _imp_apg_r_ is non-configurable for the initial phase of the offering.

The table below gives an example of a user’s browser journey and how it impacts the two identifiers.

Note: In the table below, the residue-based identifier and attribute-based identifier usually remain the same when moving from one user event to the next. This is due to the refined Device ID engine logic that can determine the Device ID has not changed despite changes in user events.

User Event Residue Based ID Attribute Based ID Remarks
1. First visit of a device (browser) abc 123 A residue added on the fly
2. Returning visit of a device (browser) abc 123
3. User changed to private mode abc 123 Will persist for most cases
4. User switched back to normal mode abc 123
5. User switched network/wifi (e.g., from work to home) abc 123
6. User cleared browser history abc 123 Will persist for most cases
7. User’s browser got auto-updated to a new version* abc 123 Will persist for most cases
8. User manipulated one of the device attributes used by Device ID def 456

References