In this section, you need to achieve the following objectives:
- Understanding the design principles of the data acquisition scheme
- Understand the writing standards for data acquisition plans
- Develop a data collection plan based on business requirements.
What is data acquisition scheme design?
Collecting user behavior data first requires clarifying the target behaviors to be collected based on business analysis needs, and further figuring out where and what kind of tracking points should be placed. The output of this step is generally called the "Data Tracking Requirements Document (DRD)". In most internet companies, the standard product iteration process is that while the business-side product manager outputs the "Product Requirements Document (PRD)," the data product manager or analyst, or other roles, need to simultaneously output the DRD, and the requirements from both sides are simultaneously incorporated into development and testing acceptance.
Since Sensors Analytics' underlying data model is an event model of Event + User, event tracking is referred to as "event" in Sensors Analytics, and the event tracking requirement document is collectively referred to as "data collection scheme design". The work in this section needs to be completed with the help of the "Data Collection Scheme" template provided by Sensors Analytics. Please contact the corresponding customer success or analyst for assistance.
Data Acquisition Scheme Design Ideas
The core ideas of the data acquisition scheme design can be broadly divided into the following points:
- Break down user behavior into individual clicks or browsing actions;
- Abstract the target actions that need to be analyzed into "events" and add the event dimension;
- Based on business needs, comprehensively improve the data collection solution design;
We have recorded an explanatory video to illustrate the design principles of the data collection solution . If you still have questions after viewing it, please contact the corresponding analyst.
Data Acquisition Solution Template
To help you understand the data acquisition solution template, we have recorded another explanatory video, also titled "Data Acquisition Solution Template ." If you still have questions after viewing it, please contact your relevant analyst.
Common problems in data acquisition solution design
Events designed in conjunction with the scenario
For similar scenarios, such as submitting ticket orders and submitting flight orders, should the events be designed separately for each scenario or combined into one event? Two design approaches are provided for reference:
A. Designed for the same event, applicable scenarios: the required attributes for each event are not much different; in normal analysis scenarios, the overall analysis is often performed.
B. Designed for different events and applicable scenarios: The required attributes for each event vary greatly; the analysis scenarios are mostly analyzed separately. If this approach is adopted, it is also recommended to use the same attribute name for some common attributes to facilitate the overall analysis when using the "virtual event function" in the future.
For example, when simply tracking the clicks of three buttons A, B, and C, instead of creating three separate events for "Click button A", "Click button B", and "Click button C", create a "Click button" event and pass the names of the three buttons (A, B, and C) through the "Button Name" property.
Passive events
Passive events: Since funnel analysis and retention analysis in Sensors Analytics require the same person to trigger the event, passive events need to be triggered for users in some scenarios. For example, after a user submits authentication, it needs to be reviewed. The review is not actively triggered by the user and can be set as a passive event.
Custom indicator calculation requirements
In the custom metric calculation of event analysis, we can perform arithmetic operations on various event metrics. For the attributes that need to be calculated, their value type must be numeric.
Issues to note regarding the Users table
• Unilateral and bilateral users
One-sided and two-sided user distinctions are used when a product has multiple user identities. One-sided users are those with only one type of user, such as the fitness app Keep or the chat tool QQ; two-sided users are like O2O products, where users may be ordinary consumers or merchants. User identification and corresponding attributes need to be designed in advance, depending on the specific product.
• Slowly changing dimensions
If you encounter attributes that change, such as a user's VIP level, you can't just pass them as user attributes into the user table. You also need to record a "current event VIP level" attribute in the event table. This is because the statistics for the current membership level and the statistics for the user's membership level at the time the event occurs are two different things.