# Making Data Tracking Plan
# Determining the user identification system
Before you start data ingestion, you should first determine the user identification system utilized by the project. You can learn more about relevant scenarios and cases from User Identification Rules.
#account_id is the smallest unit to identify users in the TE system. Generally, you can set a user's ID as the #account_id. If an account is associated with multiple mutually independent roles, you need to set a role ID as #account_id.
For example, you can create roles at different servers using a game account, with each role having its level, class and gear. In this case, the role 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.
# 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.