1 What is埋点

埋点 also known as event tracking (Event Tracking), refers to the relevant technology and implementation process for capturing, processing, and sending user behavior or events. In plain language: It is to 'listen' to the behavior of users in APPs and websites through technical means.

2 Role of埋点

If we want to collect user behavior data, we can achieve this through埋点.

• For example, if you want to know what buttons a user clicked in the APP, what pages they viewed, and what actions they took, etc.
• For example, if you want to know how many people have used certain features and the frequency of use, etc.

3 Usage of埋点 -- Overall introduction of data flow

3.1 Real-time data

• The source of real-time data starts from the click stream, the client SDK reports埋点 data, the collection service writes the reported埋点 into the JDQ write cluster, and then the data is summarized into the JDQ read cluster through the fregeta task.
• The downstream flink tasks will consume the original topic from the read cluster, then output the processed topic, which is provided for downstream business consumption.
• Downstream businesses such as: Gold Eye, Business Intelligence, Search Promotion, etc.

3.2 Offline data

• The source of offline data starts from the click stream, the client SDK reports埋点 data, the collection service writes the reported埋点 into the cfs network disk, and then the data is landed into the data warehouse through the offline data extraction service.
• The data warehouse will go through multi-level processing, process the data into the口径 required by the business, and provide it for data application use.
• Downstream businesses such as: Gold Eye, Business Intelligence, Search Promotion, etc.

4 Teams related to埋点

Responsibilities of each team:

5 Burial point process

5.1 Business product requirements

• The business product submits the requirements to the埋点 product first.
• Points to note: Any new or changed requirements related to埋点 need to be submitted to the埋点 product through the Zhiwen platform.
• Online issue: The purchase parsing failed in the JD APP mini-program on May 27, 2023, because the requirement was urgent and did not go through the meridian line. The product maintained the document itself, causing the downstream to be unable to parse after the field modification.

5.2 Set Buried Point Scheme

・After the埋点 product receives the requirement, it will start the review meeting to review whether the requirement is reasonable, whether there are omissions, whether the parameters are complete, whether it is necessary to notify the third-party business, and determine the schedule, etc.

• The埋点 product will formulate the埋点 scheme according to the review results in the meridian line
• After the埋点 product produces the埋点 scheme, it will involve business, development, testing, and data sides to participate in the scheme review to confirm whether the scheme is complete and whether the parameters are reasonable

5.3 Buried Point Development

• After the front-end R&D team receives the埋点 scheme, they will develop according to the埋点 scheme
• Points to note: Developers need to develop on the agreed埋点 online version branch, and pay attention not to go online prematurely
• Online issue: The order indicator on the search results page decreased at the hour level on October 12, 2023, because the埋点 was not tested and was released prematurely, causing the downstream to be unable to parse

5.4 Buried Point Testing

• After development is completed, the test needs to perform reporting rule verification, see: 6.2.2 Reporting Rule Test Case
• Testing performs field verification on the埋点 in the track platform, see: 6.2.1 Field Verification Test Case
• After the verification is completed, the test report is output. See: 6.3.3 track Platform Usage

5.5 Buried Point Acceptance

• The埋点 product verifies the test records in the test report produced by the test
• Data table validation is carried out at the same time

5.6 Buried Point Launch

• After the acceptance is completed, the version status corresponding to the meridian line is modified to online
• Front-end version goes online
• Points to note: Developers need to use the latest online master branch to pull a new development branch each time, and ensure that there are no other go-lives during the process of pulling branches. If there are, they need to be paid special attention to avoid covering the content of the last go-live.
• Online issue: The LBS related business dashboard data of Jingxiao on October 18, 2023 was abnormal, because the merged branch of the last online version was covered, causing the reporting to fail.

6 Main Quality Assurance of Buried Points -- Buried Point Testing

6.1 Common Problems with Buried Points

There are generally several common problems:

• The埋点 requirement did not go through the meridian line, and the reporting content was incorrect
• The business forgot to modify the埋点 reporting when modifying the logic
• The埋点 was not properly synchronized between upstream and downstream when it was launched
• The new field data structure is not compatible with the downstream

6.2 Buried Point Test Case -- Quality Assurance of Reporting Content

6.2.1 Field Verification Test Case

• Verify that the field names and field types of the埋点 reporting are consistent with those set in the scheme
• If the埋点 scheme has marked parameter length or the parameter is an enumeration, it needs to be verified
• If it is a nested JSON, attention must be paid to not destroy the original JSON structure

6.2.2, Reporting rules use case

1) PV scenario

Scene 1: Normally enter the page

• Behavior: Normally enter the PV page and stay
• Expected result: Normally report only 1 PV event tracking, and page_id, page_param and the document are consistent
• Special scenario:

• Tab nested page scenario: Only report 1 main tab PV event tracking when entering, and report another tab's PV event tracking when switching tabs. If 2 PV event tracks are reported when entering (1 outer large framework PV event track, 1 main tab PV event track), it is reported as an error; repeating tab switching will not report the same page PV event tracking again

• Easy to occur problems

• No PV event tracking report when normally entering the page, and event tracking is reported only when switching related tabs

• No PV event tracking report when entering the page, and PV event tracking is reported only when leaving the page

Scene 2: Go back to this page scenario

• Behavior: Normally enter A page and stay, and click an element in this scenario to enter the lower-level B page, and then go back to the A page
• Expected result: Native will report 3 PV event tracks, namely A, B, A, and page_id, page_param of A page and the document are consistent, and PV event tracking will not be reported when h5 goes back
• Easy to occur problems: Unreported PV event tracking for A page when going back to the previous page

Scene 3: Quick exit page scenario (mainly to solve the problem that pageParam parameters contain server-side下发 parameters, if the interface does not respond, PV event tracking also needs to be reported normally)

• Behavior: Normally enter the page and quickly leave the page
• Expected result: Normally report 1 PV event tracking, and page_id, page_param and the document are consistent
• Common problems:

Scene 4: Pull to refresh scenario

• Behavior: Normally enter the page, then pull to refresh
• Expected result: Pull to refresh will not report PV event tracking again
• Common problems:

Scene 5: APP switch to the background or lock screen scenario

• Behavior: Normally enter the page, then switch the APP to the background or lock screen, and then open or unlock it again
• Expected result: No PV event tracking will be reported again, in accordance with the specification
• Common problems:

2) Click scenario

Scene 1: Enter the page without clicking

• Behavior: Do not click the corresponding element
• Expected result: According to the event tracking document, if no default reporting is required, no click event tracking will be reported here (some event tracking has the logic of default click event tracking, and this kind of scenario meets the expected result)
• Common problems:

Scene 2: Normal click

• Behavior: Normally click the corresponding element
• Expected result: Normally report 1 click event, and event_id, page_id, page_param, event_param, json_param, et_model and the document are consistent
• Common problems:

Scene 3: Click without redirection (no function trigger, no interactive changes)

• Behavior: Normal click on the corresponding element without interaction
• Expected result: Do not report click埋点 event
• Common problems:

Scenario 4: Sliding埋点

• Behavior: Stop after sliding to browse
• Expected result: Report click埋点 event
• Common problems:

3) Exposure scenarios

Scenario 1: Normal entry into the page, at this time, the element is not exposed (test whether the exposure element is reported without exposure)

• Behavior: Normal entry into the page, at this time, the element is not exposed, and then leave the page
• Expected result: No corresponding exposure埋点 is reported
• Potential issue: Exposure埋点 reporting is performed without exposure

Scenario 2: Normal entry into the page, at this time, the element has been exposed (it is necessary to test the scenarios of the element just exposed, exposed 50%, and exposed 100%, to ensure that the space limitation and time of the element exposure are consistent with the埋点 document, and test the reporting timing and space limitation of exposure elements)

• Behavior: Normal entry into the page, at this time, the element has been exposed to the specified proportion, and then leave the page
• Expected result: The reporting timing of the element = the required reporting timing in the埋点 document (exposure reporting or leaving page reporting), and the reporting parameters remain consistent
• Common problems:

▪ The埋点 document requires exposure reporting when leaving the page, but actually reports exposure as soon as it is exposed, and vice versa.

▪ The埋点 document requires exposure only when 100% is exposed, but actually reports the埋点 as soon as 1 px pixel is exposed

▪ The exposure logic is inconsistent at both ends, and the exposure data volume of Android and iOS is greatly different

Scenario 3: Test the reporting timing of exposure elements

• Behavior: Normal entry into the page, at this time, the element is exposed 100%, and different scenarios of leaving the page are triggered: entering a sub-page, returning to the previous page, refreshing the page, switching to other tab pages, and entering the background in 5 scenarios
• Expected result: The number of exposure reports for the corresponding element = the number required in the埋点 document
• Potential issue: The埋点 document requires exposure reporting when leaving the page, but actually reports exposure as soon as it is exposed, or some scenarios are missed when leaving the page, resulting in timely exposure data not being reported

Scenario 4: Normal entry into the page (test the page-level deduplication logic of exposure elements)

• Behavior: Normal entry into the page, swipe up and down on the page to make the element appear twice, then leave the page
• Expected result: The number of exposure reports for the corresponding element = the number required in the埋点 document (whether deduplication within the page, report only one exposure)
• Common problems:

Scenario 5: Normal entry into the page (test the return reporting logic of exposure elements)

• Behavior: Normal entry into the page, swipe up and down on the page to make the element appear, then enter a sub-page or other tab page, return from the sub-page, and then leave the page
• Expected result: Report exposure of the corresponding element after returning from a sub-page or other tab page
• Common problems:

▪ Require to re-report exposure, but no re-reporting after the actual return

Scenario 6: Pull-down refresh of exposure data (test the pull-down refresh reporting logic of exposure elements)

• Behavior: Normal entry into the page, the element appears 100%, then pull down to trigger page refresh
• Expected result: Report again after pulling down to refresh
• Common problems:

▪ Refresh and re-report exposure after refresh, but actually not reported

6.3 Burial Point Testing Tool -- Track Platform

6.3.1 Platform Introduction

Track is a one-stop埋点 quality platform for APP, M, and mini-programs. It supports traceless collection of埋点 through proxy and scan methods, and automatically validates埋点 data through a unified rule center, which is convenient for testing, development, product, and business to quickly and efficiently view test埋点. At the same time, it can automate埋点 testing in埋点 self-testing, smoke testing, regression, and other links through traversal technology, save labor, and improve the efficiency of埋点 quality.

6.3.2 Platform Usage

1) Generate the埋点 scheme

This is the link to the埋点 scheme that has been maintained by the meridian.

2) After generating, select this埋点 scheme.

3) After selecting, choose the reporting method, and select scan reporting.

Fill in the corresponding site, generate a QR code, scan with the camera, and open the app to report.

4) Trigger the required test埋点 events, which will appear in the real-time reporting below. Select the corresponding event, and the field information reported on the right will appear.

5) Compare fields, label test results, and then generate a test report.

Author: Zhang Yuhun, JD Retail

Source: JD Cloud Developer Community. Please indicate the source of reproduction.