# Taxonomy 안내

Taxonomy는 이벤트와 속성을 일관되게 정의하는 규칙입니다.\
팀이 같은 기준으로 데이터를 남기고 해석할 수 있게 해줍니다.

예를 들어 홈 화면 조회 이벤트를 `view_home`으로 정했다면, 비슷한 행동도 같은 규칙으로 이름을 정해야 합니다.

{% hint style="info" %}
Taxonomy를 먼저 설계하면 이후 분석, 실험, 타겟팅이 훨씬 쉬워집니다.
{% endhint %}

## 왜 중요한가요?

* 필요한 이벤트를 빠르게 찾을 수 있습니다.
* 팀마다 다른 이름을 쓰는 문제를 줄일 수 있습니다.
* Web, iOS, Android 데이터를 같은 기준으로 비교할 수 있습니다.
* 분석 지표와 리포트를 안정적으로 운영할 수 있습니다.

## 좋은 Taxonomy의 기준

### 1. 네이밍 규칙이 일관되어야 합니다

이벤트와 속성 이름은 같은 규칙을 따라야 합니다.

예를 들면 아래처럼 하나의 규칙을 정하고 유지하는 방식이 좋습니다.

* 영문 소문자 사용
* 단어 구분은 `_` 사용
* 이벤트 이름은 `동사_명사` 형식 사용

예시:

```
view_home
click_signup
complete_purchase
product_id
product_name
```

### 2. 플랫폼이 달라도 같은 행동은 같은 이름을 써야 합니다

Web와 App에서 UI는 달라도 사용자의 행동 의미가 같을 수 있습니다.

이 경우 이벤트 이름도 동일해야 합니다.

* Web 버튼 클릭
* App 탭 진입

위 두 동작이 모두 "상품 상세 조회"라면 같은 이벤트 이름을 쓰는 것이 좋습니다.

예시:

```
view_product_detail
```

### 3. 개인식별정보는 최소화해야 합니다

이벤트나 속성에는 개인을 식별할 수 있는 정보를 신중하게 남겨야 합니다.

{% hint style="warning" %}
이메일, 전화번호, 이름 같은 정보는 꼭 필요한 경우에만 저장하세요. 저장 전에는 보안과 운영 정책을 반드시 확인하세요.
{% endhint %}

### 4. 이벤트는 사용자 행동 중심이어야 합니다

이벤트는 사용자가 무엇을 했는지 설명해야 합니다.

대표적인 예시는 아래와 같습니다.

* 검색 실행
* 상품 상세 조회
* 장바구니 담기
* 결제 완료

백엔드에서 발생한 활동도 사용자 행동과 연결된다면 이벤트로 정의할 수 있습니다.

예시:

```
search_product
add_to_cart
complete_payment
```

### 5. 이벤트 이름은 너무 추상적이거나 너무 구체적이면 안 됩니다

너무 추상적이면 의미가 모호합니다.

너무 구체적이면 재사용과 분석이 어려워집니다.

좋은 기준은 "행동은 이벤트 이름에, 세부 정보는 속성에" 담는 것입니다.

예시:

* 나쁨: `page_view`
* 나쁨: `view_home_ipad`
* 좋음: `view_home`

`ipad` 같은 세부 정보는 이벤트 속성으로 저장하는 편이 좋습니다.

## Event Property와 User Property의 차이

### Event Property

Event Property는 특정 행동이 발생한 당시의 맥락입니다.

예를 들어 `view_product_detail` 이벤트에는 아래 정보가 함께 들어갈 수 있습니다.

* `product_id`
* `product_name`
* `category_id`
* `rating`

이 정보는 같은 이벤트라도 상황마다 달라질 수 있습니다.

### User Property

User Property는 이벤트를 발생시킨 사용자의 상태 정보입니다.

예를 들면 아래와 같습니다.

* `user_id`
* `membership_grade`
* `is_first_visit`
* `acquisition_channel`

어떤 값은 고정되고, 어떤 값은 시간이 지나며 바뀔 수 있습니다.

* `user_id`는 보통 유지됩니다.
* `membership_grade`는 변경될 수 있습니다.

## 속성 이름도 일관되어야 합니다

같은 의미의 데이터는 항상 같은 이름으로 저장해야 합니다.

예를 들어 상품명을 저장할 때 아래처럼 이름이 섞이면 분석이 어려워집니다.

* `product_name`
* `product_nm`

위 둘 중 하나만 선택해 전체 서비스에서 통일하세요.

## 작성 전 체크리스트

새 이벤트를 만들기 전 아래 항목을 확인해보세요.

* 이 이름만 봐도 어떤 행동인지 이해되는가?
* 다른 플랫폼에서도 같은 이름을 쓸 수 있는가?
* 너무 추상적이거나 너무 구체적이지 않은가?
* 세부 정보는 속성으로 분리했는가?
* 같은 의미의 속성 이름이 이미 존재하지 않는가?
* 개인식별정보를 불필요하게 저장하고 있지 않은가?

## 더 읽어보기

* [이벤트 네이밍은 어떻게 정의하나요?](https://blog.hackle.io/post/event-taxonomy?utm_source=guide)
* [설계한 이벤트는 어떻게 활용되나요?](https://blog.hackle.io/post/hackle-datawebinar2-takeaway?utm_source=guide)
* [이벤트 정의부터 활용까지 전체적으로 알고 싶어요](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/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.