User Identity Persistence in Requests

Monetate identifies anonymous visitors and tracks behavior via a monetateId. This ID is generated on the first request to the platform if it's not already present and identifies a unique device or browser. In a traditional Monetate JavaScript API implementation, monetateId is set as a first-party cookie, mt.v. It persists for future site visits.

For Engine API implementations, however, Monetate generates a monetateId if no identifier is passed in the request.

Because Monetate has no way to set the mt.v cookie in an Engine API implementation, the requesting application is responsible for keeping track of the monetateId by setting the cookie or otherwise storing or maintaining the persistence of the value by other means unique to your application.

If a device ID is available that can uniquely identify the customer's device across requests, then you can alternatively include deviceId in all Engine API requests. This value then acts as a unique identifier and allows Monetate to track visitor behavior throughout the current session and across future sessions.

To summarize user identity persistence options for Engine API clients:

For hybrid implementations, ensure that you do the following:

These user identity measures allow Monetate to reconcile information collected by both the Engine API and the Monetate tag into a single unified session.

Contact your dedicated Customer Success Manager (CSM) if you need assistance with these steps.

This example of a New Visitor request has no monetateId. In the response Monetate includes it.

A monetateId is included in this example Returning Visitor request, which is mirrored in the response.

In this example New Visitor request, deviceId is passed instead of monetateId. In this scenario, it's a New Visitor request because Monetate hasn't received this deviceId before. In the response, Monetate doesn't include the deviceId but instead returns monetateId, which can be ignored in this instance.

When the same deviceId is sent again, Monetate recognizes it and classifies it as a Returning Visitor. As in the response in the New Visitor request that contained a deviceId value, Monetate doesn't include the deviceId but instead returns monetateId.

You can pass deviceId and a custom variable in a request to let Monetate know that this customer is either a new or returning visitor.

When you first send deviceId, the Engine API classifies the customer as new. When you use custom variables, you send the custom variable in addition to deviceId to ensure that new visitors are targeted.

Use the Custom variable visitors option in the Landing target type to target new and returning visitors when configuring the WHO settings of an experience.

You can also use the New visitors and Returning visitors options in the Landing target type instead of custom variables.

You can provide a customerId for logged-in customers of your application. This ID identifies someone in, for example, a loyalty program. It's associated with the identified device and allows you to use your own data that you've uploaded to Monetate in a customer dataset for targeting and context.

It's possible to have a single view of a customer across mobile, desktop, and apps as long as the customerId is the same. Doing so stitches together the behavioral data for the customer for the corresponding behavioral targets supported by a Customer View.

This setup works in Web experiences by matching on the customerId, which then guarantees that Monetate serves the same experience for customer A.

To have this same matching to happen in your Omnichannel experiences, then you must contact the Services team to set up an ID Collector. If your account already has an ID Collector set up for Web experiences, then provide the name so that it can be copied to your app accounts.

Client-side developers must take the following steps:

The Engine API responds to the request with the eligible experiences.