From data to large model application, on November 25th, Hangzhou Yuanchuang Conference was held to share development tips.

1. What is the buried point?

Tracking, also known as event tracking, refers to related technologies and implementation processes for capturing, processing, and sending user behaviors or events. In plain language: it is to “monitor” users’ behavior in apps and websites through technical means.

2. The role of buried points

If we want to collect user behavior data, we can do it by burying points.

For example, you want to know which buttons a user clicked in the APP, which pages he viewed, what he did, etc.
Another example is wanting to know how many people have used certain functions, how often they have been used, etc.

3. The use of buried points--overall introduction to data flow

3.1. Real-time data

The real-time data source starts from the click stream. The client SDK reports buried data. The collection service writes the reported buried data into the JDQ write cluster, and then summarizes the data to the JDQ read cluster through the fregeta task.
The downstream flink task will consume the original topic from the reading cluster, and then spit out the processed topic for downstream business consumption.
Downstream businesses include: GoldenEye, Shangzhi, Search Promotion, etc.

3.2. Offline data

The source of offline data starts from the click stream. The client SDK reports buried points data. The collection service writes the reported buried points to the cfs network disk, and then drops the data into the data warehouse through the offline extraction service.
The data warehouse will undergo multi-layer processing to process the data into the caliber required by the business and provide it for use by data applications.
Downstream businesses include: GoldenEye, Shangzhi, Search Promotion, etc.

4. Embed related teams

Responsibilities of each team:

5. Buried process

5.1. Demand for business products

Business products first submit their needs to buried products
Points to note: Any new or changed requirements related to buried points need to be submitted to the Meridian platform for buried point products.
Online problem: 20230527 Jingdong APP applet purchase parsing failed. This is because the demand is urgent and Meridian is not used. The product maintains the document itself, causing the downstream to be unable to parse after the fields are modified.

5.2. Set up a buried plan

•After receiving the demand for the buried product, a review meeting will be started to review whether the demand is reasonable, whether it is omitted, whether the parameters are complete, whether it is necessary to notify third-party business, and determine the schedule.

The buried product will formulate a buried plan at Meridian based on the review results.
After the buried product produces a buried plan, the business, development, testing, and data sides will be invited to participate in the plan review to confirm whether the plan is complete and whether the parameters are reasonable.

5.3. Focus on development

After front-end R&D gets the embedding plan, it develops according to the embedding plan.
Points to note: Develop version branches that need to be launched at the agreed-upon point. Be careful not to follow the version launch in advance.
Online problem: On October 12, 2023, the order indicators related to the hourly delivery of the search results page dropped. This is because the hidden points were not tested and were released in advance, resulting in the inability of downstream analysis.

5.4. Buried point test

After the development is completed, the test needs to be verified by the reporting rules. For details, see: 6.2.2, Reporting Rules Use Cases
The test performs field verification on the buried points on the track platform. For details, see: 6.2.1, Field Verification Use Cases
After verification is completed, the test report is output. For details, see: 6.3.3, track platform use

5.5. Acceptance of buried points

The buried product verifies the test records in the test report produced by the test.
Simultaneously conduct table verification of data

5.6. Buried points online

After the acceptance is completed, the corresponding version status of Meridian is changed to online.
Front-end follow-up version online
Points to note: Every time during development, you need to use the latest online master branch to pull a new development branch. When merging the code before going online, make sure that there are no other online branches during the process. If so, you need to focus on it to avoid overwriting the last time. Online content.
Online problem: On October 18, 2023, the data on the Jingxiao LBS-related business dashboard was abnormal. This was because the branch merged online covered the normal version that was launched last time, resulting in reporting errors.

6. The main quality assurance of buried points - buried point testing

6.1. Frequently asked questions about buried points

There are several common questions:

The buried demand does not follow the meridian, and the reported content is wrong.
When the business was modifying logic, it forgot to modify the buried points and report them.
The upstream and downstream synchronization was not done well when the buried point went online.
The newly added field data structure is not compatible downstream

6.2. Buried test cases--quality assurance of reported content

6.2.1. Field validation use cases

Verify whether the reported hidden points are consistent with the field names and field types set in the plan
If the burying plan has parameter lengths marked, or if the parameters are enumerations, verification is required.
If it is nested json, you need to be careful not to destroy the original json structure.

6.2.2. Reporting rule use cases

1) pv scene

Scenario 1: Enter the page normally

Behavior: Enter the pv page normally and stay there
Expected results: Normally, only 1 PV buried point is reported, and page_id, page_param and document are consistent.
Special scenario:

▪Tab nested page scenario: only 1 main tab PV burying point is reported when entering, and another tab PV burying point is reported when switching tabs. For example, 2 PV burying points appear when entering (1 outer large frame PV burying point) If one main tab pv is buried), an error will be reported; repeatedly switching tabs will not report the same page pv again.

prone to problems

▪No PV hidden points are reported when entering the page normally. The hidden points will only be reported when switching the relevant tabs.

▪No PV hidden points are reported when entering the page, and PV hidden points are reported only when leaving the page.

Scenario 2: Return to this page scenario

Behavior: Enter page A normally and stay, then click on an element in this scenario to enter the subordinate page B, and then return to page A.
Expected results: 3 PV hidden points will be reported natively, namely A, B, and A, and the page_id, page_param and document of page A are consistent. The h5 fallback will not report PV hidden points.
Problems are prone to occur: the rollback page does not report the PV hidden points of page A

Scenario 3: Quickly leave the page scenario (mainly to solve the problem that there are parameters issued by the server in the pageParam parameter. If the interface does not respond, the PV buried points also need to be reported normally)

Behavior: Enter the page normally and leave the page quickly
Expected results: 1 PV buried point is reported normally, and page_id, page_param and document are consistent
Problems prone to occur:

Scene 4: Pull down to refresh scene

Behavior: Enter the page normally, then pull down to refresh
Expected results: Pull-down refresh will no longer report PV hidden points
Problems prone to occur:

Scene 5: The APP switches to the background or lock screen scene

Behavior: Enter the page normally, then switch the APP to the background or lock the screen, open or unlock it again
Expected results: PV hidden points will no longer be reported, according to regulations
Problems prone to occur:

2) Click on the scene

Scenario 1: Enter the page without clicking

Behavior: Do not click on the corresponding element
Expected results: According to the hidden point document, if the default reporting is not required, click buried points will not be reported here (some buried points have the logic of default click buried points, this scenario is in line with expectations)
Problems prone to occur:

Scenario 2: Normal click

Behavior: Click the corresponding element normally
Expected results: 1 click buried point is reported normally, and event_id, page_id, page_param, event_param, json_param, et_model are consistent with the document
Problems prone to occur:

Scenario 3: No jump when clicked (no function trigger, no interactive change)

Behavior: Normal click on the corresponding element without interaction
Expected result: No click events will be reported
Problems prone to occur:

Scenario 4: Sliding buried point

Behavior: Stop after swiping to browse
Expected results: Report click buried events
Problems prone to occur:

3) Exposure scene

Scenario 1: Enter the page normally, and the element is not leaked at this time (test whether the exposed element is not leaked and report it)

Behavior: Enter the page normally, the element is not leaked at this time, and then leave the page
Expected result: The corresponding exposure points will not be reported
Problem-prone: report the hidden points before they are leaked

Scenario 2: Enter the page normally. At this time, the element has leaked out of the display (you need to test the scenarios where the element has just leaked out, leaked out 50%, and leaked 100% to ensure that it is consistent with the space limit and time of element exposure in the buried document. Test Reporting timing and space limitations of exposure elements)

Behavior: Enter the page normally. At this time, the element has leaked out of the specified proportion, and then leave the page.
Expected results: The reporting timing of this element = the reporting timing of the requirements in the hidden document (reporting when it leaks or when leaving the page), and the reporting parameters remain consistent
Problems prone to occur:

▪The hidden document requires you to leave the page and report for exposure. If it actually leaks, report it, and vice versa.

▪The hidden point document requires 100% leakage to be considered exposed. If one px pixel is actually leaked, the hidden point will be reported.

▪The exposure logic is inconsistent at both ends, and the amount of exposure data on Android and iOS is very different.

Scenario 3: Test the reporting timing of exposure elements

Behavior: Enter the page normally. At this time, the element has leaked 100%, triggering different exit page scenarios: entering the lower-level page, returning to the previous page, refreshing the page, switching to other tab pages, and entering the background. 5 scenarios
Expected results: The number of exposure reports corresponding to this element = the number of requests embedded in the document
Problems are prone to occur: the buried document requires leaving the page to report the exposure, but the actual leakage is reported, or a certain scene is missed when leaving the page, resulting in the exposure data not being reported in time

Scenario 4: Enter the page normally (test the in-page deduplication logic of exposed elements)

Behavior: Enter the page normally, slide the page up and down to make the element appear twice, and then leave the page.
Expected results: The number of exposure reports corresponding to this element = the number of times the requirements are buried in the document (whether to remove duplicates within the page, only report one exposure)
Problems prone to occur:

Scenario 5: Enter the page normally (test the return and reporting logic of exposure elements)

Behavior: Enter the page normally, slide the page up and down to make the element appear, then enter the lower-level page or other tab page, then return from the lower-level page, and then leave the page
Expected results: Report the exposure of the corresponding element after returning from the subordinate page or other tab page
Problems prone to occur:

▪Required to return and re-report exposure, but did not re-report after actual return

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

Behavior: Enter the page normally, the element appears 100%, and then pull down to trigger a page refresh
Expected results: Pull down to refresh and report again.
Problems prone to occur:

▪Required to re-report the exposure after refreshing, but it was not actually reported.

6.3. Buried 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 the traceless collection of buried points through agents and code scanning, and automatically verifies the buried point data through the unified rule center, making it convenient for testing, development, products, and business to quickly and efficiently view test buried points. At the same time, it can automatically test the buried points through the traversal technology in the self-test, smoke, regression and other aspects of the buried points, saving manpower and improving the efficiency of the buried points quality.

6.3.2. Platform use

1) Generate a buried point plan

What is needed here is the link to the well-maintained burying plan on the meridian.

2) Select this buried point plan after generation

3) After selecting the reporting method, select scan the QR code to report.

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

4) Trigger buried events that need to be tested will appear in the real-time reporting below. Select the corresponding event, and the reported field information will appear on the right.

5) Compare the fields, mark the test results, and generate a test report after marking.

Author: JD Retail Zhang Yuxun

Source: JD Cloud Developer Community Please indicate the source when reprinting

A brief discussion on buried points and quality assurance | JD Cloud technical team