Watch the video tutorial:
The content of this page is presented in a video tutorial, have a look:
Filters, Rankers & Scorers
Define filters, rankers & scorers based on rules, statistics and personalized Use-Cases.
Your widget strategy is mainly consistuted of 3 types of logics: filters, ranker and scorers.
Filters define must-have logics which should be applied at all costs unless the requested amount of results cannot be met. They are then considered by order of priority from top to bottom to fill-up what is missing.
Rankers to force some elements to always be on top (or on the bottom) of the results no matter what (applied by order of priority if more than one).
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.
Each Filter, Ranker or Scorer is based a Use Case which 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, ...).
How to create an A/B test?
Define test variants and associate them to the right Use-Cases.
Any part of your logic can be limited to only apply in a specific A/B testing variant. This means that (if you create 1 test variant) 50% of the visitors will get the control (all your logic Use-Cases except the ones which are connected to your test variant) and 50% will get your test variant (all your logic Use-Cases except the ones which are connected strictly to control or to other test variants).
First, click on the Create experiment green button at the top left, add a test variant name and click on Add.
Then select, duplicate or add the Use-Case(s) which should be tested, go to the Settings tab, and connect them to your new test variant.
Then click on Save & Test, test the behavior before publishing in the test view and then publish.
After reviewing your test results, if you want to keep the winner, then go to the Create Experiment dialog again and select a test variant as the winner.
How to use Segmentation?
Limit the scope of some Use-Cases to only apply for specific customer/visitor segments.
Any part of your logic can be limited to only apply to a specific visitor segment. This means that visitors in that segment will get all your logic Use-Cases without segment AND the use-cases you defined for that segment, and the others will only get all your Use-Cases without segment.
First, create or select the Use-Case(s) you want to only apply for a specific segment.
Then go to the Settings tab and define the segment you want to use to connect them. There is a quick-segmentation dialog you can use, but otherwise, you must first create your segment in the Segmentation View and after selecting them in the drop-down.
Then click on Save & Test, test the behavior before publishing in the test view and then publish.
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, ...).
Boxalino has prepared a library of Best Practices so you can identify what case you want to do and then follow the instruction to select and configure its Use-Case. See more information below in the section “Best Practices & Use Cases”.
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.
Example: product is in-stock.
It is either true (then the filter passes while the ranker or scorer increases the score by the defined weight) or false (then the filter excludes it while the ranker or scorer does not add anything to its score).
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: all-time quantity of sales per product (with a maximum of 1000)
For every product with 1000 sales or more, the full weight will be added to the score.
Products with no sales will not increase the score.
Products with sales between 0 and 1000 will increase the score according to their sales relative to 1000 (e.g.: a product with 300 sales will increase the score by 30% of the full weight)
Many linear Use-Cases have in their advanced parameters a minimum and maximum value.
If you set positive numbers (e.g.: 50 - 1000) it will set the minimum and the maximum for the linear calculation at these values. The big disadvantage is that they will be static (they will not change until you modify them and republish them).
If you set them with negative numbers, they will use dynamic minimum and maximum values based on the statistics of the field you have selected according to the following logic:
-1: the absolute minimum or maximum value that exist for this field
-10: the 10th percentile (10% of the products have a value lower)
-20: the 20th percentile (20% of the products have a value lower)
…
-90: the 90th percentile (90% of the products have a value lower)
-95: the 95th percentile (95% of the products have a value lower)
-99: the 99th percentile (99% of the products have a value lower)
We recommend to use min = -10 (10% percentile) and max = -90 (90% percentile), this typically gives the best results and avoid issues when only a few products have very very high values, making these one getting all the points and all the other ones almost nothing.
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.
* For widgets in the SEARCH / NAVI WPO (so the logic providing search results or product listing), this is it. Only products matching the filters are returned and nothing else. This is because even if the page could show more products on the first page, it just happens that they are no more products to show.
For the other widgets (unless if the widget setting mode is set to ‘search’ or ‘navigation’), you will always receive the requested number of results. In such a case, your filters are then considered by order of priority from top to bottom to fill-up what is missing (i.e.: the last filter of the list is removed first, then, if necessary, the second to last, etc.).
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.
* Rankers have a weight (just as scorers) and in fact, the only thing technically differentiating scorers and rankers is the dimension of their weight.
Rankers simply have much bigger weights (over 10’000) than scorers (typically 500).
To differentiate rankers, you can set the first one with a very big weight (like 1’000’000) then a second one less high (like 500’000) and a last one lower (like 100’000), there will still be a big gap between them to make sure the highest one is much more important than the others and they will all be much higher than the scorers, so the scorers can never over-rule any of the rankers.
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)
There are no negative weights on products. so if you want to put the products without stock at the end, what you do, instead is to put the products with a stock > 0 at the beginning.
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.
Best Practices are grouped into 7 groups as in the diagram below which are all documented here.
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?
These lists are specific to each WPO and match what you find in the middle section of the WPO documentation (for example, here for the WPO WELCOME).
When you are searching for a Best Practice, you can therefore either
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)
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).
You can also add a Use Case directly without going through a Best Practice, but such a process is only recommended for advanced users and is described here.
Configure your Use Case
Now that you have added your Use Case from Best Practice, you can now configure it.
The way to configure a Use Case greatly varies depending on each Use Case, so please refer to the documentation of the Best Practice (or of the Use Case itself) to fill the tab “Values” (and “Advanced”).
However, the tab “Settings” is the same for all the Use Cases and its configuration is documented here.
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.
To avoid deleting a Use Case you might need, just set it to inactive if it is not ready to go live.
Inactive Use-Cases appear in the “Inactive” tab of the Filters/Scorers/Rankers/Others
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).
In case you define the Max Weight with the same value as the weight of the Use Case, changing the Use Case weight will automatically also change the Max 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).
To specify no position, make sure that the positions are set to -1 to -1
does not work for WPO SEARCH/NAVI, only should be used for recommendations cases
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.
This will only work if you have connected the label of this Block in your Narrative with a dynamic variable.
Test
This enables you to connect the Use Case to a specific variant of an A/B Test.
Read more about How to Create a Widget A/B Test to get all the details.
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.
Read more about How to use Segmentation in a Widget to get all the details.
Add Comment