Online project, we need to statistics and behavior of users in the use of the product usage, through these statistical data processing and analysis, to understand the use of the product from the user’s point of view and experience, so as to better for iteration and upgrading of products, more in line with the user’s experience, more close to the user use habit. Therefore, we need to add some requirements for user behavior statistics in the business, such as:
Collect page views or clicks from users
The number of people accessing different IP addresses of a site
The amount of time the user spends on the page
Actions triggered by the user on the page
User scrolling behavior
These are the statistical points of user data, which is also the focus of front-end data monitoring. In addition to data monitoring, front-end monitoring also includes performance monitoring and exception monitoring. Performance monitoring includes:
First screen load time
Blank screen loading time
HTTP response time
Total download time for resources
Page rendering time
Page interactive animation completion time
Exception monitoring includes monitoring script and style exceptions.
Why do YOU need front-end monitoring
The buried point is the collection of user data, the acquisition of user behavior and the tracking of product user experience. After burying the site, the collected user data is monitored and processed, and based on it, the direction of product optimization is indicated, which is the source of product demand and the proof of whether the function meets the expectation. Data collection and reporting is an important part of the whole process. Only by ensuring the comprehensive, accurate and timely production of front-end data, can the final data result be reliable and valuable.
Front-end monitoring is divided into three types: data monitoring, performance monitoring, and exception monitoring. As shown below:
Data monitoring can know the source of users, promote the promotion of products, know how long users stay on the page, and promote advertising for pages that stay for a long time to increase promotion sources.
Performance monitoring enables developers to optimize products and enhance user experience.
By monitoring anomalies, you can report anomalies in a timely manner, avoiding online faults and reducing losses caused by faults.
The common workflow is as follows:
Front-end data acquisition
Front-end data acquisition is the front-end buried point and report, front-end buried point method has three kinds: code buried point, visual buried point and no trace buried point. The technical essence of burying point is to monitor the events in the running process of software application first, and judge and capture the events that need attention when they happen.
Code buried point
Buried code is embedded in the form of embedded code, for example, the user clicks events to trigger an interface call, we can click on the call interface, insert a piece of code or pass in some parameters, the data directly to the server. Such as:
When a user logs in to the application, the user information can be sent to the server to count the login times of the user, or other information.
When a user clicks to jump to a page, the FROM and to routing addresses can be transmitted to the server for statistics, so that the user’s access track can be clearly known
Advantages: It can accurately send or save the required data information at any time.
Disadvantages: Heavy workload, buried code for each component needs to be added accordingly.
Configure and collect nodes through visual tools, automatically analyze the configuration and report burying point data at the front end, so as to achieve the so-called “traceless burying point”, which represents the open source Mixpanel. You can learn about the use of Mixpanel from this article.
Advantages: Buried point only business students access monitoring, no need to insert code in the development.
Cons: Limited configurable components, no manual customization, only visual tools.
No burial site
No burying does not mean that no burying is required, but rather that all front-end events are bound to a single identifier through which all related events are recorded without the need for developers to add additional code. By defining the upload record file and coordinating with the analysis file, the data can be turned into the data we want, and the data analyst can analyze and realize the statistics without buried point. The representative scheme is GrowingIO in China. GrowingIO is not free, you can have a free account to use during development testing, and you will have to charge once the project is launched.
Advantages: no need to develop, business personnel can be buried; Report it first, bury it later.
Disadvantages: SDK developers need to provide a set of non-trace buried point technology products, including the correct acquisition of PV, UV, Action, Time and other statistical indicators. Large technical input in the early stage.
Unburied point and visualization buried point do not need development support, only data business students can set. However, there is a big difference between data reporting and burying point setting: Burying point setting can be performed after data reporting without burying point, so the amount of data collection and reporting is much larger than that of visualization burying point.
When to monitor
After introducing the above three embedding methods, how do we apply them in product projects? When do we bury them? Where do we monitor them?
In fact, the monitoring time is divided into three parts:
The user enters the application initialization
User interaction in the application and response after interaction
An error triggered by a user in the application
How to Design monitoring
How do we design the data that our products need to monitor? We need to consider the real user experience data on the Web side and monitor the health of the front end from three aspects: access speed, page running stability and success rate of service invocation, so as to constantly upgrade and iterate our products.
It can be broken down in the following ways:
Page performance logs: Network request time, DOM parsing time, resource loading time, blank screen time, page full loading time, etc.
Access statistics logs: Collects PV and UV data
Page stability logging: Monitors the error rate of page scripts to measure page stability
Interface invocation log: Provides information about interface invocation results and time, helping developers quickly find and locate faults
User-defined logs are reported
How to optimize the reporting of monitoring data
After adding monitoring data, it may increase the pressure of interface request or page rendering, so we need to optimize our front-end monitoring code or request interface.
HTTP No Content
For example, to monitor the number of times triggered by a user clicking a button, we only need to report an event to the server without any return content. Therefore, we use the HTTP HEAD reporting method to avoid resource consumption caused by the response body responding to data, as long as there is a request status code record.
fetch(`${url}? t=click&page=foo&target=btn`, {
mode: "no-cors",
method: "HEAD"});Copy the code
The HTTP 2.0
HTTP 2.0 header compression
Each HTPP request carries some of the same request resources and features, such as HOST, user-agent, and Accept. The data takes 300-800 bytes to transfer. If cookies are also carried, the request header may occupy 1 KB of space, but only 50 bytes of log data need to be reported. In HTTP 1.x, the request header for each log report carries a large amount of duplicate data, resulting in a waste of performance.
HTTP/2 header compression uses Huffman Code to compress the request header and uses dynamic tables to update different data for each request, thereby reducing the header size of each request to a small size.
HTTP / 1.1
HTTP2
HTTP 2.0 multiplexing
Multiple HTTP requests are generated between the user’s browser and the log server. However, under HTTP/1.1 keep-alive, the log report is transmitted in serial mode and the subsequent log report is delayed.
However, HTTP 2.0 uses multiplexing to merge reports and save on network link overhead.
conclusion
In this paper, the following points are introduced:
What is front-end monitoring: statistics on user behavior and usage of the product
Why front-end monitoring is needed: to better iterate and upgrade the product, point out the direction of product optimization, and verify that the functionality meets expectations
When to perform front-end monitoring: when the user enters the application, when the user interacts with the application, and when the user reports errors during the interaction
How to design monitoring: from page performance, traffic, page stability, interface calls and so on
How to optimize monitoring and data reporting: Only the request header is transmitted, no value is returned. Uses HTTP 2.0 header compression and multiplexing features
When designing front-end monitoring, we need to consider various aspects to complete our monitoring without affecting business performance. Even in the case of a large number of business visits or high performance requirements, we also need to do a good job of front-end monitoring, which is an essential part of our product development and iteration, and also one of the methods for our product improvement and self-evidence.
The resources
You can see farther on the shoulders of giants
Front-end monitoring and front-end buried point design
Discussion on the problem of statistical data loss when the page jumps
Monitoring through buried pages without affecting performance? Decrypt the technical insider of ARMS front-end monitoring data reporting
