Before the preliminary study, I had thought about several questions:

  • Where is the value and significance of full burial point?
  • What is the collection point for full buried point?
  • Is data collection abundant?
  • Does it meet product and big data needs?
  • Is the data collected accurate and timely?

Full buried point concept

Fully buried points are also called unburied points. When the user presents an interface element, events are triggered by the control binding. When the events are triggered, the system has corresponding interfaces for the developer to handle these behaviors

Advantages and disadvantages of no buried point technology

One, the advantages of no buried point:

  1. Global configuration takes effect after the configuration is complete and does not require redeployment

  2. No additional development for a module is required

  3. User actions are collected completely and will not be lost

Two, no buried pain point:

However, its disadvantages are also very obvious, and there are also the following problems:

  1. Useful and useless data will be collected

  2. It does not have the flexibility and depth of code burying point, and cannot collect special behavior actions and business parameters. Most of them cannot meet the requirements of products, so the income is low.

  3. It can only collect the data visible to the user’s naked eyes, but cannot customize the attributes flexibly. The behavior record information is little, and the data in memory cannot be obtained

  4. The collected information can be identified by users only after secondary annotation

  5. If the location of a button is not fixed, the name of the button is duplicated, or the page is reconstructed, it cannot be accurately identified

  6. Unable to adapt to changes in page structure, so in actual production, selective use of unburied technology where appropriate

  7. Because all element data are collected, transmission pressure is great, timely uploading will bring great pressure to data transmission and server

To sum up, it can be concluded that:

  • Unburied points are generally used for coarse-grained rapid business exploration.
  • For our current project, the benefits brought by full burial point are not big. Although we can go back to some historical data, we can only know some very simple data, with little value and a lot of effort. For example, a button that has only one location and information doesn’t matter much if you know that a high percentage of people are hitting it. The SDK also makes it clear that the value of full buried points is not high.
  • As we all know, it is too unfriendly to report data in full. The amount of data is too large, which not only consumes more resources in the front end, but also increases the storage pressure in the background in order to do data backtracking, while most of the stored data is still invalid, so the cost is a little high.

No buried point scheme:

  • From the perspective of big data, the requirements for buried data are divided into: 1. Basic layer (SDK solution) 2. Business layer (SDK solution)

Buried points are based on the SDK

Because platform is different, SDK is also different, want to bury point still need to analyze case by case, what business platform, what SDK to use. There are also several available SDKS:

  1. GrowingIo (full buried point)

  2. Smart Policy (Fees)

  3. Baidu Statistics (free)

  4. TalkingData (charge)

  5. Google Analytics (free)

  6. Mixpanel (Visual burying Point)

  7. Friendly Alliance (charge)

Of course, in order to meet specific needs, there are also independent research and development, we previously on the exposure of buried points also developed a set of independent solutions.

Technical direction without buried point

I. Project analysis

At this stage our RN practice is based on APP (native). For example, a generic RN container will be entered from a native entry (native will pass an actionId to the RN container to identify which RN page to open), and all RN pages will jump within the RN container. Therefore, if we choose to access SDK, the cooperation of native developers will be required according to the situation of our project, which will naturally bring a certain amount of work to the native developers. Then, we may consider the full burying point on the JS level more.

Two, no buried target

For the full buried point, I analyzed the target and got:

Collected data = user behavior data + front-end health analysis

We can start in the following directions:

  1. Page browsing data: collect the user’s browsing page URL to form the user’s browsing path;
  2. User click data: Collect click behaviors, such as the xpath path, title or dom element of the click element
  3. Page loading performance (to be further studied)
  4. JS error reported (pending further research)
  5. Interface error reporting (to be further studied)
  6. Custom speed measurement (to be further studied)

Iii. Technical Keys (Later practice)

– The key to “no burial point” technology is:

  • Operate the visual configuration tool and save the configuration
  • How does SDK base code report behavior according to configuration

– “no buried point” technology implementation pre-plan

  1. The unique identity of the page
  2. The unique identity of the element
  3. Js Hook implementation principle
  4. How to find elements
  5. Highlighting and visual interaction implementation when marking elements
  6. Routing hop
  7. Event capture…

The above is the accumulation of some knowledge of the pre-research of the full buried site. In the follow-up, some technical schemes and specific practices of the full buried site will continue to be carried out. Please look forward to it.

Reference documentation

  1. React Native has no embedded SDK
  2. React Native burial points
  3. Smart data – Advantages and disadvantages of data acquisition without burying points
  4. Design and implementation of netease HubbleData unburied SDK in iOS terminal
  5. Whats – Element – Unique identifier calculation