An overview of the

At the early stage of project development, I designed a simple burial point framework for the product, which mainly solved how to define the burial point and how to manage the configuration of the burial point. As the project’s capabilities continue to expand, the simple AOP acquisition and manual buried point approach becomes increasingly inadequate in terms of iteration speed. There are too few business models to support. For example, short-term online activity analysis is very unfriendly. At the beginning of the activity, real-time user usage data is required, but after the activity is over, this batch of data does not need to be collected.

So how can we make the product students have data to analyze without updating the burying rules? My answer is to provide more granular burial data.

Scheme 1.0

Design of App data burying module

Take my current IM project as an example, using custom burial code to report burial data, such as users clicking the create group button 10 times within 1 hour. This type of data can be understood as result data, which intuitively provides a piece of data that does not need to be analyzed.

The advantage is that the server only needs to merge and group the data, which can be presented to the visual background, reducing the development cost and analysis and calculation pressure on the server. The disadvantages are also obvious, because the client has processed the data twice, resulting in data distortion, the operation of the original user can not be reversed through the results. For example, if a user is creating a group from the home page or from the address book, you need to add two more burial points for related entries, or modify the “create a Group” burial point rule to add data fields about the source, and wait for the next release to take effect

Scheme 2.0

If the reported data is changed from the design of specific customized burial sites to the statistics of user behavior, the product can be provided with more flexible and comprehensive data. For example, instead of reporting the number of times a user clicks to create a group within one hour, it is reported that the user enters the home page, the user clicks to create a group, and the user creates multiple burial points such as a group. At this time, the product again wants to analyze the behavior of users to create groups, so the back-end development can obtain data from the buried point database, and then analyze the number of times a user clicks to create a group within an hour through the analysis rules, and the proportion of source distribution can also be analyzed at the same time.

The advantages of this solution are as described above, namely, increased data integrity and the possibility of flexible analysis of the data. However, there are some disadvantages. For example, the client needs to report data in a shorter period of time, which consumes more network and system resources. The calculation of analyzing buried point data is centralized from the client to the server, which is equivalent to changing from distributed computing to stand-alone computing, increasing the pressure on server resource usage.

Therefore, at present, I choose to use two modes for collection. For need analysis, but the rule update frequency is low, so I still use client aggregation calculation and upload, such as the calculation of page stay time.

Burial point and collection point

In order to better standardize the use of buried point, first make a few abstract definitions.

Burial point type:

  1. Event type buried point, represents the occurrence of an event, can also represent an event process through the same event ID. For example, the user sends an image, and the user goes from startup to IM login.
  2. Page type buried point, representing the life cycle of the page. For example, the user opens the address book and enters the chat session.
  3. Status Type Indicates the status of certain configuration items. Such as whether the user has push notifications enabled, whether the user has facial recognition enabled.
  4. Daily Type Indicates that data is reported only once in a period of time. For example, the user logs in the same day.
  5. The count type burial point, derived from the event type, aggregates the burial points within a time period to represent the number of occurrences within a time period. For example, the number of times a user entered a chat session in an hour, the number of times a user sent a picture message in an hour.

Collection point type:

  1. Universal collection point, collection point can produce multiple buried point data of the same type. Like page jump, button click, App life cycle.
  2. Custom collection points, collection points correspond to the logic of a specific function. For example, after the creation of a group successfully, the API asynchronous callback buried point, the whole process of user login buried point.

User behavior Statistics

Designed to

It provides a context for the universal collection point, and carries out more detailed and full collection of the user’s behavior. At the same time, the design of the collection point does not involve the modification of the original logic code as much as possible, that is, the current widely used non-buried point mode.

User behavior chain

Whenever the user behavior is triggered, the user behavior model is created and the user behavior chain is added to form a linked list recording the user behavior.

User behavior types:

  1. Page jump types, such as page initialization, page display, page disappear.
  2. Type of button click, such as function button click (send emojis), reuse list click (enter personal details from address book).
  3. System event type, such as system push, system screenshot, and System mute.

Collecting User Behavior

Taking iOS as an example, AOP is used to Hook the page life cycle, gesture delegate, reuse list delegate, UIApplication event handling, etc., to complete the initial construction of collection points.

The Runtime feature of Objc is used here to implement method implementation replacement, which can be implemented using base class inheritance if the language does not support it, but is much more costly. Dynamic class creation is required for the delegate hook, which is similar to the system framework implementation mechanism of KVO. The implementation scheme is not too detailed. It is recommended to implement the collection of list click events in seven steps

Based on the collection point, the plug-in protocol is provided, and the plug-in implementing the protocol is registered in the user behavior chain manager to get the event-triggered callback, and then different customized buried points are generated according to different filtering rules.

Event identification

In order to analyze the current user’s behavior through the user behavior chain, you need to ensure that each event has an identifier. Rules are preset through identifiers, creating buried data for the behavior that triggers the rule.

Page jump type identifier

NavigationController is provided by iOS UIKit framework, which can maintain the page stack and get all page data from the following page to the current page.

For example, from the HomePage (HomePage) to the session details page (SessionPage), and then to the contact details page (UserInfoPage), the navigation path is HomePage -> SessionPage -> UserInfoPage. At this time, the different pages can be combined into a Class as a single page identifier page path is used, such as: “HomePage/SessionPage/UserInfoPage”.

If the current system framework does not provide such functionality, you need to set an identifier yourself, or use the Class name of the current page as the identifier, such as “UserInfoPage”.

Whenever a page jump is triggered, a user behavior model is created and added to the user behavior chain, so that the user’s historical page operation can be known only by querying the user behavior chain.

Key click type identifier

There are two types of keys, one for single use keys, the other for reuse list keys.

The use of keys alone may result in the reuse of UI controls and response functions of keys. It can be described by combining the Class name of the key, the response function name of the key, and the Class name of the page where the key is located.

For example, clicking the image (ImageView) in the session Details page triggers the pushUserInfo action on the contact details page. According to the rules of identifier generated, can form “SessionPage/ImageView/pushUserInfo” identifier.

The reuse list button is used in a dynamic list, and multiple buttons of the same type will appear at the same time. During the user’s refresh or scrolling, the associated data source of the same key may change, and the response function of the reuse list is almost the same function. At this time, in the identifier rule that uses keys alone, the response function name is removed and the key position information is added to reconstitute the identifier.

For example, if you click SessionListCell 3 in the session list in the HomePage, you can collect only the Class name of the key, the Class name of the page in which the key is located, and the relative position of the key (session 0, row 3). Can be combined into the HomePage/SessionListCell / 3-0.

If the data source changes, the data source model also needs to be resolved for a custom burial operation.

System event type identifier

These events are triggered by the user using the system function, such as the user taking a screenshot, the user clicking push. You can directly set the default string for identification.

User behavior analysis

It is often difficult to make a single judgment based on a user’s behavior data because of complex burial rules.

For example, from the HomePage (HomePage), use the GlobalSearchPage (GlobalSearchPage) to search for contacts. Click the contact to jump to the contact details interface (UserInfoPage). Click send message in the contact details interface (UserInfoPage). The session Details page is displayed. The requirement is whether the source of the statistics session details is the global search page on the home page.

When the collection point is triggered, we need to make a series of judgments

  1. Check whether the current user behavior is on the SessionPage.
  2. Check whether the latest page hop event is GlobalSearchPage.
  3. Determine whether the GlobalSearchPage is originally from the HomePage.

Note that the user behavior chain will record the full amount of user behavior, there may be repeated user actions, and the user behavior that has been counted will not be removed from the chain.

The depth of the query

We can stratify the user behavior chain according to the page jump behavior as the dividing line, and design the minimum query depth when hitting the buried point to avoid repeated statistics.

For example, the current user jumps from the HomePage to the GlobalSearchPage, and then returns from the GlobalSearchPage to the HomePage. Then the user went to other pages such as ContactPage to jump to more than a dozen pages, and finally entered the SessionPage from the contact details interface (UserInfoPage).

If you do not design the query depth, you can still find a record of user behavior in the chain that goes to the GlobalSearchPage. Simply determining whether GlobalSearchPage is a jump record will misjudge the source of SessionPage. If the query depth is set to 2, only the two previous page jumps (user details and global search) before the SessionPage are queried, and the previous user behavior records can be ignored.

Burial site validation

In order to verify the validity of the buried point data, in development mode, when each buried point is triggered, the relevant information should be printed to the console and written to the log file, and then the script verification log is used to ensure that the buried point of each step is correctly recorded.

Reference documentation

Meituan point evaluation front-end non-trace buried practice

Design and implementation of netease HubbleData unburied SDK on iOS