A/B testing of Category Merchandising using API Implementation

Klevu has an AI-driven mechanism to order products on every category page and it also provides visual merchandising tools for any manual merchandising of your pages. However, it is when you are not sure if you should really merchandise your categories or leave it to the AI system or if you decide to manually merchandise, which of the manual merchandising strategies to choose, you can use our A/B testing solution to take data-driven decisions.

Please note that if you are using Klevu's out of the box theme (based on V2 JS Library) for serving your category pages, you should read our KMC guide to setup A/B testing. This document is mainly aimed at those who like to integrate A/B testing using our API.

Here, we share the step-by-step instructions to set it up. There are three main steps:

Step-1 Setting up an A/B Test in Klevu Merchant Center

Step-2 Implementing the A/B Test on your frontend (explained below)

Step-3 Verifying your data to take a final decision

For steps 1 and 3, please refer to our guide here. Once you have performed step 1, our backend will automatically compute variants to categories allocations per shopper. As your shoppers visit your category pages and variants get used, the Klevu backend continues to recompute its allocations for new users to maintain the split ratios.

Below, in the integration steps for A/B Testing, we explain

• How to retrieve these allocations?
• How to use the allocated variants when querying for products for the respective category pages?
• How to inform the klevu backend that you have served a customer with the allocated variant?, and finally
• How to register the used variant when reporting the category navigation analytics events?                                                             

Integration steps for A/B Testing Category Merchandising

Step-1 In your custom shop, add the API call to allocate A/B Testing Variants for Categories on a recurrent basis. We recommend this call be made from the storefront anywhere between 20 minutes and one hour.

• The response from this call should be stored in the local browser cache, to be used when visiting a Category.

Step-2 When a user visits a store Category, the local browser cache should be checked for any A/B Tests and Variants assigned to that Category. If any exist, the corresponding A/B Test and Variant unique identifiers should be appended to the calls to retrieve the Product list for the visited Category.

Step-3 Also when visiting a Category for the first time since an A/B Test and Variant have been assigned to that Category, we recommend recording that visit on the local browser cache and sending a request to our systems to notify of this visit. 
This is important so we can overcompensate or skew for combinations of Categories and Variants which initially receive fewer visits. When we receive a lower amount of visits for those combinations, our algorithm will increase the likelihood for those combinations to be assigned in the allocation requests from point 1.

It is also important to keep this in the local browser storage, to keep consistency over the list of Products retrieved for a Category over the duration of the A/B Test.

Step-4 When a category page is viewed and when a category view event (as described here) is registered, you must supply the respective abTestId and abTestVariantId to the request. Similarly, when a product is clicked on a category page and when a respective category product click event (as described here ) is registered, you must supply the respective abTestId and abTestVariantId to the request.