Behavioral Tracking

When a user browses a website or shop, they do various things:

• Look up specific products or product group
• Search for products and product groups
• Add something to a shopping basket (and buy or not buy it)
• Visit a specific content page or blog post

All the above can be summarized as behavior. In order to have the best Search and Recommendation to offer your users, you need to track this behavior to the extent the user allows it. Always ensure that your site is GDPR-compliant.

The amount of tracking information you need is dependent on the usage pattern of a specific solution. However, as a general rule of thumb, the more behavioral data you track with Relewise, the better the personalized experience it can provide.

Note: Behavioral Tracking data is free of charge for our customers.

Implementation details for Developers

See how to implement Behavioral Tracking here

Locations

Locations (AKA DisplayedAtLocation) are used for several thing within Relewise, primarily for dimensioning analytics data, as well as for targeting specific requests in Merchandising.

Location is basically a means for you to be able to let Relewise know where you are planning to show the results of this query to the user. This lets you know where your searches and recommendations are being made, and where they perform best - allowing you to optimize your Relewise performance.

It is important to not create too many locations, as performance will suffer. Never use context/data-driven auto-generated objects for locations, such as urls, page-names etc.

Locations are relevant for both Search and Recommendation purposes. As a baseline, Relewise recommends focusing on the following locations (though your needs may vary):

Recommendation Locations	Search Locations
Front Page	Search Overlay
Product Details Page	Search Page
Cart/Basket	Search Results Page
Power Step
Category Page
Content Page
Search Result page

If you do not have products or a basket to worry about, focus instead on the content-related pages that would make sense to set up as locations. Just keep in mind that a location should be generic rather than specific. You want to target "content pages" in general, and not each content page in particular.

A note on window.location and other auto-generated locations

Under no circumstance should you attempt to track the window.location property of the browser. This is not a Location as we refer to them in this documentation, and will cause major issues with loading your tracking data in the Relewise engine.

This extends to all context/data-driven auto-generated locations, such as URLs, page-names etc. Locations are static places on the website, and cannot be linked to a dynamic object.

Identifiers

When tracking user behavior, it may be beneficial to use custom IDs that do not map directly to the user types codified in Relewise to begin with. Such IDs can be saved to the User-object in a collection called Identifiers, as a list of key/value pairs.

There is no limit to the amount of identifiers that can be appended to a User-object.

Identifiers are commonly used for something like a nonstandard Customer ID, an ID generated by an Email marketing system, a rewards club membership number, etc.

By appending these to the User-object, Relewise is able to link it to other registered user-types associated with the User-object, and thus serve personalized recommendations and search results on the basis of the user's entire user journey through your site.

Appending additional user IDs to a User-object is made easy in Relewise. Every time a request containing User data is sent to the Relewise API, the User-object automatically gets updated with any new information that may be appended.

This means that any Recommendation or Search request that you serve via Relewise's service automatically binds the userdata together, ensuring that you will serve as much personalized data as possible back to the user.

In terms of the merging of userdata, Relewise prioritizes userdata from strongest to weakest key, starting with:

• Authenticated IDs
• Custom IDs
• Temporary IDs
• Email IDs

All of these are, naturally, optional. If no ID is assigned to a session, the user is considered anonymous.

User-objects may also be updated with the use of the TrackUserUpdateRequest.