This is the 19th day of my participation in the Gwen Challenge in November. Check out the details: The Last Gwen Challenge in 2021″

One, buried logic

  • Interface – Event – Event parameters

Each event on each interface has a unique identifier ID. In addition, there are public parameter statistics in each interface, such as userId, TIMESTAMP, taskId, etc.

Two, how to test the buried point

1. A common way is to check the data corresponding to one’s own APPID periodically on the third-party statistical platform.

  • The advantage is that the data of third-party platforms are often analyzed and summarized, and the display is very intuitive.

  • The disadvantage is that the data of these platforms are not always updated, and the stability of third-party statistical platforms also needs to be considered, so it is impossible to confirm the accuracy of data in time.

Mainstream APP statistics tools: U-App, Talking Data, OpenInstall, Google Analytics

2. Another way is to start from the client and look at the buried logs of development.

1) Android platform with Android SDK

Environment and Data Preparation:

① To build the DDMS environment, you can use Android Studio, or directly use the Android SDK with Monitor.

② Get the buried point field table, which is the basis of the development of buried point, and the standard of product analysis.

③ Take the buried installation package and output the log of the buried APP.

Test method:

① After the Monitor is switched on, connect the mobile device.

② Set filter for logcat and enter the package name.

③ Check the buried point field table, perform the operation of the buried point, and enter the APP operation on the mobile phone.

④ You can view operation logs by viewing DDMS logcat.

⑤ Check whether the buried point is correct, the error is generally:

  • A) Leakage point.
  • B) The buried point does not correspond to the operation type. For example, “Next step” is clicked, but “return” is reported.
  • C) The buried point does not correspond to the operation frequency, for example, the operation is performed once but reported twice

2) Xcode for iOS

Environment and Data Preparation:

① Install Xcode and download it directly from the App Store.

② Get the buried point field table, which is the basis of the development of buried point, and the standard of product analysis.

(3) find the development to have buried the installation package.

Test method:

① After activating Xcode, connect to mobile device.

② Select debug-Devices.

③ View the buried point field table and perform the operation on the buried point.

④ Check the accuracy of buried points.

3) Small program platform

Small program buried point was implanted through script code, js scripts through the built-in app, the app has his life cycle, when open the small program will trigger a request, can put the things we want to do with the request and the corresponding need to collect the component, events are added to the list to monitoring, according to the needs of the json collection of components, Binding the corresponding class and handling the listening callback will satisfy the conditions we need to collect when the page is being viewed.

3. Precautions for buried point data

(1) Encoding format: When the value of buried data is Chinese, especially the encoding format should be paid attention to. To avoid data parsing errors on the server, the client generally needs to transform the encoding format of the sent data.

(2) Case: The value of buried data should be named in the same way as the server data group, especially case.

(3) Full Angle and half Angle: When the value of buried point data is in English, it is often easy to ignore the input mode of full Angle and half Angle, sometimes resulting in unacceptable errors.

(4) Data format: The data format of buried data should be simple and clear in the definition, especially the non-real-time data transmission mechanism. The amount of data sent out is large and many are sent out from the same buried point, which needs to be integrated.

(5) Sending time: Sending buried data is often a common function, and sending time is generally divided into two types: real-time and non-real-time. Therefore, the data sending function exists as a separate module, and other functions can be called, so as to avoid the separate processing of all modules when sending and increase the test cost.

(6) The naming rules of buried data: the standardized naming rules of buried data are conducive to data reading and viewing, for example, the Page click starts with Page, and the region starts with Label as prefix.

(7) Buried point of presentation: the most critical point is to avoid repeated statistics. For example, when a user searches for “Huawei mobile phone” in a Certain treasure, the results of “Huawei MATE40 mobile phone” and “Huawei MATE40” are almost the same, losing statistical significance.

(8) Buried point of click class: the key is to avoid repeated statistics caused by continuous click when the server times out.

(9) Burying point of status class: The key is to avoid the default state statistics. And the state class buried point statistics must be the final state. For example, if you switch from on to off, the final state data sent must be the closed state.

(10) Burying point of counting class: the key is to avoid omission. In general, the count buried points that are not sent in real time are prone to omission, because they involve database reading and writing, so special attention should be paid to them during testing.

(11) Web page cache: for web page buried point statistics, to consider the problem of web page cache. Information details page, for example, have to stay long, timing starts when entering information details page count, not the end of the page, so this time we will consider to switch each other in Taiwan before and after the existence of multiple, is problems before the browser will cache the length of the pages made statistics shall be sent to the server.

(12) Network environment: when the network is particularly poor, the client fails to send buried points. In this case, the data that failed to send should be saved locally and sent together when the next condition is met, so as to avoid the situation of losing data.

(13) Overlaying installation: after the product is upgraded, the buried points before the upgrade cannot be deleted, but should be saved locally and sent out when the conditions are met after the upgrade.

(14) Server-side pressure: there are real-time and non-real-time data transmission. When the real-time data volume is particularly large, it is easy to cause pressure to the server, so special attention should be paid to it during the test.