Watch the video tutorial:

The content of this page is presented in a video tutorial, have a look:

Winning Interactions Tutorials - WPO Widgets part 1/3

Winning Interactions Tutorials - WPO Widgets part 2/3

Winning Interactions Tutorials - WPO Widgets part 3/3

Filters, Rankers & Scorers

Open

 

How to create an A/B test?

Open

 

 

How to use Segmentation?

Widget Strategy: Filters, Rankers & Scorers (and Others)

An example widget with 1 filter (price > 0), 1 ranker (filter instock) and 1 scorer (all-time sales count).

Each Filter, Ranker, or Scorer is based on a Use Case that defines what the logic of this component is. Use Case can be set as a business rule (discounted or new products), on statistics (top trending sales/revenue/margin), on marketing campaigns (selected or currently active campaigns), individual personalization (favorite brand, last purchase, repeated purchases, ...) or machine learning (collaborative filtering, correlations, regression, ...).

Conditional vs Linear

Each Ranker and Scorer can be either conditional or Linear. Filters can only be Conditional.

Conditional

A conditional Filter, Ranker, or Scorer is either true or false.

So it will either match the Filter (or increase the score with the entire defined weight by the Ranker or Scorer) in case it is true.

And, in case it is false, it will either exclude de result if it is a Filter, or not add anything to its score if it is a Ranker or a Scorer.

Linear

A linear Ranker or Scorers will give a percentage of the defined weight as scores (from 0% to 100%).

So, instead of increase each result score by either their full weight or nothing (like the conditional case), they will increase the score by a percentage of their weight.

Example: A scorer with a minimum value of -10 and a maximum value of -90 (best practice to get the linear range from the 10th to the 90th percentile).

Filters (and System Filters)

Filters define must-have logics which should be applied. This means that only* products which match all the filters are returned.

Example: do not show any products out-of-stock.

Filters can be of any nature (as we will see later with the Best Practice). This means that you can set a filter to indicate you only want to show products with a price or a stock bigger than 0, or that you only want to show products already bought by a customer. While both cases are very different, you can define both as a filter.

Example: A filter setting the price > 0 (the operator “greater than” is defined in the Advanced Parameters Tab)

System Filters

System filters are similar to Filters, except that System filters will never be “relaxed”.

This means that, even if the system would need to remove them to return the required number of results, it will not do it and return fewer products than requested.

If needed, you can separate normal filters (which can be relaxed) from system filters (which can’t).

Example: a System Filter making sure the products have the property “Active” set to 1.

Rankers

Rankers make sure some results are on top (or on the bottom). There can be more than one ranker in which case the top rankers are more important than the lower rankers*.

Example: put in-stock products always before out-of-stock products.

Rankers can be of any nature (as we will see later with the Best Practice). This means that you can set a ranker to indicate you always want to see products with a price or a stock bigger than 0 before showing any products with a price or a stock of 0. But rankers can also be that you want to show first some specific personalized product recommendations (if any) before showing anything else. While both cases are very different, you can define both as a filter.

Example: A ranker to put products with a stock > 0 at the top of the list (the operator “greater than” is defined in the Advanced Parameters Tab)

Scorers

Scorers will define what type of products appear higher than others based on the sum of their weights.

As scorers are significantly less strong than Filters and Rankers, they will only order the list of results within the results lists defined by the Filters and the Rankers.

Example:

• 500 points to products currently in sales

• 500 points on the all-time quantity of sales per product

• 500 points to products matching the most bought brand of each individual customer

If it happens (for some customers) that there are products in the first list provided by the Filters and Scorers who score all 1’500 points on each of the 3 criteria, they are guaranteed to be on top.

Afterwise, products scoring all (or high) points in all 3 will come (e.g.: a product with 500+300+500 = 1’300 pints will be quite high).

Finally, products scoring low points or only on 1 or 2 of the cases will appear (e.g.: a product with 0 + 400 + 0 = 400, or a product with 500 + 10 + 0 = 510).

So, scorers will compete which each-other by computing an aggregated score summing the weighted effect of each of the scorer and the product matching all the filters & rankers and with the highest score will appear on top.

Example: a Linear Scorer giving 0 to 500 points based on all-time number of sales (fields with Bq prefixs are automatically calculated by Boxalino in the BigQuery Data Science Ecosystem)

Others

While Filters, Rankers, and Scorers play a direct role in selecting and ordering the products (or contents) returned by the Widget, the Other Use Cases do not play any direct role in the results.

They will instead change the additional aspect of the response, like for example adding a return field to each product returned, setting some other parameters in the response, etc.

Example of an “Others” Use Case adding the title to the return fields (by default the Boxalino Narrative API returns the product “id” and the requested fields, but additional fields can be added in the widget configuration)

Best Practices & Use Cases

Each Filter, Ranker, and Scorer is based on a Use-Case.

A Use-Case is a real-time program that generates a Filter, Ranker, or Scorer based on a specific logic.

As Use-Cases are quite generic and can be used in many different situations, Boxalino has prepared a list of Best Practices that define a concrete case of the configuration of a Use Case.

Therefore, to configure a Widget, you need to add these Use-Cases by selecting them from our Gallery of Best Practices (and then slightly adjust their parameters if needed).

Every widget suggests a list of Best Practices for the setup, to a/b test first, or do consider as advanced cases. This Dialog appears after clicking on the orange button “WPO - optimization Strategies” on the top.

Add a Use Case

Find a Best Practice

First Click on the Orange button “WPO - optimization Strategies”

You will see then the dialog box (as in the screen-shot above) showing you 3 tabs:

• What to start with (for the go-live)?

• What should be a/b tested first?

• What else could you be experimented with?

When you are searching for a Best Practice, you can therefore either

1. look at our suggestions for the current WPO (either by clicking the orange button or going to the WPO documentation and selecting the WPO you are working on) (recommended for most cases)
   
   

2. look per Best Practice Group and find a best practice depending on its type (real-time personalization, marketing alignment, …) (only recommended if you know the group of Best Practice you need)

Add the Use Case from a Best Practice

Once you have identified the Best Practice you want, you can add it to your Filters, Rankers, or Scorers.

If you found your Best Practice through the gallery in the Admin

You can simply click on the orange button on the bottom left of the dialog and this will add the Use Case directly to your view

If you found your Best Practice using our online documentation

At the end of the page describing the Best Practice, you will find a section you can expand call “Use-Cases (JSON)”. You can then click on the “Copy” icon on the top right as here:

You can then go to your widget in the admin and click on the “Import” button:

and then paste from your clipboard in the text area and click on the “Import” button.

The Use-Case is now added to your strategy and you can edit its parameter (follow the instruction provided in the Best Practice) and you can move it to the Filters (only if it is Conditional) or to the Rankers or Scorers by drag & drop or by clicking on the Change to (as squared below).

Configure your Use Case

Now that you have added your Use Case from Best Practice, you can now configure it.

The following parameters appear in the Settings tab of all Use Cases:

Name

That’s just a name, but this is what you will see when the Use Case is collapsed and when you are testing your strategy in the test view, so we recommend giving it a name that is easy for you (and your teammates) to understand quickly just by looking at it (for example: “Smart Bestsellers” could be renamed to “Number of sales during last 3 months”.

Use case

This is only informative, it indicates what is the name of the Use Case.

Active

Defines if the User Case is active or not.

OR Group

This is quite an advanced case and mainly makes sense for Filters.

If you would like to apply an or logic between two filters, you can give any name here and make sure you put the same name in the other Filter Use-Case.

This way, the system will know that any one of these Filters to be true is enough.

Max Weight

Only for Rankers and Scorers and typically, this parameter should not be set.

In some cases, a use case might find several matches, in which case the weight of the Use Case will be given several times (e.g.: match favorite categories, a product might be connected to more than 1 of the favorite categories).

If you want to limit the maximum possible weight which can be given, you can set this value (the value should of course be higher than the Use Case weight).

Positions

If you want this Use Case to only apply for specific positions of product recommendations (e.g., the first 2 products), you can specify a position.

The position starts at 0, so a range 0-2 will cover the first 3 products (positions 0, 1, and 2).

Overwrite Label

In case you want to set a different Recommendation label to the User if this Use-Case participates in the results (so not when it doesn’t add any score of filter to the results), you can define a different label here.

Test

This enables you to connect the Use Case to a specific variant of an A/B Test.

Segments

This enables you to add a segment to this use-case, which means that it will only apply to situations where the segment is active.