Filter out irrelevant A/B tests
There can be many A/B tests running on the platform, but only some that are relevant for a given page. Without filtering, we would need to have variant combinations for all of the running A/B tests for that page, resulting in unnecessary requests that need to be cached, as even though an irrelevant A/B test would not trigger on a page, you would still end up adding the A/B test to the request, thus making it a different request. To avoid this, we want to filter out the irrelevant A/B tests.
Example response
Consider the example response below:
In the response we have a single A/B test with the following properties:
318ccefa-bb47-4589-945d-ccc0c4f32280 as the A/B test id
Two variants or variations each with a weigh distribution of 50% and their corresponding ids
06c26226-25bc-4054-b622-62fcbe4db3fd for the first one
4f4bdc48-a586-4670-985b-b8de7d028773 for the second one
A single filter in the filters object which states that the A/B test is active on pages whose
fh_location
parameter matches the RegEx//catalog01/en_GB/color>{black}.*
which translates to all navigation pages within the catalog01 universe, with locale en_GB, which start with a facet selection of color: black.
The filters are configured when the A/B test is created. Most of the time, the only available key would be fh_location
, but there might me multiple RegEx patterns to match. We will work with the fh_location parameter in this example, but the process is completely the same for any other parameter.
Filtering
In order to filter out irrelevant A/B tests for a given page all we need to do is some RegEx pattern matching. If the page you want to request matches ALL of the patterns for ALL of the properties in filters, then you have a match and the A/B test should be used. If you have query parameters that there are no filters present for, you can assume a match. If on the contrary there are filters for a query param which you don't have in your query for the page, you can assume a mismatch.
Let's look at the fh_location example in the response above. Consider the following pages:
A page with
fh_location: "//catalog01/fr_FR/color>{black}"
will not match, because the locale in the path doesn't match the one we have in the filter.A page with
fh_location: "//catalog01/en_GB/spotlight>{new}/color>{black}"
will not match, because the color facet is not the first one selected while navigating.A page with
fh_location: "//catalog01/en_GB/color>{black}/spotlight>{new}"
will match, because the color facet the first one selected while navigating, and the color is black.
To confirm whether a value is a match, all you need to do is perform a RegEx match in your language of choice, which in Java is:
As mentioned before, this needs to be done for all patterns of a property, for all properties available in filters:
Everything mentioned in this section is also covered via the SDK.
Once you have the irrelevant A/B tests filtered out you can move on to assigning variants to the user.
Last updated
Was this helpful?