Data Definition and Structure

Data Definition

In the Operation Growth platform, we use User and Event to describe users and the various behaviors users perform in a product. This is also the core basis for the design of all APIs and features in the Operation Growth platform.

You can simply understand this as two large tables: one records user attributes, and the other records user behaviors. The two tables are associated through a unique ID. In the User table, each user is a record. In the Event table, each user behavior is a record. By combining the two tables, analysis can be performed across many dimensions.
In Jiguang Operation Growth, APIs are provided for users to upload and modify these two types of data. When using product features, these two types of data can participate in specific analysis and queries either separately or together. The two concepts are described in detail below.

Data Structure

Event

Five Elements of an Event

Simply put, an Event describes that a user completed a specific action at a certain time, in a certain place, and in a certain way. Therefore, a complete event contains the following key elements:

Event Classification and Field Design Principles

Event Classification Principles

• To save costs, record only events that will be used. Events are recorded to understand in detail how users use the product. Events that will not be used for the time being do not need to be recorded.
• For events with common characteristics, merging is recommended. For example, if a product is concerned about visits to a series of product category pages, you can abstract this into one visit event and record different product categories as event attributes.

Event Attribute Design Principles

• First sort out the metrics and dimensions required for analysis, then work backward from the metrics and dimensions to determine which event attributes need to be recorded for each event.
• The Operation Growth platform is a marketing-oriented system, not a log storage and backup system. Therefore, fields that are not used, such as the full contents of a Cookie or backend request return codes, do not need to be recorded and collected as event attributes.
• If preset event attributes can meet business requirements, reuse preset event attributes as much as possible. For descriptions of all preset event attributes, see the relevant descriptions in Events and Attributes.
• Once the design of a field for an event is determined, do not modify its type or value meaning. For example, if the event "Purchase" was initially designed with a numeric event attribute "purchase amount (yuan)", and later the unit needs to be changed to cents, it is recommended to add a new field "purchase amount (cents)" instead of changing the original attribute. Otherwise, data confusion may occur.

User

Recording and Collecting User Attributes

Each User entity corresponds to a real user, is identified by CUID, describes the user's long-term attributes, and can be associated with the behaviors the user performs, namely Events.

Operation Growth provides a series of SDKs and APIs for collecting user attributes.

Which fields should be collected as user attributes depends entirely on the product form and analysis requirements. Simply put, among the user attributes that can be obtained, those that are helpful for analysis and usage should be collected as user attributes.

Choosing Between User Attributes and Event Attributes

User attributes record attributes of user characteristics, such as place of birth, gender, registration location, and first ad source type. Event attributes in an Event record the characteristics when the event occurs, and their values are contextual, such as province, city, device model, and login status.

Take "address" as an example: an event attribute records the address used for the current order, while a user attribute is often the "frequently used address".