> For the complete documentation index, see [llms.txt](https://docs.relevant-digital.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.relevant-digital.com/hb-manager/auction-behavior-and-optimization/multivariate-a-b-testing-and-using-child-prebid-configurations.md).

# Multivariate A/B testing and using child prebid configurations

This article describes how to use child prebid configurations as a way to perform multivariate A/B testing on a site.

A/B testing on a site is pretty straight-forward after understanding the concept of *child prebid configurations*. Using this concept, users can be split into two or more test-groups where you control how many % of visitors each group should contain. The groups can then be compared against each other using the headerbid analytics in order to determine the outcome.

Examples of parameters that can be used for A/B testing:

* Enabling/Disabling of one or more bidders.
* Changes of floor prices.
* Changes of headerbid timeouts.
* Switching between server-/client-side bidding.
* Custom execution of JavaScript code - to e.g. programmatically change Prebid.JS settings, load some other JavaScript, or whatever else.
* User-defined settings in [**Prebid Config Tag Fields**](/hb-manager/setup/prebid-config-tag-fields-advanced.md)**.**
* ..etc

### Child configuration

A *child* prebid configuration creates as a "child" to a normal prebid configuration. Which SSP-placements that are selected is still decided in the normal ("parent") prebid configuration. This means that whenever the set of SSP placements for the normal configuration is changed - the child configurations will be updated automatically.

All **Prebid parameters** and **Configuration Data** settings in the parent configuration will be applied as well - *but they are all possible to override in the child prebid configuration*. To read about how settings are applied and in which order - read about [**Prebid parameters**](/hb-manager/auction-behavior-and-optimization/manage-prebid-settings-with-prebid-parameters.md).

### Introduction by example - benchmark enabling a bidder server- or client-side

In this hypothetical example we imagine that we've just got ourselves an account in Xandr and want to test the performance (as measured by **Ad unit eCPM**). This is a good example where A/B testing can be beneficial as it's not always clear how much of added revenue that is "cannibalization" on other SSPs, and how much revenue that is lost because of the possibly longer load times when adding yet another SSP.

#### Preparation - Set the SSP as disabled as default before adding SSP placements

![disable xandr](/files/17377470c2b8ec1d2eec0c23f62d065ecf6e453f)

This can for example be done *globally.* If necessary - read the introduction on [**Prebid parameters**](/hb-manager/auction-behavior-and-optimization/manage-prebid-settings-with-prebid-parameters.md).

{% stepper %}
{% step %}

## Create child prebid configurations for the site we want to run the test

Select "Prebid configurations" on the Website/Apps level, and this will bring you the currently existing Configurations.

Select one of the existing configurations, which will take you to the option of creating child configurations:

![child config](/files/244f00a5bb5ca07c3c4ad1b07d03a873b0641b73)

In this test we'll create two child configurations, one called " *Xandr client-side*" and another called " *Xandr server-side*":

![child configs prebid params selected](/files/b0becc168d9f055279c786ad603fb82721232453)

In this example we'll give them a **Percentage** of 25% each (although you might normally use a much smaller fraction of the traffic like 1%). Make sure to switch on **Enabled child configuration** when you want to start the test.

We're then ready to change the settings we want to change. As we don't want to only test individual placement(s) but *all* placement in the prebid configuration - select **Prebid parameters** on the Account/Publisher level ( **red** marking above).

**Note!** If you would like to change settings for just one or a few placements, then open up the drop down, which lists all your placements, and then select the Placement you would like to do the change on, by pressing **Prebid parameters.**
{% endstep %}

{% step %}

## Change settings for the child configurations

Change the settings on the Account/Publisher level in the configurations (see above), so that we un-check the **Disabled Bidder** setting in the " *Xandr client-side*" configuration:

(If you want to do changes to other settings, like Floor prices or reloads, these can be found under the "Generic placement Data)

![enable xandr](/files/83d8d527dd7494c03e8262b307b782ecf127f037)

In the " *Xandr server-side*" configuration we'll do the same, but we'll also change **Bidding type** to **Server-side**:

![enable xandr server-side](/files/b651a74d1f81caeec841a67c19deed1521f2f93c)
{% endstep %}

{% step %}

## Save settings and run the test

That's it! You can now save the the settings and then save the Account/Publisher. Immediately after saving, the child configurations will be used - in this case for 25% + 25% of the visitors.
{% endstep %}

{% step %}

## See the result of the test

The **Prebid configuration** dimension in the HB Analytics header bidder reports can now be used to measure the performance of the test. The most important metric is normally the **Ad unit eCPM** metric as it shows how much revenue that is generated in average per ad request. You cna add your results as a Dashboard reporting module if you would like to keep a close eye on your test all the time, and even build alarms on it.

But there is also an **A/B Test statistics** section in the parent prebid configuration that shows you the base metric Ad Unit eCPM, if you prefer not using the reporting or dashboards.:

![ab test results](/files/7912b1ea4419035abf6570718130814e59b4f265)

We recommend that you utilize the reports and the Dashboard reporting modules, if you would like follow your progress over longer time periods though, but it is of course your own choice. In the reporting and dashboard reporting modules you can also filter for the configurations you would like to see:

![](/files/7426d89129291677dd5d4a81337107f847cab018)
{% endstep %}

{% step %}

## Apply the "winning" settings

In our example it turned out that the " *Xandr server-side*" configuration came out on top. What we probably would do in this case is to **1)** disable the the **Disable Bidder** setting in the *global* settings (see the *Preparation..* section earlier), **2)** set **Bidding type** to **Server-side** and **3)** delete the no longer needed child configurations.

However, in case the testing we're doing is only about optimizing the site/configuration we're currently testing - then we can *copy* the child configuration's settings into the parent configuration using the button outlined below:

![copy child config](/files/1cb179001b51fa7c21764d2fd6260ef8c7f47da2)

This concludes the step by step guide, but if you would like to add more customized code to your child configurations and your tests, we recommend that you read through the section below.
{% endstep %}
{% endstepper %}

### Executing custom JavaScript code for a child configuration

Using **Custom Config JavaScript Code** we can execute any JS code.

![Code](/files/5ed101f13d3affd35e64a9ed4996c622aa1adc3c)

This code will be executed ***once*** immediately when doing the ***first*** call to [relevantDigital.loadPrebid()](broken://spaces/thyujPhgXh1WtJZy8bjr/pages/28d0e242e33c72426e17b4dc7700f6629be560ea).

{% hint style="warning" %}
**NOTICE:** As such code is only executed once per page-view / page-session it's worth to notice that in the case of a *Single Page Application* style page with *different* prebid configurations for e.g. frontpage/articles - then *only* the code for the *first* used configuration will be executed. If needed it's possible to create an own code-field with different behavior using [**Prebid Config Tag Fields**](/hb-manager/setup/prebid-config-tag-fields-advanced.md).
{% endhint %}

#### Data available in the Custom Config JavaScript code

The following variables will be available in the JavaScript code in the field:

* **data** - An object with the **Configuration Data** for the prebid configuration. This includes the *Built in settings* (like the code itself). The keys for these built-in fields will be prefixed with " *rlv*". It also contain custom user-created settings created using **Prebid Config Tag Fields**.
* **pbConfig** - The prebid configuration object itself. It will be one of the objects returned by [relevantDigital.getConfigs()](broken://spaces/thyujPhgXh1WtJZy8bjr/pages/ae89e984aeba5911f599c02cb956319d59743200).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.relevant-digital.com/hb-manager/auction-behavior-and-optimization/multivariate-a-b-testing-and-using-child-prebid-configurations.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.