Background#
The main traffic source for the product pages managed by the team comes from various App platforms within the group. One of the key metrics we focus on is the arrival rate.
Arrival rate calculation: Page impressions from resource clicks / Resource clicks
- Resource clicks are tracked on the Native side, and BI determines the corresponding business based on the material name.
- Page impressions are tracked on the Web H5 side and are generally set within the
mounted
lifecycle.
Recently, we have received feedback about a decrease in the arrival rate. After investing a significant amount of manpower and conducting some case analyses, we have identified several main reasons for this decrease:
- User intent / fatigue issues
- BI calculation issues, errors in numerator or denominator
- Slow page loading
In order to have readily available statistical data to visually analyze user drop-off points and effectively conduct problem analysis and localization in similar situations in the future, we need to analyze the existing user flow. After conducting some research, I would like to record the findings.
Research#
The current way to view the user flow is through the personal diagnostic link on the internal monitoring and statistics platform:
- Firstly, select different platforms, which correspond to different data tables for tracking (Native and H5 are distinguished).
- Secondly, input the user ID + time, and select the corresponding page and filter events to simplify the query results.
- Finally, based on the reporting time, all relevant operation tracking points for that user within the selected time period are displayed.
It can be seen that the core logic of the personal diagnostic link is to retrieve a complete set of operation tracking points based on a single user identifier in chronological order.
However, the statistical display of the behavior path requires calculating funnel data based on fixed operation tracking points in a logical and agreed-upon sequence, meaning that there must be clear order and reasonable statistical dimensions for the key tracking points. Therefore, the personal diagnostic link tool cannot meet the statistical needs.
From the user clicking on a resource to the page being displayed, the corresponding technical behavior path is: opening a webview in the app and loading the H5 page.
Based on this behavior path and consultation with the SDK team responsible for tracking, the following conclusions have been reached:
- The Native SDK and H5 SDK links have no clear order of loading (similar to component lifecycle and page lifecycle), so monitoring can only be based on data from one side.
- Native SDK
- Standard tracking points include opening an H5 page, starting to load an H5 page, and H5 page loading complete, but currently not supported (depends on future releases).
- Existing tracking points include entering a certain page and exiting a certain page, with a broad triggering range (including opening/closing the app, switching pages within the app, switching between foreground and background, etc.), without reasonable statistical dimensions.
- Key tracking points such as clicking the top left corner to go back: no direct tracking point on the app side; SDK's automatically collected and reported unified tracking points: need to filter based on control type name + controller name + trigger method name, high query cost and instability, and no reasonable statistical dimensions.
- Summary: The current Native link has no feasible monitoring points.
- H5 SDK
- Standard tracking points include H5 page initialization and H5 page exposure (after onLoad), with specific business-related information such as the complete page URL and page routing. Fuzzy matching can be done based on inrouter and channel number, etc.
- With the help of existing funnel analysis functions, arrival rate can be calculated easily.
- Summary: The current H5 link has monitoring points, but the effectiveness is limited.
Conclusion#
Short-term solution: Monitor the H5 initialization - exposure funnel conversion rate technically for auxiliary observation.
Long-term solution: After the Native release, monitor the Native link and promote the addition of tracking points for meaningful business indicators such as the bounce rate when clicking back on the app.