Taxonomy Guide

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.

Why is it important?

• 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.

Criteria for a Good Taxonomy

1. Naming rules must be consistent

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:

view_home
click_signup
complete_purchase
product_id
product_name

2. Use the same name for the same behavior even on different platforms

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:

view_product_detail

3. Minimize personally identifiable information

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.

4. Events should focus on user behavior

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:

search_product
add_to_cart
complete_payment

5. Event names should not be too abstract or too specific

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.

Difference Between Event Property and User Property

Event Property

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.

User Property

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.

Property names should also be consistent

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.

Pre-writing Checklist

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?

Further Reading

• How should event naming be defined?

• How are the designed events used?

• I want to understand the full picture from event definition to utilization