Caching & Cookies
Bloomreach's A/B testing will not work on your site if you employ any type of caching. Additionally, A/B testing traffic split will only work if you have integrated the _br_uid_2 parameter correctly. For details on how to integrate this cookie, please refer to our Integration Guide. Please note the _br_uid_2 parameter values in the pixel and API must match.
What's A/B testing?
A/B testing is the technical term for testing the effectiveness of variants of your website. A variant is essentially a change or version of something on your site like a redirect or a ranking rule. A collection of variants represent an experience. When we're talking about A/B tests, think of an experience the way you might think of test or experimental groups and control groups.
Despite the name, A/B testing can involve more than two experiences. You can test up to three experiences, though it's generally easier to find statistically significant results when you limit the number of your experiences to less than that. It's up to you what constitutes a manageable number, but we recommend 2 – 3 experiences per A/B test.
How does A/B testing differ from split testing or bucket testing?
You might hear A/B testing called split testing or bucket testing. All of these terms refer to essentially the same kind of testing technique. For simplicity, Bloomreach only uses the term, A/B testing.
What's the value of testing?
Testing helps you understand the effect of changes on your site, then make data-driven decisions.
For example, what's your prediction on the outcome of burying office chairs for searches of bedroom furniture? Sure, it sounds logical: if I'm looking for bedroom furniture, then it's a logical assumption that I'm not interested in an office chair. But what if I like having an office alcove in my bedroom? What if I live in a studio apartment? What if I'm a college student? Or maybe I'm a very dedicated business professional who starts every morning by rolling out of bed and answering email?
Sometimes what sounds logical doesn't reflect the realities of customers. A/B testing shows you the effect of proposed changes on key performance indicators. Use this data to execute your decisions quickly and successfully.
Is an A/B test the same as a before-and-after comparison?
Here's the short version
A before-and-after comparison gives you unreliable results because you can't control the many external factors that can affect the performance of your changes.
An A/B test gives you the information you need to make a data-driven decision about your changes.
No. When you run an A/B test, you set up experiments, let them run, and examine the results before you fully commit to changes. A/B testing is the gold standard for measuring the effects of your changes. An A/B text isolates the effects of your changes by randomly exposing your change to a subset of your site visitors. Everything except your change is identical to the experience of your other site visitors.
Before-and-after comparisons don't allow you to pinpoint the effects of your change. What if you decide to change the ranking of products on a page today, and tomorrow your site has a huge sale? A before-and-after comparison can't tell you if your ranking change drove an increase in revenue or if the sale was responsible. It might even be both changes that increased revenue. An A/B test not only tells you if your change is effective, but also teases out its effectiveness from the effectiveness of other changes like a sale.
To be sure that your changes are driving business to your site, we recommend A/B testing rather than comparing site data before and after changes.
A/B testing lets you run experiments with otherwise conflicting rules. Site visitors are randomly assigned to an experimental group. You can check the results as early and often as you like. If you notice that a particular group is performing at the level you want for your organization, then you can end the test and fully commit to the changes. Similarly, you can stop the test if you see that your proposed changes aren't having the effect that you want.
For a before-and-after comparison, you first have to commit to your changes. You can't run conflicting changes in production. For example, Mei is a digital marketer. She suspects that redirecting a "shoe" site search on her company's site to her Shoes category page will lead to more conversions than the "shoe" site search page results. She can take a chance by showing the redirect and hoping that her company will see a lift in shoe sales. Or she can take a chance by doing nothing at all. Either way, she's taking a chance and not making a data-driven decision.
What is currently supported?
Bloomreach currently supports A/B testing for ranking changes and site search redirects. We currently do not support A/B testing for ranking changes with audience targeting, facets, and assets/campaigns.
How do I start?
The quickest way to start a test is directly from a rule that you want to test. Click the Save New Test Variant button.
Click into the existing rule you would like to test, then click on Save New Test Variant.
When the Rule Variants popup opens, select the variants you want to test, then click the Setup New Test button.
In this example, the variants table has one variant listed in the table. That variant is being tested against the default variant, which is an option at the bottom of the table.
Alternatively, there are two other ways to start setting up an A/B test.
Alternate starting point 1
You can also start a test from the Testing Overview page. Click the Start New Test button in the upper right corner of the Testing Overview page. The New Test Setup page opens where you can give your test a name, allocate test traffic and select the rule variant(s) that you would like to test.
When you finish setting up your test, click the Activate button in the upper right corner of the New Test Setup page to start the test. While the test runs, you can return to the Testing Overview page any time to check the results by clicking the View Stats button for your test.
When you're ready to end the test, open the Test Detail page by clicking on the test name, then click the End Test button in the upper right corner. You can choose to enact one of the test's experiences as the new default experience for all traffic to your site when you end the test.
No changes to site experiences
If you're not happy with the results for any of the experiences or otherwise don't want to set a new default experience for your site, then you can simply conclude the test without changing your site. Visitor experience on your site remains the same as it was before you started your test.
Alternate starting point 2
Additionally, you can start a test (for ranking rules) from the Ranking page. Click on theicon in the Variants column for the rule you would like to test. This will take you to the Rule Variants menu where you select the variants you want to test, then click the Setup New Test button.
Handling A/B Tests that have more than 1 term in the same active test
To handle A/B testing scenarios where more than 1 term is included in the same active test, note the following FAQ:
Q1. How are the A/B tests handled when more than 1 term is included in the same active test?
A user is assigned to a test or control on a random basis when the first activity is performed by the user that is relevant to the A/B test. The user then remains in that bucket for the entire period of the test, for all the qualifiable activities made by the user. This is true for all tests.
Q2. Are the results from both the queries included in the test, or does the A/B test only use the first term for the test?
Results metrics will include all the activities that are relevant to the test, so all queries are included.
Q3. Is the traffic split at 50/50 per query in the test, or is the traffic split just between test bucket A and bucket B regardless of the queries?
The random splitting (which is assumed to be 50-50) of users happens at the time of the first activity inside the test, which could be either a query in a bigger test, or just one in a single-query test.
Q4. What would happen if there were far more queries in one of the test buckets?
This is situation would not arise because of the inherent randomness explanined in Q.1 above.
Q5. Does it help increase traffic on test buckets by adding more queries to the test? Would this help reach Significance quicker for tail queries?
Adding more queries increases traffic in general, to all buckets proportionally. Significance can increase with increase in lift or increase in traffic, but adding more tail queries does not affect overall test volume or impact it significantly. Infact, it would make no difference.