User

A user in Relewise is the person that browses the site/shop you add the Search and Recommendation to.

What the user does on a site (see Behavioral Tracking) is important, but a user can mean different things depending on if they have accepted cookies or not, or if they are logged into the website. Naturally, it is best to know as much as possible about the user to make search and recommendations better, but since it is often something we cannot control, the system needs the flexibility to work properly both in cases where we know much about the user, as well as where we are prevented from knowing as much.

Datakeys are Case Sensitive

Most datakeys in Relewise are case sensitive. Ensure that your data adheres to this case sensitivity to avoid unnecessary issues during implementation.

To learn more, click here.

Anonymous User

This is the type of user you know the least about, since they have not given consent to be tracked. Such a user is considered an Anonymous User in Relewise.

In this case, Search and Recommendations are based on the general popularity of products and content from other users, but they cannot be specifically tailored to the user.

Temporary User

A Temporary User is a profile with an ID that might change if the user decides to clear browser data or change device. For instance, if a user uses your site on a laptop and a phone they can't be identified as the same person. Temporary Users are also sometimes called Guest Users.

In terms of Search and Recommendation, such a user will have a connected experience on the same device, but might have a different experience on other devices if they have vastly different behavior.

Best practice for developers when working with Temporary Users

The Temporary User is identified by a TemporaryId.

• Use an ID that is “long-living” and classified as 1st party, e.g. cookie or localStorage.
• Make sure the ID does not change when the user completes an order .

Authenticated User

An Authenticated User is a user that has logged into your site, and as such is recognized with a unique ID by the system that uses Relewise, i.e. an e-commerce site or a mobile app. This ID can be a number, a GUID, an email address, or similar.

In terms of Search and Recommendation, these users are offered the best experience, since you can offer them consistency across devices.

Best practice for developers when working with Authenticated Users

The Authenticated User is identified by an AuthenticatedId that is very unlikely to change and will be the same regardless of whether the user logs in from different devices.

It does not matter how or where the AuthenticatedId is generated. The decisive thing is that the ID is accessible to all systems that need to call Relewise, as it is a required parameter in every request.

If possible, use an ID that is semantic and constant. For a user journey that “starts” as a Temporary User, make sure to map the Temporary ID on the first request to Relewise – this can also be done through a TrackUserUpdateRequest.

Email User

An Email user is a user who has accessed your site via a promotional email, newsletter or similar external source. Commonly, these users will be given a unique ID to track their engagement, and by including this in the UserUpdate request, you can link these users to a Temporary or Authenticated UserID. This ensures that personalization persists between platforms. The unique ID must be included in the request as an Identifier, described below. Note that due to GDPR rules, an email user's unique ID must be tracked only for users who have given consent to cookies.

Identifiers

When linking an external user ID (such an an ID generated by an email recommendation) to a temporary or an Authenticated user in Relewise, you must include the external ID as an Identifier, which is a key-value pair that describes the origin of the ID, and the ID itself.

Read more about Identifiers here.

Example of an Identifier as part of a UserUpdate request

"User": {
 "TemporaryId": "idFromCookie",
 "AuthenticatedId": "idFromLoginIfLoggedIn",
 "Identifiers": {
 "ExtID": "idFromQueryNamed:ext_id"
 } 
 }

Expanded User Data

The User Entity can contain a number of different fields, intended for a specific usecase. Each of these is optional, but can be used to expand your use of the User entity should you require it.

The expanded list of user data contains the following:

• Classification: A metadata field used to specify classifications such as the user's country of origin, the user type (B2B/B2C), etc.
• Data: Various types of Data that you might want to save on a user-level, such as a list of Favorite product IDs
• Fingerprint: Used to support fingerprinting, if this is desired. This field can also be used to exclude duplicate products in recommendations for anonymous users when batching is not possible.
• Channel: Denotes what channel(s) the user has chosen to access the site via, e.g. webshop, app, etc.
• Company: If the user is a B2B user, it may be connected to a Company Entity, which can be used for, e.g., cross-referencing user purchase behavior for the purpose of recommendations.
• Custom: A field for whatever other type of data that does not fit within any of the other data fields.