Talk about burying point and monitoring

Talk about burying point and monitoring

Original intention

Recently, it has been discovered that most front-ends are in a relatively rudimentary state for burying and monitoring, and there are relatively few related articles.

Recently, in the community, I found some articles about burying points, but I always feel that it has taken everyone away.

1. What is a buried point system

Buried Point System = Buried Point SDK + Buried Point Visualization Platform + Buried Point Access Method

The problem to be solved by embedding SDK is the realization of some common functions of embedding, such as statistics of users' UV, PV, and so on. It mainly sends relevant data internally to the backend of the buried point service. It exposes a set of APIs to facilitate our access.

The problem that the embedded point visualization platform solves is that when my embedded point data is reported, I can see the relevant data. For example, what is today's UV and PV, compared to yesterday's month-on-month growth, and so on.

Buried point access method, this is the ability of the buried point system to open to the outside world. Generally, you will need to apply for an appid. This appid is unique. Then every time you report the buried point, you will know which project data it is.

In more detail:

The above statement is more general. For example, the embedding SDK is defined in more detail. In essence, it is a js file. This js file is provided by the developer. Of course, we can also make our own embedding SDK.

There is another reason why it is called SDK, which is that SDK is basically unchanged. Just like when we develop Vue projects, we need to import the vue.js file. We don't need to know how the vue.js file is implemented, we just need to know what the api it provides.

What the SDK does internally is to report data. The so-called report data is nothing more than sending an http request interface to the background server. Then store it in the database.

The embedded point visualization platform reads and displays these data from the database. The deeper level is nothing more than data analysis, conversion rate analysis and the like.

2. Burying and monitoring are two different things

Many students confuse burying points with monitoring. In fact, they are completely different within the big factory.

Functionally speaking, monitoring is mainly for JS error monitoring, interface exception monitoring, page performance monitoring, resource loading exceptions, and some custom exceptions.

The main things that Buydian does are data reporting, data statistics, and data analysis.

From the perspective of usage, monitoring can accurately locate errors. We don't need to add extra things to the code. We only need to introduce the monitoring SDK to achieve error monitoring.

And burying points is more about business behavior. At the business level, we have to decide by ourselves what data we want to know, how we want to bury points, and then what kind of analysis we need to do after we access the burying point SDK. Call the api of the buried point for data reporting.

Therefore, it must be clear that burying points and monitoring are two different things.

3. There are differences in the realization of burying points and monitoring

The implementation mentioned here refers to the implementation principle of this related SDK.

What is the realization principle of buried point?

The essence of embedding is data reporting, which must be inseparable from such latitude data: geographic location, page path, browser information, userId, timestamp, and so on. Information like this should be automatically carried when the user reports it.

Some reported data may be related to the business. Add an ID similar to the business identifier in the provided embedding api to associate the relevant data.

What is the principle of monitoring?

In fact, it is nothing more than implementing several abnormal monitoring within the SDK.

JS errors can be monitored using window.onerror.

The interface is abnormal. The current request is generally a fetch or ajax request. We only need to wrap them in one layer, and get our information in the corresponding response event. If the request is not 200, the error is directly reported.

Page performance is mainly achieved through an object provided by the browser, Performance-related api, which records the time occupancy of the browser to load and parse resources.

Resource loading error, the simplest way, can be achieved through the onerror event. Script can be used, img tag can be used.

These expressions are more general. For example, in js errors, errors about promise and vue need to be supplemented in error capture.

4. Solution-Ali Yueying

Of course, the most practical thing is to let everyone try monitoring and burying points, and I recommend you to use Ali open source product-Yue Ying

It's super easy to use.

Address: yueying-docs.effirst.com/yueying-int...