Guides

Generating persistent identifiers

Suggest Edits

Using unique identifiers with MCM

Identifiers are passed using the Event and Decision APIs. Customers should generate a unique identifier for web browsers in the device.persistent_id field or use the unique device identifiers for mobile devices in the device.persistent_id field. For user IDs customers should use their existing unique e-commerce user IDs inside the user_id and user.user_id fields in the API call.

📘

Note:

All identifiers passed to Moloco should be hashed. We recommend using any hash function that is not easily reversible, but customers should avoid using MD5.

Please see our Event API and Decision API documentation for more information on ID fields and API usage.

Web Apps

Persistent Identifiers

It is recommended to persist generated IDs and the unique device (mobile or web) IDs in a first-party cookie or browser local storage. This means that once a session is created, it should be stored in a way that the browser can remember it across multiple page views or even site visits. Maintaining stable user and device identifiers is essential for Moloco's attribution and machine learning algorithms to function effectively, especially for logged-out users on the web.

Checking for Existing Session IDs

Before generating a new session ID, check for an existing one. This helps in maintaining a consistent session across different interactions without creating unnecessary new session identifiers.

Avoiding New Session ID on Refresh

Do not generate a new session ID for every browser refresh. This is important to ensure that the session remains stable and identifiable throughout the user's interaction with the site.

Mechanisms for storing identifiers

Browser Local Storage

Local storage is a mechanism provided by browsers for storing data on the client side. Data stored in local storage persists even after the browser is closed and reopened. However, these storage mechanisms are limited to the specific web browser on the specific device. User and device identifiers can be stored in local storage for persistent identification of users and devices across browser sessions.

Please see these links for more information:
https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API
https://developer.chrome.com/docs/devtools/storage/localstorage
https://support.mozilla.org/en-US/kb/storage

First-party cookies

These cookies are typically used to enable essential website functions such as session management (keeping users logged in or tracking logged out users), storing user preferences, tracking user interactions, and providing personalized content or recommendations.

Privacy Implications

All browser storage mechanisms including local storage and cookies are subject to the browser's privacy settings and regulations like GDPR. They are often associated with concerns about tracking and user privacy. Browser local storage is generally considered more private than cookies because it's not automatically sent with every request. However, first-party cookies can still be used to track user behavior within the context of a single website.
The decision to use first-party cookies vs local storage will depend on your architecture. For example, customers who heavily rely on client-side rendering, local storage may be a more convenient option. If using both local storage and first-party cookies, the first-party cookie is accessible from both the client and the server side.
Using the "HttpOnly" attribute for first-party cookies is a security measure aimed at mitigating the risk of cross-site scripting (XSS) attacks. When a cookie is set with the HttpOnly attribute, it instructs the browser to restrict access to the cookie through client-side scripting languages such as JavaScript. This means that the cookie can only be accessed and manipulated by the server and is not accessible to JavaScript running in the browser.

Apps on Mobile Devices

Both Apple iOS and Android provide methods for storing data as well as unique identifiers for the device and app. Moloco requires the fields user.user_id and device.persistent_id for mobile devices.

For app traffic, a unique identifier for a device should be used in both the Event API and the Decision API calls. Customers can issue a unique identifier for a device, or use the App set ID on Android or IDFV value for an iOS app.
On the mobile app, the value for this parameter can be clearly defined. These values should be less privacy-sensitive since these are unique ID types within the same vendor’s Apps. Please see the links below for more information.

CDP/MMP and Analytics Tools:

Customers can retrieve ID generated from a 3rd party library (as long as ID is long-lasting and uniquely identifiable) and use it as the device.persistent_id value. Customers can use the persistent ID that is already passed to 3rd party libraries.

🚧

Caution:

When using a CDP, the retrieved ID for the Decision API requests should match with the ID for User Events from the CDP integration.

Updated 5 months ago