Taxonomy is a set of rules for consistently defining events and properties. It ensures that teams record and interpret data based on the same standards.
For example, if you name the home screen view event view_home, similar actions should follow the same naming rule.
Designing your Taxonomy first makes later analysis, experimentation, and targeting much easier.
You can quickly find the events you need.
It reduces the problem of different teams using different names.
You can compare Web, iOS, and Android data on the same basis.
You can operate analytics metrics and reports reliably.
Event and property names should follow the same rules.
For example, it is good practice to establish a single rule and stick to it, such as the following:
Use lowercase English letters
Use _ to separate words
Use the verb_noun format for event names
Example:
Even if the UI differs between Web and App, the meaning of the user action can be the same.
In this case, the event names should also be identical.
Web button click
App tap entry
If both actions represent "view product detail," it is better to use the same event name.
Example:
Be careful when including information that can identify an individual in events or properties.
Store information such as email, phone number, and name only when absolutely necessary. Before storing, always verify your security and operational policies.
Events must describe what the user did.
Representative examples are as follows:
Execute search
View product detail
Add to cart
Complete payment
Backend activities can also be defined as events if they are linked to user behavior.
Example:
If they are too abstract, the meaning becomes ambiguous.
If they are too specific, reuse and analysis become difficult.
A good rule of thumb is: "Put the action in the event name, and the details in the properties."
Example:
Bad: page_view
Bad: view_home_ipad
Good: view_home
Details such as ipad are better stored as event properties.
An Event Property is the context at the moment a specific action occurs.
For example, the view_product_detail event can include the following information:
product_id
product_name
category_id
rating
This information can differ depending on the situation, even for the same event.
A User Property is status information about the user who triggered the event.
For example, the following:
user_id
membership_grade
is_first_visit
acquisition_channel
Some values remain fixed, while others may change over time.
user_id is usually maintained.
membership_grade may change.
Data with the same meaning should always be stored under the same name.
For example, if product name is stored using mixed names as below, analysis becomes difficult:
product_name
product_nm
Choose one of the two and use it consistently across the entire service.
Before creating a new event, check the following items:
Can the behavior be understood just by looking at this name?
Can the same name be used on other platforms?
Is it neither too abstract nor too specific?
Have the details been separated into properties?
Does a property name with the same meaning already exist?
Is personally identifiable information being stored unnecessarily?
Last updated
view_home
click_signup
complete_purchase
product_id
product_nameview_product_detailsearch_product
add_to_cart
complete_payment