Make effective product iteration, simple implementation of front-end A/B Testing, front-end testing

Make effective product iteration, simple implementation of front-end A/B Testing, front-end testing
Introduction to A/B Testing

The speed of iteration of Internet products is very fast. It is often released on a Monday basis. It was launched in January 1. The various requirements and changes raised by the product are to improve the product experience and hinder product progress, if there is no data for reference, it is not rigorous to determine whether the product is successful or not. The product's success cannot be based on luck or possibility, but on data, speaking based on data, A/B Testing is one of the many data types.

The so-called A/B Testing is an effective way to help the product quickly test changes. For example, the navigation bar of the PC site starts on the left side, and it is changed to the right side by A product iteration, how to check whether this simple change is effective and how to judge how to improve the conversion rate? Of course, we can check the changes in the conversion rate after the launch. However, this test is not the most rigorous practice. A better method may be:

Divide users into two groups, one group uses old products, the other group uses new products, and then compares the data of the two groups of users to determine whether the change is effective.

The following are some features:

① There must be at least two versions (generally two versions)

② Dynamically control the traffic to each version

③ The conversion rate of each version can be detected and data can be collected

By reading this article, you can understand the implementation of A simple front-end implementation scheme of A/B Testing (most A/B Testing is based on the server)

This article is my personal framework and business development experience. I hope it will be useful to you andSupport Discussion, Pointing outInsufficientAnd some of yourSuggestions.

Address: https://github.com/yexiaochai/mvc/

If you are interested in this article, we suggest you read these two blogs first:

[Mobile front-end development practices] H5 development instructions from scratch (statistics, requests, MVC and modularization)

[Componentized Development] how to compile maintenance and upgradeable code in the front-end advanced article

Front-end implementation

When implementing code, we first grasp a key point: Pay attention to changes in conversion rates of different versions. Here, the conversion rate is the data submitted by order, so here we can draw a conclusion (different projects)

When creating an order, you need to record whether the order comes from solution A or solution B. In this way, we can finally get A data:

How many orders are created in solution A today, how many orders are created in solution B today, and then fine-tune the traffic of different solutions so that we can compare whether the change is meaningful.

PS: Generally, A/B Testing targets large-volume pages.

Originally, A/B Testing may also need to ensure that A user always uses the previous solution to access A page. This implementation depends on the actual needs of your project.

According to the following requirements, I have obtained the Code requirements:

① There is a scheme to allow both the new and old pages to access at the same time ② There is a scheme to control the proportion of access to the new and old pages ③ There is a scheme to get the final order data of each page (Scheme)

Here, we still take the list product list page as an example. We may need to record PV for different solutions. here we can use Baidu statistics products to complete custom events. We will not pay attention to them here.

Both solutions exist simultaneously

The first feature we have completed here is that the two solutions exist at the same time. Here we have done one thing: copy the original pages as a previous version:

Because the framework is cheap, we can perform simple operations during Instantiation to achieve two sets of code that can be accessed at the same time. For example, we have the url with a plan = B to access the old code, here, we will change the position of the toolbar below:

Of course, I have to say that this change is very silly, but we don't know how the product will work. Here is just an example. Here we simply changed the main. js code:

1 (function () {2 var project = '. /'; 3 var viewRoot = 'page'; 4 5 6 // you only need to perform A/B Testing 7 var viewMapping ={} on the list page {}; 8 var ver = 'ver/1.0.0/'; 9 var APath = 'pages/list/list'; 10 var BPath = ver + APath; 11 viewRoot = ver + viewRoot; 12 13 // default latest scheme 14 viewMapping. list = APath; 15 if (_. getUrlParam (). plan &&_. getUrlParam (). plan = 'B') {16 viewMapping. list = BPath; 17 project = '. /'+ ver; 18} 19 20 require. config ({21 paths: {22 // root directory of the relevant BUS template 23 IndexPath: project + 'pages/Index', 24 ListPath: project + 'pages/list', 25 CityPath: project + 'pages/city', 26 27 TemplatePath: project + 'templates', 28 29 BusStore: project + 'model/bus. store', 30 BusModel: project + 'model/bus. model '31} 32}); 33 require (['abstractapp', 'uihead'], function (APP, UIHeader) {34 35 windows. APP = new APP ({36 // configure A/B Testing37 viewMapping: viewMapping, 38 UIHeader: UIHeader, 39 viewRootPath: viewRoot40}); 41 window. APP. initApp (); 42}); 43 })();

Control traffic

The second thing we need to do here is to control the traffic. If you want to keep the last solution for the second time, you can use localsorage. Here we simply use random number control, the above code is optimized here:

1 (function () {2 var project = '. /'; 3 var viewRoot = 'page'; 4 5 // you only need to perform A/B Testing 6 var ver = 'ver/1.0.0/' on the list page /'; 7 8 // set the proportion parameter here, the number is 0-10, the default A scheme is 10, only use the latest scheme 9 // The proportion of a scheme is 60% 10 var APlan = 6; 11 12 // generate a random number from 1 to 10. If the condition is met, it is plan B 13 var abRandom = parseInt (Math. random () * 10); 14 if (abRandom> = APlan) {15 project = '. /'+ ver; 16 viewRoot = ver + viewRoot; 17} 18 19 // use the old scheme 20 if (_. getUrlParam (). plan &&_. getUrlParam (). plan = 'B') {21 project = '. /'+ ver; 22 viewRoot = ver + viewRoot; 23} 24 25 require. config ({26 paths: {27 // root directory of the relevant BUS template 28 IndexPath: project + 'pages/Index', 29 ListPath: project + 'pages/list', 30 CityPath: project + 'pages/city', 31 32 TemplatePath: project + 'templates', 33 34 BusStore: project + 'model/bus. store', 35 BusModel: project + 'model/bus. model '36} 37}); 38 require (['abstractapp', 'uihead'], function (APP, UIHeader) {39 40 windows. APP = new APP ({41 UIHeader: UIHeader, 42 viewRootPath: viewRoot43}); 44 window. APP. initApp (); 45}); 46 })();

So we achieved simple traffic control. Here we control the latest 60% access solutions and the old 40% access solutions.

Data Records

The last step we have done here is data record. According to our interface design, we can add a common field here:

PS: if you do not understand it, please refer to this blog: [Mobile front-end development practices] from scratch (statistics, requests, MVC, modular) H5 development instructions

head: {    us: '',    version: '1.0.0',    plan: ''}

Each time we create an order, this parameter will be passed to the server, including the version and channel. Now we can collect this parameter on a plan server.

There are multiple methods to record this plan. You can release the global method or inject this parameter to the APP. Because there is no interface to submit here, we will skip it here.

Conclusion

Today, we briefly introduced the concept of A/B Testing and implemented it from the front-end perspective. The solution has not been fully implemented in the actual project, this article may be improved after it is implemented in the project.

Important

If you think this blog is helpful to you, I would like to ask for a thumbs up !!!