# Event tracking Scheme and Data Acceptance
TA records the user's key behaviors in the product through events, such as registration, login, payment, and event attributes describe the relevant information when the event occurs, such as the registered user's 'source channel', 'operate system' and so on. 'User attributes' describe each user and their latest status, such as the user's gender, grade, cumulative recharge amount.
Before using TA system for analysis, data demander identifies events, event attributes and user attributes to be collected to form buried point scheme in combination with analysis requirements. Data developer carries out embedment implementation according to the determined embedment scheme and reports data timely, accurately and completely, which is the cornerstone of data analysis.
In the process of practice, common data developers lack tool support, cannot locate data problems in time, and have problems such as missing event tracking data, inconsistent attribute reporting type and planning type, resulting in the reported data cannot be analyzed. The data demander also needs to know the quality of embedded data to ensure the availability of analysis results before analyzing the data.
The buried point scheme and data acceptance function are designed to solve the common problems in the above buried point process. The quality of buried point data is guaranteed by uploading buried point scheme, setting data processing rules and performing data acceptance function. Functions of each module are described as follows:
- Management Buried Point Scheme: Upload buried point scheme to TA platform for unified management and record buried point changes as the basis for buried point implementation.
- Set up data processing rules: regard buried point scheme as data acquisition standard, and set ETL data processing rules to ensure the accuracy of stored data.
- Data acceptance: Obtain the difference between actual data and burying scheme, optimize burying code continuously and steadily improve data quality.
# I. Manage Buried Point Scheme
This part includes the operation instructions for adding burying scheme, checking burying scheme and modifying burying scheme.
# 1.1 Add Buried Point Scheme
Default project manager and supervisors can add burying scheme, which includes 3 parts:
(1) Buried point events: record the events to be collected and their attributes
(2) Attributes of public events: Attributes affecting each event can be uploaded as attributes of public events. Attributes of public events need to be set manually when burying points. See the user manual of each access setting.
(3) User Attributes: Record the user attributes collected
TIP
The data processing rules and data acceptance function do not take effect on the preset attributes. If there is no multi-terminal access requiring attribute alignment, you can choose not to fill in the preset attribute information in the event tracking scheme
- You can choose between [batch upload] or [add one by one] burying scheme. When uploading in batches, organize your burying scheme according to TA Burying Scheme template format, and you can choose to import it into the burying scheme page.
- When a small number of buried points need to be added in product iterations, the option of [adding] buried points one by one] can be selected to add buried event, event attribute or user attribute information based on the current scheme.
If you already have data reported in your project, you want to carry out the maintenance of the Burying Scheme Based on the existing burying point, you can choose 'one key synchronized burying point reported'. Note:
- Synchronization of this operation does not include preset attributes
- Since TA cannot identify the 'public event attributes', all event attributes will be synchronized to the 'buried event', which may be different from your buried plan and can be adjusted as needed.
# 1.2 View Buried Point Scheme
TIP
You can tell whether an event or property has data uploaded by the status ID in front of it. 'Green' means data reported; 'Gray' means unreported.
(1) Click on the name of the buried event to view the details of the event.
(2) The list can be filtered and viewed by searching for information such as Event Name, Display Name, Event Description, Creator, etc.
(3) Click on View by Attribute to select a non-public event attribute and view the list of events associated with that attribute.
When adding buried events, you can add tags for events as needed and view them by event tags. Classification tags can be created according to classification conditions such as embedded platform, product modules to which events belong.
# 1.3 Edit Buried Point Scheme
# 1.3.1 Modify Buried Point Scheme
After adding buried point scheme, it can be edited as required. Click the Edit button after the event, common event attributes, user attributes, or click the edit above the detail card to enter the edit status:
(1) Edit rules for events
| Event | Edit status |
|---|---|
| Event name | When the event is not reported, it can be edited; the event has been reported and cannot be edited |
| Display name | Editable |
| Event tags | Editable |
| Event description | Editable |
(2) Edit rules for event attributes
| Event properties | Edit status |
|---|---|
| Attribute name | Not editable |
| Display name | Editable |
| Attribute type | Editable |
| Attribute description | Editable |
WARNING
The same event attribute may be associated with more than one event. If you edit the event attribute display name, attribute type or attribute description on an event detail page, the attribute information under other events will be modified at the same time.
(3) User feature editing rules
| User features | Edit status |
|---|---|
| Attribute name | Not editable |
| Display name | Editable |
| Attribute type | Editable |
| Update method | Editable |
| Attribute tab | Editable |
| Attribute description | Editable |
# 1.3.2 Delete Buried Point Scheme
(1) You can choose to delete event, event attribute or user attribute under the buried scheme. Deleting events or attributes in a buried scheme only means deleting them from the buried scheme and does not actually delete the reported data.
(2) Click on 'More' in the operation bar to select 'Empty Buried Point Scheme'. This action clears the contents of buried point events, public event attributes, and user attributes at the same time and can optionally be uploaded again when cleared.
# II. Set Rules for Data Processing
TA defaults to the attribute type based on the data type when the attribute is first stored. In the actual data reporting process, common problems such as inconsistency between attribute reporting type and expected type lead to the data reported can not support analysis and higher repair costs in the later stage. The function module takes the uploaded buried point scheme as the data acquisition standard, compares the inbound data with the buried point information, and sets the data processing rules when there are differences in reporting. This effectively avoids inconsistent data and ensures consistency between reported data and planned data at the beginning of data reporting.
After uploading the buried point scheme, TA over-manager or administrator can set data processing rules in project management. Choose whether to open the data validation based on embedded point scheme based on the default ETL data processing rules. Settings include:
- Events not in the Buried Point Scheme → whether it can be stored
- Attributes of events not present in the buried scheme ( i.e. attributes of events not present in all events in the buried scheme) → Whether it can be stored
- Not in the event tracking scheme user feature → whether it can be stored
- Event attributes or user attributes that are inconsistent with the 'attribute type' in the buried scheme → whether it can be stored
WARNING
Data processing rules only take effect for newly reported events or attributes that have not yet generated metadata.
For example, a 'recharge' event is not recorded in the event tracking scenario, but the event has been reported. This rule does not take effect for 'recharge' events when you select 'Events not in the buried scheme are not stored'.
The default project configuration is 'Free Report' mode, i.e. the buried scheme has no effect on ETL data processing rules and can be switched to 'Strong Check' mode or 'Custom' mode. In the strong check mode, the data processing rules are described as follows:
**Event rules ** : events not in the buried point scheme→ Not stored: that is, you need to maintain the complete buried information in the buried plan before you can report the data. This rule prevents the repository of dirty data that is not in the plan.
**Attribute rules **: including event attributes/user features that are not in the event tracking scheme → discard attributes, inconsistent with attribute types in the buried scheme → discard attributes. This rule prevents invalid attributes from being put into storage and ensures attributes are warehoused with expected attributes by comparing actual attributes with buried scheme attributes.
Note: Attribute rules only include custom attributes, not TA preset attributes.
Once set, members can view the data processing rules settings for the current project on the Buried Point Scheme page:
# III. Data Acceptance
After uploading the buried point scheme and data reporting, you can carry out data acceptance to obtain the reported data quality. The acceptance result consists of the following two parts:
- All differences between reported data and buried plan: whether all buried events are reported and whether unplanned events (events not in buried plan); Whether there are missing attributes, unplanned attributes (not in the buried point scheme), inconsistent reporting attributes and expected types.
- Null rate for reporting attributes: Support setting null rate threshold which will display exceptions in acceptance results when null rate of attributes is greater than threshold.
WARNING
The data acceptance scope includes events and custom attributes, and does not accept preset attributes.
# 3.1 Data Acceptance
Click 'Data Acceptance' in the upper right corner of the page to configure acceptance rules. You can choose to accept event data or user data.
(1) Acceptance event data
Click to select 'Acceptance Event Data' to set the data range for acceptance. Include event time, event range and filter condition:
- Event time: The time range for the acceptance of the event, which defaults to yesterday and can be customized. Note that this time refers to the #time field in the reported data and does not shift with the project time zone.
- Event range: i.e. events requiring acceptance, default Full Event, can customize the event scope. For data acceptance, select a new version of added buried event.
- Filter condition: Event data can be filtered. If you collect and report data through a client side SDK, you can specify the data under a certain source for acceptance.
Click 'Next' to set the attribute null rate acceptance rules. Include null rate thresholds and statistical rules:
- Null rate threshold: Set the null rate threshold. When the reported attribute null rate exceeds the threshold, an exception will be displayed in the acceptance result.
- Statistics rule: Choose whether to include empty strings in attribute null rate.
(2) Acceptance of user data
Click to select 'Acceptance User Data' to set the acceptance rules for the acceptance of user data range and attribute null rate. Same as acceptance event data.
# 3.2 Check Acceptance Results
Click on the operation after the acceptance record to view the acceptance result report. The acceptance result of event data includes the following scenarios:
| Acceptance result | Result description |
|---|---|
| Success | The reported data is consistent with the event tracking scheme, and the attribute null rate is lower than the set threshold |
| Not reported | Within the selected acceptance range, there is no data report for the event |
| Abnormal | The following conditions are recorded as an event exception: 1. There are events that are not in the event tracking scheme 2. Exists in the event tracking scheme, but actually has the attribute of reporting 3. There are missing attributes, that is, attributes that are not actually reported in the event tracking scheme 4. There is a report attribute type that is inconsistent with the attribute type in the event tracking scheme 5. The attribute null rate exceeds the set threshold |
The acceptance results of user data include:
| Acceptance result | Results Description |
|---|---|
| Success | The reported attribute data is consistent with the event tracking scheme, and the attribute null rate is lower than the set threshold |
| Abnormal | A user feature exception is recorded when: 1. User features not in event tracking scenarios 2. Attribute missing: that is, in the event tracking scheme, but the actual user feature is not reported 3. The report attribute type is inconsistent with the attribute type in the event tracking scheme 4. The attribute null rate exceeds the set threshold |