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

{% hint style="info" %}
Designing your Taxonomy first makes later analysis, experimentation, and targeting much easier.
{% endhint %}

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

{% hint style="warning" %}
Store information such as email, phone number, and name only when absolutely necessary. Before storing, always verify your security and operational policies.
{% endhint %}

### 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?](https://blog.hackle.io/post/event-taxonomy?utm_source=guide)
* [How are the designed events used?](https://blog.hackle.io/post/hackle-datawebinar2-takeaway?utm_source=guide)
* [I want to understand the full picture from event definition to utilization](https://www.youtube.com/playlist?list=PLG34Df5JQ-UbcfJ8kWXv1Lnpl6alKWFKg)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.hackle.io/en/event-management/taxonomy-guide.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.