새 기능 하나 낼 때마다 이벤트 이름을 그때그때 짓다 보면, 6개월 뒤엔 addToCart, add_cart, cart_add가 한 서비스에 다 섞여 있어요. 사람은 대충 알아보지만, 매체 최적화 알고리즘과 대시보드는 그렇지 못해요. 이벤트 택소노미는 이걸 막는 이름·파라미터·발화 시점의 표준 계약이에요.

왜 이름 하나가 이렇게 중요한가

이벤트명은 그냥 라벨이 아니에요. Google UAC·Meta AAP 같은 자동입찰 캠페인이 "성과가 좋았다/나빴다"를 판단하는 학습 신호가 바로 이 이벤트예요. 오늘 purchase로 보내던 걸 다음 주 order_complete로 바꾸면, 매체 입장에선 완전히 새로운(그리고 데이터가 0인) 이벤트가 생긴 거예요. 캠페인 학습이 통째로 리셋돼요.

최소한 지켜야 할 것들

snake_case 통일: addToCart(X) → add_to_cart(O). 대소문자·구분자 혼용 금지.
매체 예약어 회피: session_start, first_open처럼 MMP·SDK가 이미 자동으로 쓰는 이름을 자체 이벤트로 다시 쓰면 충돌해요.
PII 절대 금지: 이메일·전화번호·이름을 파라미터 값에 직접 넣지 마세요. 필요하면 해시 처리.
통화 코드 항상 동반: revenue 파라미터를 보낼 땐 currency(ISO 4217, 예: KRW)를 항상 같이 보내세요. 매출 정규화는 나중에 서버에서, 클라이언트는 원본 통화로.

실무에서 진짜 자주 터지는 문제들

매출이 매체 대시보드에서 계속 0으로 보인다: currency 누락, 또는 매체 파트너 설정에서 해당 이벤트가 "Revenue Event"로 체크가 안 돼 있는 경우가 많아요.
같은 결제가 여러 번 잡혀 ROAS가 부풀려진다: 결제 콜백이 네트워크 재시도로 중복 발화되는 경우예요. transaction_id를 유니크 dedup 키로 강제하고, 서버 검증이 끝난 뒤에만 클라이언트가 이벤트를 쏘게 하세요.
자동입찰 캠페인이 학습을 계속 못 벗어난다: 최적화 대상 이벤트(예: purchase)의 주간 발화량이 너무 적으면 알고리즘이 수렴을 못 해요. 이럴 땐 일시적으로 상위 퍼널 이벤트(add_to_cart 등)로 최적화 목표를 낮춰 학습량부터 채우는 방법을 써요.

정직하게

택소노미는 한 번 정하면 자주 못 바꿔요. 이벤트명을 바꾸면 과거 데이터와 단절되고, 매체 학습도 다시 시작해야 해요. 그래서 처음 설계할 때 인앱 이벤트 택소노미 설계서처럼 퍼널 전체를 놓고 한 번에 정하는 게, 나중에 하나씩 고치는 것보다 훨씬 싸게 먹혀요.