In just a few years, wechat mini program has grown from a small sprout to a towering tree, forming a large-scale developer ecosystem, especially in the payment, offline vertical field has great potential.

As a leading life service platform, the technical team of Meituan has also carried out a lot of exploration and practice in the field of small programs. For example, MPVue is a front-end framework for using vue.js to develop micro channel applets, and it has been verified in meituan comments on several practical business projects. For details, you can read “Developing micro channel applets with Vue.js: Open source framework MPvue Analysis”. Currently, mpvue is open source, the project address is: https://github.com/Meituan-Dianping/mpvue.

This article will introduce the practice of scanning code payment applet, which is based on the speech “Pioneer journey of Financial Scanning code payment H5 migration applet” given by Chen Yao, a front-end engineer of Meituan, in the 31st technical salon of Meituan (click to check the Slides and videos of the four speeches in the salon).

Pictures 0

What is scan pay applets?

Meituan Scan payment is an offline order collection service launched for C-terminal consumers. I believe you have already experienced it in many offline restaurants and other life service businesses. This service is mainly provided through small programs. In actual scenarios, users first use the “Scan” function of wechat to scan the qr code of merchants, and the system will automatically call the scan code payment small program to enter the payment page, and finally enter the amount to complete the payment of goods.

Picture 1

Objective and data analysis

The most core indicator of payment services is obviously the percentage of successful payment by users, which we call payment conversion rate. For scan payment business, the higher the percentage of payment conversion rate is, the higher the turnover of scan payment business is, and the income it brings is positively correlated. Therefore, it has become an important task for our technical team to improve the conversion rate of scanning code payment. Through data analysis, we found that conversion rate loss mainly exists in the following two aspects:

  • Scan code to enter the small program link (external link)
  • Enter the mini program to the payment link (internal link)

From scanning code to entering the mini program, wechat will complete basic information acquisition, resource preparation (code download or update) and other preparations for the mini program. In preparation, if the preparation fails or the waiting time is too long, users will leave. This part of the link controlled by wechat is called external link.

Into the small program to pay link, the page will be rendered, data request, etc., if the rendering time is long, the data request also easy to cause the user to leave long time, also, if the data request failure also can cause the user use process is terminated, this part is controlled by a technical team Meituan scan code we pay for the link, called internal links.

Picture 2

How to improve the conversion rate of external links?

For the small program developers, the scan code to the small program to tune the link is a black box, we can not know the details. While we tried to comb through the small program with wechat students and found that the small program had a high loss rate in the external link. After querying the data, we found that most of the users manually clicked the exit on the upper right corner.

From a business perspective, users who use the scan payment applet can be considered to have a strong demand for payment, and part of the reason for users to manually click out may be the long waiting time. In this part of the time impact is more resource preparation, that is, the small program code download or update behavior. As a rule of thumb, there are two possible factors affecting download and update times: one is the network and the other is the code package.

Because the user’s network is out of our control, we try to start with the code package. Without subcontracting at that time, our main package size was about 3M, which meant that both new users and users of cached applets had to wait around 3M to download their first use of the package. In this case, while users enjoy the benefits of the applets offline cache package, most of the new user experience is lost. So we tried some optimizations at the package code level:

  • Added subcontract loading mechanism. When users use the scan payment service, they will load it on demand to optimize the download time for the first startup of small programs.
  • Reduce the size of main packages and subpackages. Optimize for the concept of an empty main package. After the subcontract loading mechanism, the primary package can’t be minimized and affects the first download time. On the one hand, in the original 3M package, the image size occupies 50% of the size. We distributed all the embedded binary and Base64 images to THE CDN. On the other hand, part of the transferable business was distributed to other subcontractors.

After doing these things, the sweep subcontracting was reduced from the original 3M whole package to 361K (main package 300K+ subcontracting 61K), and the conversion rate of external links increased by 3%. Although the conversion rate has been improved, part of the conversion rate in the pre-stage is still lost. Theoretically, the main package of 300K can be effectively reduced, but due to the nature of the business, it cannot be further reduced. Therefore, we proposed the concept of independent subcontracting to wechat Small program: users do not need to download the main package when using independent subcontracting.

Picture 3

Through independent subcontracting loading, the program only needs to load 61K subcontracting size during the download and update phase. At present, this function is still in the gray stage, scan code to pay small program team is also in the first batch of internal test user experience, optimization effect in the later practice, we will also share, we can pay attention to the United States technical team public number, continue to pay attention to us.

How to improve the internal conversion rate?

In entering the small program to pay this link, belongs to our business process. The loss of conversion rate in this process is something we can control, but we have to have a basis for it. So we did some data monitoring:

  • Business core process monitoring. The core business process refers to the intermediate process that affects the final payment after users enter the small program. The loss of the intermediate process will directly affect the loss of the entire conversion rate of the business, so it must be monitored here. The monitoring of the core business process requires specific indicators that can be monitored. We disassemble the key actions of entering the mini program and payment, from the beginning of code scanning to the user seeing the page, and then click to pay, initialize the order and pay successfully. After disassembling these key actions, disassemble the technical indicators for each controllable link. Key indicators (scan code loading conversion rate, click willingness, etc., as shown in the figure below) are formulated for each step from entrance to exit, forming a top-down funnel and producing multiple quantifiable indicators for monitoring business processes. For these quantifiable indicators, the conversion rate can be improved through long-term observation and analysis.
Picture 4
  • Abnormal monitoring. Any exception to the page can cause the rendering of the payment page to fail and the payment cannot be made properly. We monitored the abnormal interface and wechat API of the page. Interface exceptions can be directly caught in the FAIL function of API (wx.request) and reported for monitoring. Timeout for interface, only through the global app. The json to global Settings (the default 60 s, time is too long, for the user experience is poorer), after we have tried to set the global 5 s in the small program request timeout, but not all the scene in the actual application needs, set up unified timeout, finally we separate interface encapsulates the request timeout. The abnormality of wechat API can be monitored through some fail of wechat.
Picture 5

  • Performance monitoring. The white screen time and interactive time after entering the small program are concerned in the internal conversion process of the small program. The internal white screen time starts at onLoad and ends at onReady. Internal interactionable time ranges from onLoad to clickable payment time when the page data request ends.

  • In daily monitoring, we also found some problems, such as interface call timeout, interface call failure, these problems will lead to the termination of page flow. We made some optimizations for these issues:

  • Interface merging. There are a large number of interface requests on the payment page, and the failure of any interface will lead to problems. Merging interfaces can reduce the probability of problems and improve the conversion rate of the intermediate process.

  • Add retry mechanism. In the case of an interface exception, the page will directly block. If the retry succeeds, the conversion rate can be improved. There are two types of retries in the whole process: proprietary interface request exceptions and applet API call exceptions.

For these two types of exceptions, retry is adopted when the interface times out or the invocation fails. In extreme cases, the number of page retries is controlled based on Retries when obtaining global configurations. In addition, each retry must be manually triggered after a period of time. When the number of retries exceeds, the process terminates.

How to monitor internal and external processes?

We also mentioned before, for small program developers, scan code to small program tune up this link is a black box, we developers can not know the details here, so in terms of monitoring external links we developers seem to do very few things. However, I wonder if you have noticed that wechat will attach a scancode_time field to the query parameter after every code scan. In fact, this field represents the time recorded by the wechat server when the user uses the scan. Therefore, based on the consideration of this field, we made the following attempts and conducted real-time monitoring respectively for the following two parameter values:

  • White screen time of the payment page (client time when the user sees the first screen – time when the user scans the server through wechat + time between the server and the client).
  • User interaction time of payment page (page Loading completion time – user wechat scanning server time + server client difference time).

Since the client timestamp is the time to obtain the local mobile system, there may be differences. So in order to guarantee the accuracy of the report, we took every time the onLoad time we server time, record the client and server a time difference, and in the subsequent all involve the server time are calculated with reference to the time difference do (network level of 100-200 ms of transmission delay, temporarily negligible).

But because we sweep yards special application scenario is pay a small program in order to ensure users a quick and reliable payment, since in external link control level is not high, if it is can be considered in terms of internal business processes to do a fine-grained monitoring statistics, can do it for every data may affect the payment link to follow? In view of this direction, different from the traditional PV and UV statistics, we classified the business report as follows:

  • According to the reported scenarios, the real-time monitoring part and the statistics part are divided.
  • The report types are Error, Event (common life cycle events), Metric (user-defined events, dimensions can be customized), and custom speed measurement (delay trend and distribution).

Based on the exploration of the above scheme, our team has basically achieved overall control over many business indicators that may affect the payment link. In the next step, we should further think and consider each potential optimization point, and then make timely strategy optimization and update. Through the scan code to pay small program exploration, we have accumulated a lot of optimization experience. The value of Meituan is the pursuit of excellence. We will further explore the aspects that can be optimized, and welcome more students to discuss with us.

Author’s brief introduction

Chen Yao joined Meituan in 2015. Before that, she participated in the front-end development of mobile terminal touch-screen version of Meituan platform, and participated in the front-end construction of smart payment application layer from 0 to 1. Now, she is responsible for the small program business of meituan’s order receiving business, scanning code payment business.

recruitment

If you are interested in our “smart payment big front End Team”, please send your resume to Chen Xiaoer directly ([email protected]). Welcome to Join Meituan and explore the future with us.