The buried point design document is for the development of the buried point requirements specification, the purpose is to make the developer understand which buried point collection needs to be done under what circumstances, as well as the specific types and values of attribute parameters, so as to ensure the accuracy and perfection of the collection. In order to achieve the overall index system, the landing and use of data products, it is necessary to design a buried scheme for the development, which is conducive to unified management, modification and maintenance in the future. Ensure that the caliber is uniform, traceable and easy to understand.

As an important part of data construction, buried point design directly affects the quality of subsequent data application and data traceback, but do we often encounter the following problems in our daily life:

Through the reproduction of the above scene, so you realize that we are responsible for burying the design, not only a tool person, if the underlying construction is not good, it will cause a lot of waste of resources and time costs, as well as the availability of their own data is greatly reduced. As a designer, we should give ourselves, and internally, especially managers, a correct attitude towards the construction of burial sites. This is a systematic project. Only when burial sites are clearly defined and traceable, business changes can be iterated, and important requirements can be covered, can we avoid late rework, reduce unnecessary waste of time and cost, improve efficiency and improve data accuracy. Improve data utilization.

So the question is, how to do a good job in the overall planning of the buried site design and the management of this project? Can be divided into the following three parts:

If you want to deeply analyze the business and form a data driver, you must need to add more custom code embedding points on the basis of preset events. Custom burying points have higher flexibility, autonomy and application. According to the core requirements of the business, the designer should form an event design document and deliver it to the R & D team for data access.

Each event has a fixed number, the number is unique and can not be modified, convenient for document access, backtracking, management.

Each abstract behavior event, a Chinese name and an English name, must be an one-to-one correspondence between Chinese and English, which cannot be repeated and represents the same meaning.

For the naming of events in English, to avoid confusion, it is necessary to adopt a unified standard for naming. The recommended rules are–

Each event attribute, a Chinese name and an English name, must be an one-to-one correspondence between Chinese and English, representing the same meaning.

This column is intended to clarify the meaning of the attribute field for R & D personnel, as well as the description of special circumstances, so as to facilitate the understanding and reality of R & D personnel.

It is necessary to specify when each event should be triggered, and if an event may be triggered at multiple times, all the trigger times need to be sorted out. For example, “Click to start Registration event” should be triggered when you click to register, but registration usually has multiple different entrances. Therefore, business staff need to clearly enumerate which registration entries need to be buried by R & D personnel. If there is a distinction between attribute values, it should also be marked to avoid omission.

The event burying point form supports both the front end and the back end. When triggered at different times, the data obtained are inconsistent. For example, the registration event is triggered when the front end submits the registration, and it is not clear whether the registration was successful or failed. Triggered after the back-end registration returns the result, it can not only specify the registration result, but also avoid the loss of front-end data. In general, core business process events are recommended to be buried at the back end to ensure the accuracy of data, such as product purchase, successful registration, etc. In special cases, the embedding point can also be carried out by the cooperation between the front and rear ends, in which one end transmits the collected data to the other end, and then the event burial point is triggered by the data receiver.

User attributes should be those that describe the long-term status of users, such as demographic information, account information, and so on.

Common attributes are those of all events, such as the platform on which the event occurs, the business module to which the event belongs, and so on. Public attributes can be ignored when there is no business requirement.

Abstract observe the behavioral events of the indicator, such as want to observe the payment conversion rate? The clear definition of payment conversion rate is that the application starts-enters the product list page, browses the product details page, submits the order-payment success conversion rate, and abstracts each behavior as an event.

To observe the conversion rate of payment, the business demand is far from enough, we also need to observe the conversion rate of different commodity prices, the conversion rate of different stores, the conversion rate of different commodity categories, and so on. Therefore, it is necessary to add event attributes to events that can record these relevant information, so as to facilitate the separation of dimensions later. As shown in the figure, browse the product details page to add commodity-related attributes.

Complete the trigger form, English naming, burying point, attribute value type and attribute value example of the event.

If you want to see the difference in user conversion rates between different genders and different registration months, you need to add user attributes.

In more business scenarios, there are many complex data, such as the bank loan business database, the risk control level calculated for each user can be imported as user attributes.

For example, in retail offline transactions, the behavior is not online, or in online education, the recall of customers’ offline phones cannot be used as online behavior data collection. This kind of data stored in the business database can also be abstracted from events and attributes. Use the business database import method, and determine the import cycle frequency (daily, weekly, etc.), import regularly.

The designer should confirm the feasibility and cost of event and attribute collection with R & D one by one, and make a choice between the high cost and low-importance requirements, and make the overall priority schedule.

For example, button clicks in similar scenarios can be merged, instead of clicking on one event at a time, it needs to be merged into one event.

For global events, we recommend that they be designed as the same event, distinguishing specific operations by specific property values, rather than designing an event for each operation.

For example, a content platform has videos and articles. Because the attributes recorded in videos and articles are quite different, the details of browsing content should be divided into browsing video details and browsing article details.

For example: collecting goods, browsing product details, although there is little difference in attributes, but there is little business relationship between collection and browsing, and is usually analyzed separately.

The required attributes of each event are not much different, but the usual analysis scenario is a single analysis, and the business meaning is quite different.

In online education users, there are multiple user identities, such as teachers, students, parents and so on. It is necessary to distinguish the user attributes and set the attributes of users with different identities.

As with other events, only the timing of the exposure event should be paid attention to, for example, the trigger time of the content exposure event of a platform is:

Virtual event is the merging and splitting of meta-events, which is a special function. Therefore, in the event burial point design, if the virtual event can be satisfied, there is no need to add new burial points.