Configuring A/B Testing in Edge

Edit on GitHub

A/B Testing is a serverless function from Azion’s Edge Computing platform for constructing A/B Tests.

Using A/B Testing you can create tests that are completely managed on Edge, using Edge Computing’s logic systems to control the distribution of access to the different scenarios, more assertively, during the test execution, and identify the variants that present the best results, enabling you, among other things, to direct the public to the preferred versions.

Some other advantages of Edge Function’s A/B Testing:

  • You can set up multiple variations (A, B, C, …);
  • Vary the traffic flow;
  • Combine test rules with business rules (WAF, Bot Protection, etc.)
  • The user experience is better, because it does not affect the time a page takes to load, and is significantly faster, compared to solutions that use JavaScript to carry out the A/B test.

Next, let’s have a look at how to establish and set up some Edge Function A/B Tests.

How does Azion’s A/B Testing work?

The settings for the test are defined in the function using JSON format parameters (Args), where the attributes related to each version to be tested are listed, such as probability, cookie value, etc.

When the request arrives at one of Azion’s Edge Nodes, the algorithm of the function distributes it, according to a defined probability. Then a cookie is set with the expiration time and the values specified for each variable (from that moment on, all traffic from the client that originated the request will be directed to the selected version).

The Edge node then forwards the request to the originating application, which returns the content of the test page requested, so that Edge delivers the content to the user.

When another user makes a new request, the function runs the selection process again, within the probability defined in the parameters, and directs the user to the chosen page.

Setting up A/B Testing

Edge Function A/B Testing is available from the functions library of Azion’s Edge Computing platform and can be accessed through Real-Time Manager (RTM), from the Libraries menu.

The function can only be executed when it has been instanced in the Edge Application that you intend to work in and when the activation criteria and behaviors have been defined in the Rules Engine.

Creating an Instance

Path: Real-Time Manager > Edge Computing > Edge Application > Functions.

Enter RTM and select the Edge Application that is going to run the function and activate the Edge Functions module, on the Main Settings tab. Then, on the Functions tab, add a new function, ensuring that you give it an identifiable name.

Parameters: You need to include the type of function for your instance, in this case choose A/B Testing. Note that the function code appearing in the Code field, is just for information. On the Argstab, add the parameters by which your test will be executed. Below is a description of each of the Args parameter fields:

{
"param": {
	"cookie": {
		"name": **Name of the cookie**,
		"expiration": **Cookie expiry date**,
		"max_age": **Cookie expiry date**,
		"domain": **domain**,
		"path": **Validity subdomain of the cookie (“/” indicates that it is valid for every domain)**
		},
	"a": {
		"cookie_value": **Value of the cookie for test A**,
		"prob": **Probability of selection**,
		"addresses_list": **Address for test A**,
		"originid": **identification id of the origin (automatically generated by the RTM when the origin was registered within the Edge Application)**,
		"live_ingest": **Indicator as to whether the origin of the test is live for streaming**,
		"protocol_policy": **protocol policy (force http or https, or “preserve” to keep the request**,
		"path": **Subdomain for which the cookie is valid (“” indicates that it is valid for the whole domain)**,
		"cache_key": **Cache key in Edge, specify for this variant (cannot repeat)**,
		"host": **Name of the host that must be included in the request (HTTP HEADER "Host", and which will overwrite what was given by the registered origin)**
		},
	"b": {
		"cookie_value": **Value of the cookie for test B**,
		"prob": **Probability of selection**,
		"addresses_list": **Address for test B**,
		"originid": **origin identification id (automatically generated by RTM at the time of origin registration within the Edge Application)**,
		"live_ingest": **Indicator as to whether the origin of the test is live for streaming**,
		"protocol_policy": **protocol policy (force http or https, or “preserve” to keep the request)**,
		"path": **Subdomain for which the cookie is valid (“” indicates that it is valid for the whole domain)**,
		"cache_key": **Cache key in Edge, specify for this variant (cannot repeat)**,
		"host": **Name of the host that must be included in the request (HTTP HEADER "Host", and which will overwrite what was given by the registered origin)** 
		}
	}
}

Next is an example of the configuration of a basic Function, maintaining a 90 per cent (0.9) probability for the first variant and 10 per cent (0.1) for the second, not forgetting that the sum must always be 1.

{
"param": {
	"cookie": {
		"name": "MYABTEST_NAME__",
		"expiration": "Wed, 04 May 2021 10:16:00 GMT",
		"max_age": 600,
		"domain": "localhost",
		"path": "/"
		},
	"a": {
		"cookie_value": "A_VARIANT",
		"prob": 0.9,
		"addresses_list": "www.mytest_ab_of_my_site.com:443",
		"originid": "uuid1",
		"live_ingest": false,
		"protocol_policy": "https",
		"path": "",
		"cache_key": "test_a",
		"host": "localhost"
		},
	"b": {
		"cookie_value": "B_VARIANT",
		"prob": 0.1,
		"addresses_list": "www.mytest_ab_of_my_site.com:2010",
		"originid": "uuid2",
		"live_ingest": false,
		"protocol_policy": "https",
		"path": "",
		"cache_key": "test_b",
		"host": "localhost"
		}
	}
}

Edit the parameters and click on Save to save.

Defining the Execution criteria (Rules Engine)

Path: Real-Time Manager > Edge Computing > Edge Application > Rules Engine.

The rules in the Rules Engine determine the set of conditions that need to be met for Behaviors to be executed. You can use the Default Rule to run your function without any conditions, or create a new rule in order to configure the trigger conditions for your function to be executed by the Edge Application.

Defining validation criteria (criteria): choose the variables, comparison operators and strings to create your business rule, as in the following example:

  • If: ${uri} is equal /home (next: logical operator, variable, comparison operator, string)

Here, the rule is executed if the URL accessed is equal to the string “mypagetotest.com/home”.

Defining Behaviors: add the behaviors you want to be carried out when the rule’s conditions are met. Example:

  • Then: Run Function MyABTestFunction (next: logical operator, action, function)

In this example, if the conditions defined in the rules are satisfied, then the function MyABTestFunction will be executed.

Finally, save your Edge Application and the new function will be ready.


Didn’t find what you were looking for? Open a support ticket.