Popularity and Relevance

Core to most of Relewise's services are the concepts of Relevance and Popularity. These drive the fundamental functions of most of Relewise's search and recommendation behaviors, and are both informed by the behavioral tracking available on your site.

Briefly put, popularity is the aggregate of user behavior across users, while relevance is the behavior of the individual user.

Popularity

Popularity refers to the aggregate of views (or views and purchases, in the case of products) that an entity has received. It is used as the primary modifier for many of Relewise's features, and exists as the standard fallback when other data fails. In particular popularity is used for recommendations (PopularProducts/PopularContents, etc.), search sorting (ProductPopularitySorting/ContentPopularitySorting), as well as the basis for the fill function.

For product entities, Popularity is calculated as a split between product views, product category views, and product purchases. In other words, both viewing the product itself as well as its associated category or categories will affect its popularity, along with any purchases of the product. By default, product views and purchases are weighted equally, with product category views playing a lesser role.

The ratio of weighting product views versus product purchases is by default set to a 50/50 split, but it is possible to configure this with the help of Relewise's staff. Please reach out to us for more information on how to achieve this.

For other entity types (Content, Product Category, Content Category), it is the number of views that determine a given entity's popularity.

PopularProducts and Line Revenue

Users of Relewise's B2B features can also opt to define the Popularity of products on the basis of line revenue, specifically when using the PopularProducts recommendation type. Doing so means that, rather than look at the tracked interactions with the product, the recommendation instead looks at the registered line revenue of the products that have been tracked via order tracking. The material difference here is that popularity by default looks at the number of products sold, whereas Line Revenue looks at the actual worth of the products sold.

Popularity in Search

When performing a Relewise search, the system will first attempt to match your query against the various data that has been indexed on your dataset. Then, once the viable candidates have been identified, a popularity boost is applied, wherein an entity's relative popularity will determine where it is ranked among the results. This popularity ranking is perfectly capable of elevating entities with a lower lexical match to a higher position, if the entity in question is particularly popular or relevant (see below). All of this is, naturally, contingent on the use of the ProductPopularitySorting logic.

Relevance

Relevance is a measure of the likelihood that an entity will be relevant to the specific user. Where Popularity is based on the behavior of all users in aggregate, Relevance adds another layer on top by taking into account the particular user's own behavior and the preferences that they have shown during their engagement with the site.

Relevance is only relevant for non-anonymous users. For anonymous users, Popularity will be used instead.

Relevance is the core of Relewise's personalization feature, and should for the most part be considered the default behavior of our services. For search, Relevance is the default sorting behavior if nothing else is specified. Certain recommendation types will also take Relevance into consideration, notably PersonalProduct.

Similar to Popularity, Relevance is based on the types of tracking events logged for the user. These form the basis of the 'interests' that a user exhibits, and this interest is then measured against a metric of relevance based on what other users with similar interests have engaged with. As Relewise tracks more user behavior across time, this network of relations between entities grows stronger and more reliable, and comes to form the statistical underpinnings for serving relevant search results and recommendations to the individual user.

The Relevance calculation will also look at products currently in the user's cart, and apply a boost to related products.

In other words, as users engage with entities, Relewise logs how these entities are engaged with - products purchased together, entities viewed after other entities - and creates a network of relations that affects what entities are shown to a given user when they interact with the site. If ten users have viewed product A and then product B, then product B is likely to be relevant to a user who engages with product A in some capacity.

Relevance in Practice

The following explains in broad strokes how Relewise applies Relevance to a user's experience:

• If the user is non-anonymous, Relewise looks at what the user has in their cart and what they last viewed.
• Then Relewise applies a boost to relevant products based on this. By default, equal value is assigned to purchase history and view history.
• Finally, Relewise applies a general Popularity factor, which helps bring popular products to the top of the search results. This will sometimes cause them to mix in with the relevant products of the user to give a broader feel.

Relevance and Search

Relewise's engine learns from user behavior and what users interact with after they search. This allows the engine to match search terms to specific entities, even if they have a low view/purchase history. If Relewise can identify that a certain entity has been engaged with heavily after a given search term, the engine will provide an additional boost to the entity upon further searches for that same term. This is extremely helpful for datasets where entities share the same "words", since the engine adapts over time to show the best/most relevant results.

Popularity and Relevance Decay

By default, Relewise looks at data going back 30 days, with more recent activity being weighted higher. For instance, an event tracked an hour ago is more relevant than an event tracked a day ago, which in turn is more relevant than an event tracked two weeks ago.

After 30 days, the tracked events stop being factored into the default popularity ranking. Do note that the PopularProducts recommendation type has its own configurable setting, sinceMinutesAgo, which determines how far back the recommendation looks to consider popularity. For more information, refer to our best practices for recommendations page.

Decay can be configured on the dataset level, both in terms of the gradual decay over time, as well as the time limit before an event stops having an effect at all.

Decay Use case Example

If your products are highly contingent on being seasonal, you may benefit from a shorter decay rate to ensure that products purchased last season do not affect the current season's popularity.

Inversely, if you experience zero seasonality on your products, you may wish to set the daily decay rate at zero percent, and prolong the hard cutoff rate of decay to a full year. This will ensure that popularity and relevance are solely based on what was tracked, and not when it was tracked during the year.