In user behavior analytics, a single user action or a category of actions can be abstracted as an event. For example: launching an app, browsing a page, applying for a loan, clicking submit, and so on. All of these can be referred to as an event. The process of writing event logic into code through SDK development is called event tracking.
You may have heard various concept terms related to event tracking, such as: "no-code event tracking", "full event tracking", "visual selection", "visual event tracking", and many others. From a team perspective, choosing the form of event tracking that best suits your team's business needs becomes the primary consideration. The following is a brief overview and summary of various data collection methods to help you make a decision.
In the Growth Analytics (DataFinder) product, event tracking can be simply divided into three categories, which are introduced in detail below.
Full event tracking is also known as "no-code event tracking", "invisible event tracking", and "full event tracking". Full event tracking fully collects and reports standard page views and standard element clicks. In Finder, the collected full event tracking events are bav2b_click for button clicks and bav2b_page for page views. No additional development effort is required, saving time and effort. However, full event tracking comes at the cost of reporting large volumes of data and can only collect simple PV and UV metrics. It is somewhat inadequate for collecting rich business data.
The data collected by full event tracking can also be used for visual event tracking and heatmap analysis.
The main application scenario for visual selection event tracking is for business analysts who do not understand code or technology. It enables them to easily obtain the data they want to analyze with a very low barrier to entry. It is simple and easy to understand: by directly clicking the page or button to be analyzed on the real interface of the website or mobile application, the system will fully define the desired event tracking, generate a selection event, and achieve visual operation. For reference, see the documentation: Circle Event.
Heatmaps can visualize the behaviors of a large number of users, displaying user preferences for clicks and dwell time through a visual interface. You can refer to the documentation: Heat Map Analysis.
Code-based tracking refers to developers manually writing code to implement data collection logic according to personalized business requirements. The collection scope is broad; in theory, any client-side interaction can be collected. At the same time, complex business logic information can be collected. For example, for the event of viewing a product details page, information such as product category, product price, and product name can be collected, which cannot be achieved by other tracking methods.
However, this also means that a certain amount of workforce is required, and it is necessary to verify and calibrate the accuracy of data transmission and the consistency of business logic.
Preset full tracking refers to the Finder SDK, which collects preset events by default, such as app launch and app exit on the app side. Based on these basic events, quick integration can be achieved, enabling simple analysis of daily active users, monthly active users, active days, new users, and other basic metrics. For related preset operation instructions, see Preset Property Summary Table.
Summary:
Data collection methods | Full tracking (visual tagging, heat maps) | Code-based tracking | Preset full tracking |
|---|---|---|---|
Advantages |
|
|
|
Disadvantages |
|
| Only basic metrics can be implemented and must be combined with code instrumentation. |
Other notes |
| Mandatory. | Mandatory. |