Create a tracking plan
Determine the user identification system
Before you connect data, you need to determine the user identification system that the project uses. You can find more scenario examples in User identification rules. #account_id is the smallest unit that identifies a user in the AE system. Usually, you can set the user's account ID as #account_id. If an account has multiple independent characters, you need to set the character ID as #account_id. For example, a game account can create characters on different servers, and each character has its own level, class, equipment, and so on. In this case, the character ID is the smallest unit. #distinct_id is the ID that records a user's behavior as a guest, such as opening the app or viewing announcements. Before the user logs in to an account or before character information is obtained, behavior data is attributed to #distinct_id. #user_id (AE user ID) is a unique identifier that the AE system generates based on #account_id and #distinct_id. With #user_id, you can link a user's behavior before and after login. When a record contains both #account_id and #distinct_id, and their corresponding #user_id values are different, the record is attributed to the #user_id that corresponds to #account_id.
Determine events and event properties
An event represents one or a series of meaningful user actions and is the main object of analysis. You can start from the core metrics of the project, sort out key features such as registration, login, payment, and core gameplay, and turn these features into events. After you determine the events, you also need to determine the exclusive properties of each event to provide more detailed information for future analysis. For example, when a user triggers a payment event, event properties can record the payment amount, the ID of the purchased bundle, and so on. In addition to exclusive properties, you can set some important properties as Super Properties, which reflect the user's state at the time the action occurs. For example, if you set VIP level as a super property, it is carried with every event that is reported, so you can analyze the impact of VIP level on user behavior more precisely.
Determine user properties
Unlike super properties, user properties record the user's current state. You can set the following three kinds of values as user properties:
- Fixed values: properties that don't change, such as registration time, Source Channel, and username
- Latest values: information about the user's most recent behavior, such as last login time and last payment time
- Cumulative values: similar to latest values, they represent the user's historical cumulative data, such as cumulative payment amount and cumulative login count.
For example, suppose a user has triggered the payment event twice, where the single payment amount is an exclusive property and the cumulative payment amount is a super property that records the total amount the user had paid when the payment event occurred:
| Event time | Cumulative payment amount | Single payment amount |
|---|---|---|
| Jan 1 | 0 | 50 |
| Jan 2 | 50 | 100 |
If you view event details, the values of event properties don't change over time. However, if the cumulative payment amount is a user property, its value is updated from 0 to 50 after the user's first payment and to 150 after the second payment. To learn more about events, event properties, and user properties, see Data management. We strongly recommend that you organize all the events and properties you need to track in a document, which helps you communicate with engineers during tracking implementation. After you create the tracking plan, the next step is to report and validate data.