# Making Data Tracking Plan
# Determining the user identification system
Before beginning data ingestion, it's important to first identify the user identification system being used by the project. For more information on relevant scenarios and cases, you can refer to the User Identification Rules.
In the TE system, the #account_id is the smallest unit to identify users. Typically, a user's ID can be set as the #account_id. However, if an account is associated with multiple independent roles, it's necessary to set a role ID as the #account_id.
For example, a game account can create characters under different game servers, and each character has its own level, profession, equipment, etc. At this time, the character ID is the smallest unit.
#distinct_id is the ID recording a user's behaviors under the visitor state, such as opening an APP or viewing announcements. Before the user logs into the account or obtains role information, behavioral data is attributed to #distinct_id.
#user_id (TE user ID) is the unique identifier generated by the TE system based on #account_id and #distinct_id. #user_id can be used to connect user behaviors before and after login. When #account_id and #distinct_id simultaneously exist in a data entry and correspond to different #user_id, the data is attributed to the #user_id corresponding to #account_id.
The "distinct_id" is the ID that records a user's actions while in the visitor state. This includes activities like opening an app or browsing announcements. Behavioural data is assigned to "distinct_id" before the user logs into their account or obtains information about their roles.
The "user_id" (TE user ID) is a unique identifier created by the TE system based on the "account_id" and "distinct_id". The "user_id" can be used to link user actions before and after logging in. If a data entry contains both "account_id" and "distinct_id" and they correspond to different "user_id"s, the data is assigned to the "user_id" that matches the "account_id".
# Determining event and event property
An event represents a user's certain or series of meaningful behaviors, which is also the main target of analysis. You can start with the core metrics of a project and organize key functions like registration, login, payment and core gameplay modes into "events".
After determining "events", you also need to determine the unique properties of each event and thus provide more detailed information for subsequent analyses. For example, when a user triggers a payment event, you can record the payment amount and ID of the purchased package by event properties.
Apart from unique properties, you can also set some important properties as "super properties", which reflect the user's state when behaviors happen. For example, if you set the VIP level as a super property, the property will be attached to all events that are reported, so that the influence of the VIP level on user behaviors can be more precisely analyzed.
# Determining user property
Unlike super property, user property records a user's current state. You can set the following three values as user properties:
- Fixed value: Properties that do not change, such as registration time, source channel and user name.
- Latest value: Information about the last time a user does a certain behavior.
- Cumulative value: Similar to the latest value, it represents a user's historical cumulative data, such as cumulative payment amount and cumulative times of login.
For example, suppose a user has triggered two payment events with one payment amount being the unique property and cumulative payment amount being the super property. Then, the total amounts paid by the user should be used when recording payment events:
| Event-time | Cumulative payment amount | Single payment amount |
|---|---|---|
| January 1 | 0 | 50 |
| January 2 | 50 | 100 |
If you view event details, the values of event properties will not change over time. However, if the cumulative payment amount is of user property, then the property value will be updated from 0 to 50 after the first payment, and then to 150 after the second payment.
About event, event and user property, you can understand more from Data Management. We strongly recommend that you organize all events and properties needing to be tracked in the form of document, as it can help you communicate with technical personnel when performing data tracking.
After making data tracking plan, the next step is to complete Data Reporting and Verification.