Front end monitoring and front end burying point

Front-end monitoring and front-end buried point, one is the purpose, one is the way to achieve, do front-end buried point, is to do front-end monitoring, then why do front-end monitoring?

The purpose of front-end monitoring is:

Obtain user behavior and track the use of products on the client side, and point out the direction of product optimization based on the monitoring data.

The front-end monitoring

Front-end monitoring can be divided into three categories: data monitoring, performance monitoring, and exception monitoring.

Data monitoring

Data monitoring is to monitor user behaviors. Common monitoring items are as follows:

• PV/UV:PV(page view) : page views or clicks; UV: Refers to the number of people visiting a site or clicking on a news item from different IP addresses
• The amount of time a user spends on each page
• What entry point does the user use to access the page
• Actions triggered by the user on the corresponding page

Statistics of these data are meaningful. For example, we know the source channels of users, which can promote product promotion, and know the time that users stay on each page. We can increase advertising push for pages that stay longer, and so on.

Performance monitoring

Performance monitoring refers to the performance of the monitoring front end, mainly including the monitoring of web pages or product experience on the client side. Common performance monitoring items include:

• First screen loading time for different users, different models and different systems
• Bad time
• Response time for requests such as HTTP
• Total download time for static resources
• Page rendering time
• Page interactive animation completion time

The results of these performance monitoring can show how well the front-end performance is. Based on the results of performance monitoring, the front-end performance can be further optimized, such as compatibility with animation effects of lower versions of browsers, faster first-screen loading, and so on.

Abnormal monitoring

Because exceptions can occur in the product’s front-end code during execution, exception monitoring needs to be introduced. Timely reporting of abnormal conditions can avoid the occurrence of online faults. While most exceptions can be caught by try catch, exceptions such as memory leaks and other incidental exceptions are difficult to catch. Common exceptions that need to be monitored include:

• Javascript exception monitoring
• Exception monitoring for style loss

The front-end buried point

Now that we’ve talked about the three categories of front-end monitoring, let’s talk about how to implement front-end monitoring. To realize front-end monitoring, the first step must be to collect the items (data) we want to monitor, and then submit them to the background, and finally carry out data analysis. The richness and accuracy of data collection will directly affect the quality of our front-end monitoring, because we will use this as a basis for guiding the future development of our products.

Monitoring data collection is achieved through the front-end buried point. At present, there are three common front-end buried point methods: manual buried point, visual buried point and no buried point.

Manual buried point

Manual burying point, also known as code burying point, is to write code manually, call the function of SDK of burying point, call the interface at the function of business logic that needs burying point, and report burying point data. Third-party data statistics service providers such as Umeng and Baidu Statistics mostly adopt this scheme.

Manual burying allows users to easily set custom properties, custom events; So when you need to drill deep and refine your custom analysis, use manual burrowing points.

The defect of manual burying point is that the project is large, the location of the burying point is too many, and the product development and operation need to communicate with each other repeatedly, which is prone to manual error. If the error occurs, the cost of re-burying point is also very high. This leads to long data collection cycles, high collection costs, and low efficiency. Because manual burying point needs to be completed by developers, every time there is burying point update or missing burying point, it needs to go through the online release process again, and the updating cost is also high, which has certain harm to the stability of the online system.

Visual burial point

Replace the above code burying points by means of visual interaction. Business code and buried code separation, provide a visual interaction page, input for business code, through this visualization system, can be customized in the business code to add buried events, etc., the final output of the code coupling business code and buried code. The disadvantage is that the control can be buried point is limited, can not be customized manually.

Visual burying points may sound fancy, but they’re actually not that different from code burying points. That is, a system to manually insert code burying points. For example, Mixpanel is one of the earliest visualization companies in foreign countries, while TalkingData and Zhuge IO support visualization burying points earlier in China. In 2017, Tencent’S MTA also announced support for visualization burying points. Compared with the difficulty of manual burying point update and the high cost of burying point, visualization burying point optimizes the data collection process in mobile operation and can support product operation to adjust burying point at any time, without going through the process of version release, directly pushing the configuration results to the front end, simplifying the data collection process and facilitating product iteration.

Most of the solutions for visualization buried points are based on Xpath, a language for finding information in XML documents, which can be used to traverse elements and attributes in XML documents.

No burial site

If there is no buried point, the front end automatically collects all events and reports buried point data, and the back end filters and calculates useful data. The advantage is that the front-end only needs to load the buried script once, while the disadvantage is that the traffic and data collected are too large, and the server performance is under great pressure.

The use of no buried point technology has mainstream GrowingIO, god policy.

conclusion

We need to choose different burial sites in different scenarios. For example, for simple user behavior events, you can use full buried points to solve; Declarative burying points are needed to address the need to carry a large number of business fields that are available only at runtime.

The code examples

With the theory out of the way, let’s look at some common core code implementations.

Collecting User Information

Through the built-in JavaScript object of the browser, we can collect some basic information about the current user. We will point the collected data to the backend script through the SRC attribute of the Image object instance and carry parameters, and then we can send the collected data to the backend. The reason for using Image objects instead of Ajax is to avoid cross-domain problems.

(function () { let params = {}; // document if (document) { params.domain = document.domain || ''; / / domain params. Url = document. Url | | '. / / the current URL address params. Title = document. The title | | '. . / / the current page title params referrer = document. The referrer | | '. / / on a visit to the page URL} / / window if (Windows & window. The screen) {params. Sh = window. Screen. Height | | 0; / / screen height params. Sw = window. Screen. The width | | 0; / / screen width params. CD = window. Screen. The colorDepth | | 0; } / / / / screen color depth the navigator if (navigator) {params. Lang = the navigator. Language | | '. // let args = ''; for(let i in params) { if(args ! == '') { args += '&'; } args += '${I}=${params[I]}'} let img = new Image(1, 1); let src = `http://www.funlee.cn/api/test.jpg?args=${encodeURIComponent(args)}`; img.src = src; }) ()Copy the code

You can use JavaScript’s built-in apis to get more information based on your actual needs.

Introducing buried code through script tags

<script> (function() { let hm = document.createElement("script"); hm.type = "text/javascript"; hm.async = true; hm.src = "http://www.funlee.cn/testAnalyze.js"; let s = document.getElementsByTagName("script")[0]; s.parentNode.insertBefore(hm, s); }) (); </script>Copy the code

Get the web phase response time

To accurately capture the performance characteristics of our Web application, we need to know the response time of the application at various stages, such as DNS resolution time, TCP connection establishment time, home page blank screen time, DOM rendering completion time, page load time, and so on. Fortunately, these information can be obtained through the Performance interface.

let timing = performance.timing, start = timing.navigationStart, dnsTime = 0, tcpTime = 0, firstPaintTime = 0, domRenderTime = 0, loadTime = 0; dnsTime = timing.domainLookupEnd - timing.domainLookupStart; tcpTime = timing.connectEnd - timing.connectStart; firstPaintTime = timing.responseStart - start; domRenderTime = timing.domContentLoadedEventEnd - start; loadTime = timing.loadEventEnd - start; Console. log('DNS resolution time :', dnsTime, '\nTCP setup time :', tcpTime, '\n first screen time :', firstPaintTime, '\ nDOM render completion time :', domRenderTime, '\n page onload time :', loadTime);Copy the code

CSS buried point

Of course, CSS burying points can only handle some simple event burying points, and collecting complex data still needs JS. But CSS burying points have the advantage that they cannot be disabled.

For a complete instance, please: CSS buried

The core code is as follows:

<style> .link:active::after{ color: red; Content: url (" http://192.168.1.110:3000/someapi? params=someInfo"); } </style> <a class="link BTN ">Copy the code