이벤트 이름 짓기 규칙: 나중에 후회 안 하는 분석 이벤트 택소노미 설계법

제품 분석을 처음 붙일 때는 일단 로그가 쌓이는 것만으로도 뿌듯합니다. 하지만 시간이 지나면 click_1, button_clicked, user_action 같은 이름이 무엇을 의미하는지 아무도 설명하지 못하는 순간이 옵니다. 이벤트 이름은 개발자만 보는 코드가 아니라, 미래의 내가 읽을 분석 보고서의 문장입니다.

조코헌트 집계에서 출시 첫 24시간 안에 업보트나 댓글 같은 반응을 하나라도 받은 프로덕트는 56%였습니다. 이런 흐름을 분석하려면 ‘반응이 있었다’가 아니라 어떤 행동이 언제 완료됐는지를 일관된 이름으로 남겨야 합니다.

1. 이벤트 이름은 보고서의 문장이다

가장 무난한 출발점은 object_action 구조입니다. 무엇이(object) 어떤 상태가 됐는지(action)를 읽히게 만드는 방식입니다. 예를 들면 signup_completed, project_created, comment_submitted처럼 씁니다.

완료된 행동을 기준으로 짓기

버튼이나 화면 이름보다 제품 안에서 일어난 의미 있는 행동을 기준으로 정하세요. start_button_clicked보다 trial_started가 낫습니다. 버튼이 나중에 링크나 자동 실행으로 바뀌어도 분석 의미가 유지되기 때문입니다.

가능하면 완료형 동사를 사용하세요. signup_started와 signup_completed는 서로 다른 단계입니다. 시작과 성공을 구분해야 중간 이탈을 볼 수 있습니다.

이름만 보고도 범위를 알 수 있게

created처럼 목적어가 없는 이름은 피하세요. workspace_created와 document_created는 비슷해 보여도 분석 질문이 다릅니다. 약어, 내부 변수명, 특정 화면의 명칭도 시간이 지나면 해석 비용이 커집니다.

2. 이벤트와 속성의 경계

모든 정보를 이벤트 이름에 넣으면 이름이 폭발하고, 모두 속성으로 보내면 핵심 행동을 찾기 어려워집니다. 판단 기준은 “이 차이가 퍼널이나 사용자 여정의 단계인가?”입니다.

별도 이벤트로 남길 것

행동 자체가 달라지거나, 성공·실패·취소처럼 여정의 상태가 달라지면 이벤트를 나눕니다. 예를 들어 payment_started, payment_completed, payment_failed는 같은 결제 흐름에 있지만 분석 목적이 다릅니다.

속성으로 남길 것

같은 행동의 맥락만 달라진다면 속성으로 보냅니다. signup_completed 하나에 method: email 또는 method: oauth, source: landing_page처럼 붙이는 식입니다. 이렇게 해야 이벤트 목록은 안정적으로 유지되고, 나중에 조건별 비교도 가능합니다.

개인 이메일, 이름, 자유 입력 문장처럼 분석에 꼭 필요하지 않은 개인정보는 기본적으로 속성에 넣지 마세요. 수집 목적과 보관 정책은 사용하는 분석 도구의 공식 문서에서 확인하세요.

3. 택소노미를 설계하는 순서

이벤트 이름부터 무작정 적기보다 사용자의 핵심 여정을 먼저 펼쳐보면 누락과 중복이 줄어듭니다.

핵심 여정에서 출발하기

가입, 첫 가치 경험, 반복 사용, 공유, 결제처럼 제품의 중요한 흐름을 적습니다. 각 단계에서 “사용자가 무엇을 완료하면 다음 단계로 넘어가는가?”를 질문하세요. 그 답이 이벤트 후보입니다.

그다음 이벤트마다 목적, 발생 조건, 필수 속성, 예시 값을 적습니다. 개발자가 구현할 때 조건을 추측하지 않도록 “페이지가 열렸을 때”가 아니라 “서버 요청이 성공했을 때”처럼 트리거를 구체화하세요.

문서 표를 먼저 만들기

간단한 표 하나면 충분합니다.

이 표를 코드보다 먼저 리뷰하면 이벤트가 너무 많거나, 반대로 중요한 행동이 빠진 문제를 초기에 발견할 수 있습니다. 실제 도구에 이벤트를 연결하는 과정은 PostHog Next.js 설치부터 첫 이벤트 추적까지: 인디 메이커용 30분 셋업 가이드에서 이어서 확인할 수 있습니다.

4. 자주 생기는 두 가지 실패

너무 잘게 쪼개는 경우

hero_cta_clicked, navbar_cta_clicked, mobile_cta_clicked처럼 UI 위치마다 이벤트를 만들면 대시보드는 금방 복잡해집니다. 행동의 목적이 같다면 signup_started 하나에 placement 속성을 추가하는 편이 보통 낫습니다.

단, 위치별 클릭이 실제로 서로 다른 여정이나 실험의 기준이라면 속성으로 보존하세요. 이벤트를 합치는 것이 목표가 아니라, 분석 질문을 유지하면서 구조를 단순하게 만드는 것이 목표입니다.

너무 크게 뭉뚱그리는 경우

반대로 user_action이나 content_interaction 하나에 모든 행동을 담으면 이벤트는 적어도 의미가 사라집니다. 이름만 보고도 핵심 행동과 완료 조건이 떠오르지 않는다면 다시 쪼개야 합니다.

이미 망가진 이름을 한 번에 전부 바꾸기보다 새 규칙을 정하고, 기존 이벤트와 새 이벤트의 대응표를 만든 뒤 코드가 안정되면 옛 이름을 제거하세요. 과거 데이터와 새 데이터를 섞어 해석하지 않도록 전환 시점도 기록해두면 좋습니다.

5. 출시 후에도 지키는 운영 규칙

이벤트 택소노미는 한 번 작성하고 끝나는 문서가 아닙니다. 기능을 추가할 때마다 기존 이벤트로 표현할 수 있는지 먼저 확인하고, 정말 새로운 분석 질문이 생길 때만 이벤트를 추가하세요.

주기적으로 이름 목록에서 중복, 미사용, 의미가 불명확한 항목을 찾고, 대시보드와 이벤트 문서의 이름이 같은지 확인합니다. 활성 사용자를 어떤 행동으로 정의할지 정리할 때는 DAU·WAU·MAU 제대로 정의하기: '활성 사용자'를 우리 제품에선 무엇으로 셀까를 함께 참고하면 좋습니다.

마지막으로 이벤트를 추가하기 전 세 가지를 체크하세요.

• 이 이벤트만 보고도 행동과 완료 조건을 이해할 수 있는가?
• 변형 정보는 이름이 아니라 속성으로 분리했는가?
• 이 이벤트가 실제 의사결정이나 퍼널 분석에 쓰이는가?

이 기준을 통과한 이벤트만 남기면 데이터는 적어도 오래 쓸 수 있습니다. 숫자를 많이 모으는 것보다, 같은 이름이 같은 의미를 계속 유지하는 것이 1인 제품의 분석 기반을 더 단단하게 만듭니다.