Best Practices for Behavioral Tracking

Relewise relies on knowledge of user behavior to personalize the experience. Setting up behavioral tracking is essential to ensuring a good integration of Relewise into your website.

Behavioral tracking is ideally set up before you implement the Search and/or Recommendations services to your site. This gives the system the opportunity to "warm up the engine", and ensures that you will be seeing personalized content from day one of your service implementation.

User tracking consists of a few parts:

• A User ID (if the user is non-anonymous)
• The event being tracked
• The Entity ID of the event being tracked

var productView = new ProductView(
    User.ByAuthenticatedId("usersAuthenticatedId", "usersTemporaryId"),
    new ProductAndVariantId("product-1")
);

Best Practice for tracking users

Tracking User data is contingent on the user having accepted or rejected tracking cookies on the website. To ensure that your site is GDPR-compliant and sorts properly between users who have agreed to being tracked and those who have not, you may wish to integrate to an external provider of GDPR compliancy solutions. For examples on how to integrate these services into Relewise, refer to our examples page.

To get the most out of your Relewise integration, you should familiarize yourself with the different types of users that Relewise operates with. You can read about them in this article.

We recommend that you store your Users' Temporary ID somewhere persistent, such as on local storage or in a persistent cookie. It is important that this ID does not change when the user closes and reopens their browser.

With Temporary User IDs stored locally, Relewise is able to connect Temporary IDs and Authenticated IDs via tracking requests. When a user logs into an authenticated user, you should perform a UserUpdate request to immediately link the temporary and the authenticated user together. As a rule, ensure that you use AuthenticatedIDs that are constant, ideally a GUID.

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.

User Classifications

Relewise supports user classifications, which allow you to segment your users without the need for separate datasets.

Segmentation can be done based on any key which is determined to be a good segmentation-key for your customers.

A common example is using the customer's Country as segmentation to better adjust Relewise's personalization, in order to faster understand the country-specific preferences of customers in different countries..

The classification itself is done as part of the user object, and must be included in every behaviour trackings, search request, and recommendation request made to the Relewise API.

Exampleof User Classification

user.Classifications["Country"] = "DK";

We strongly urge you to reach out to us at Relewise to discuss it if you wish to use some type of classification other than country or language. We will be able to help advise you on the best implementation for your site, and help prevent loss of personalization performance due to incorrect implementation.

Events to Track

The strength of Relewise lies in cross-referencing large amounts of data. As such, we recommend setting up as many types of tracking as possible. Below is a list of the tracking types available; use it as a checklist to ensure you have as many of them running as possible.

Track-Type	Description
TrackProductViewRequest	Tracks that a given product has been viewed by a user.
TrackProductCategoryViewRequest	Tracks that the product list of a given product category has been viewed by a user.
TrackContentViewRequest	Tracks that a given piece of content has been viewed by a user.
TrackContentCategoryViewRequest	Tracks that the content list of a given content category has been viewed by a user.
TrackBrandViewRequest	Tracks that a given brand has been viewed by a user.
TrackCartRequest	Tracks that a cart has been updated by a user.
TrackOrderRequest	Tracks that an order has been completed including which products it consisted of.
TrackSearchTermRequest	Tracks that a user has searched for a given search term.

Note that TrackSearchTermRequest is only applicable if you are not yet using Relewise's search, either because you have yet to implement it or because you have decided to use a different system for now.

Tracking of search terms is useful if you are currently using a different search engine but might switch to Relewise in the future, or if you want to use any of the selected recommendation which operates on search terms inputs, e.g. SearchTermBasedProductRecommendationRequest which allows you to recommend products that other who searched for the same, ended up interacting with during their visit, including products not textually related to the search term provided by the user.

Tracking of search terms is implicitly done automatically when using Relewise Search.

A note on entity IDs

Any entity you want featured in your Relewise experience, whether it be products, content pages, or categories for either, requires an ID for Relewise to track them. These IDs are often frontloaded into Relewise, to allow the engine to warm up with behavioral tracking before the search and recommendation features are activated.

Important Note!

Ensure that you have set up your tracking to correspond with the entity IDs that you have provided to the Relewise API. Discrepancies between IDs means that the behavioral tracking will not function as intended.

In particular, ensure that the Product IDs that you send over match in terms of both Product ID and Variant ID where applicable. Failure to account for the difference between Product and Variant ID can result in the incorrect assumption that variant products are not variants at all, and leads to incorrect and misguiding tracking results.

Another common and critical pitfall is to accidentally send a ProductId as part of a ProductView tracking that differs from the ProductId used in ProductUpdate as part of the product integration. This prevents Relewise from correctly tracking the ID, and in turn keep us from returning the best results for future requests.