이벤트 택소노미로 앱 분석 데이터를 쓸모있게 만드는 법

앱을 운영하다 보면 데이터는 계속 쌓이는데, 정작 필요한 순간에 쓸만한 데이터를 찾지 못하는 경우가 많습니다. 유저가 어디서 이탈하는지 어떤 기능이 전환에 기여하는지 같은 질문에 답하려면 데이터를 뒤져야 하는데, 막상 뒤져보면 정리되지 않은 데이터만 쌓여 있는 상황이 발생하는 거죠.

이 문제의 근본 원인은 대부분 이벤트 택소노미의 부재입니다. 이벤트 택소노미란 어떤 유저 행동을, 어떤 이름으로, 어떤 속성과 함께 기록할지를 정하는 설계도인데, 이게 없으면 데이터는 쌓이지만 쓸 수 없는 상황이 반복되고, 반대로 있으면 데이터가 바로 의사결정과 매출로 연결될 수 있습니다.

우리 앱 데이터는 쌓여도 쓸모가 없었던 이유

이벤트 택소노미 없이 데이터를 쌓으면 어떤 일이 생길까요?

먼저, 분석가의 시간 대부분이 데이터 정리에 쓸립니다. 통상 이벤트 택소노미가 없는 환경에서 데이터 분석가 시간의 40~60%가 데이터 정리에 들어가고 있다고 하거든요.

두 번째, 팀마다 다른 이름으로 같은 행동을 기록하게 됩니다. 개발팀은 btn_click으로, 마케팅팀은 buttonClicked로, 분석팀은 click_button으로 같은 행동을 서로 다른 이름으로 저장하는 상황이 생기다가 추후 합치려면 막대한 정리 작업이 필요해집니다.

세 번째, 내가 원하는 데이터가 없는 경우가 생깁니다. 이벤트 택소노미를 정해두지 않으면 일단 수집할 수 있는 데이터를 중구난방으로 최대한 수집하는 경우가 생기는데, 이러면 데이터는 넘치는데 정작 필요한 건 빠져 있는 상황이 발생하기 쉽거든요. ‘이 유저가 구매 전에 어떤 화면을 거쳤나?’ 같은 질문에 답하려는데, 정작 그 화면의 이벤트를 수집하지 않았던 것과 같은 상황들이 발생하는 거죠.

이벤트 택소노미 설계 3가지 원칙

이벤트 택소노미를 설계할 때 핵심적으로 정해야 할 것은 세 가지입니다.

1. 이름 짓기 : Object_Action 형식으로 통일

이벤트 이름은 대상_행동 형식으로 짓는 게 가장 일반적입니다. 예를 들면 주문 완료는 order_completed, 상품 조회는 product_viewed, 회원가입 버튼 크릭은 signup_started 같은 식이죠.

대문자 대신 소문자 + 언더바(_)로 단어를 구분하는 snake_case를 쓰는 게 좋습니다. 이런 구조가 iOS, Android, 웹 어디서든 호환되고 데이터베이스 쿼리에도 쉽거든요.

하지만 무엇보다도 이벤트 택소노미를 위한 이름 짓기에서 가장 중요한 건 모든 플랫폼과 모든 팀이 같은 이름을 쓰는 것입니다. Android에서 productViewed라고 쓰고 iOS에서 product_viewed라고 쓰면 나중에 각각을 대조해 합치는데 적지 않은 시간과 비용이 투입되거든요.

2. 속성 설계 : 이벤트 이름에 동적 값을 넣지 않기

흔한 실수 중 하나가 이벤트 이름 안에 변하는 값을 넣는 것입니다. 예를 들어 purchased_blue_widget_29900이나 viewed_product_12345 같은 식으로 이름을 지으면, 상품마다 이벤트가 수천 개씩 생기면서 분석이 불가능해집니다.

올바른 방법은 이벤트 이름은 하나로 통일하고, 변하는 값은 속성(property)으로 분리하는 것입니다. 예를 들면 이벤트는 item_purchased로 통일하고, 속성으로 color : blue, price : 29900, product_id : 12345를 붙이는 방식이죠.

이때 속성 이름도 명확하게 짓는 게 중요합니다. type이라는 모호한 이름 대신 item_type, payment_type처럼 맥락이 분명한 이름을 쓰는 게 나중에 헷갈리지 않습니다.

3. 범위 정하기 : 이 데이터로 어떤 판단을 할 건지부터 역산

이벤트 택소노미를 설계할 때 가장 중요한 원칙은 어떤 이벤트를 수집할까가 아니라 이 데이터로 어떤 의사결정을 할 건가를 먼저 정하는 것입니다.

예를 들어 구매 전환율을 높이고 싶다는 목표가 있으면, 유저가 구매 전에 어떤 화면을 거치는지를 알아야 하죠. 그러면 상품 조회(product_viewed), 장바구니 추가(cart_added), 결제 페이지 진입(checkout_started), 주문완료(order_completed), 같은 이벤트가 필요하다는 게 자연스럽게 정해질 수 있습니다.

권장하는 이벤트 수는 핵심 질문에 답할 수 있는 10~200개 내외이며, 처음에는 20~30개 핵심 이벤트로 시작하는 게 현실적이죠.

이벤트 택소노미를 설계할 때 흔히 하는 실수 5가지

이벤트 택소노미를 설계할 때 많은 팀이 반복적으로 범하는 실수들이 있습니다.

1. 모든 걸 다 추적하려다 데이터 과잉

나중에 필요할 수도 있으니까라는 생각으로 모든 버튼 클릭, 모든 화면 전환, 모든 스크롤을 기록하면 데이터만 넘치고 정작 분석은 어려워집니다.

이를 방지하기 위해서는 이벤트를 설계하기 전에 이 데이터를 알면 어떤 행동을 취할 수 있는가?를 먼저 물어보는 게 좋은데, 만약 답이 없으면 그 이벤트는 우선 과감하게 수집하지 않아도 괜찮습니다.

2. 팀마다 다른 이름을 쓰는 비일관성

위에서 설명한 것처럼 btn_click, buttonClicked, click_button이 각각 들어오면 나중에 데이터를 합치는 작업에만 상당한 비용과 시간이 필요합니다.

따라서 처음부터 명명 규칙을 정하고 모든 팀과 플랫폼에 동일하게 적용하는 게 좋습니다.

3. 속성 없이 이벤트만 기록

order_completed라는 이벤트만 있고 결제 금액, 결제 방법, 상품 카테고리 같은 속성이 없으면 구매가 일어났다는 사실만 알고 왜, 어떻게는 알 수 없겠죠? 이런 상황을 예방하기 위해서는 이벤트마다 필수 속성과 선택 속성을 정의해두는 게 좋습니다.

4. 한 번 설계하고 방치

앱의 기능이 바뀌고, 유저 행동 패턴이 달라지면 기존에 설계한 이벤트 택소노미가 더 이상 맞지 않는 상황이 벌어지기도 합니다. 분기마다 이벤트 택소노미를 점검하고 업데이트하는 습관이 필요한 이유죠.

5. iOS와 Android 이벤트명 불일치

Android에서는 productViewed, iOS에서는 product_viewed로 기록하면 통합 분석이 불가능해지기 때문에, 앱 분석에서 플랫폼 간 이벤트명 통일은 꼭 필요한 작업입니다.

잘 설계한 이벤트 데이터가 매출로 연결되는 구조

이벤트 택소노미를 잘 설계하면 데이터가 단순한 기록을 넘어 아래와 같은 구조로 연결되며 매출을 만드는 도구가 될 수 있습니다.

이벤트 데이터 → 유저 세그먼트 → 맞춤 메시지 → 전환

예를 들어 cart_added 이벤트가 있는데 order_completed가 없는 유저를 분류하면, 장바구니 이탈 유저 세그먼트가 만들어집니다. 이 세그먼트에 ‘담아둔 상품이 할인 중입니다’라는 맞춤 메시지를 보내면 전환을 유도할 수 있는거죠.

실제 리텐션을 봐도 이벤트 택소노미를 통해 맞춤형 푸시 알림을 적용하는 것의 성과는 어마어마합니다. 푸시 알림을 고객의 이벤트 데이터에 기반해 맞춤형으로 설계할 때에는 28일 기준 리텐션이 61~74%까지 나온 반면, 전체 발송 방식은 49%에 머무르고 있거든요.

이벤트 택소노미, 데이터를 쓸모있게 만드는 첫 단계

앱 데이터가 쌓이는데 쓸모가 없다면, 데이터를 더 모으는 게 아니라 이벤트 택소노미부터 제대로 설계하는 것이 필요한 순간일지도 모릅니다. 어떤 유저 행동을, 어떤 이름으로, 어떤 속성과 함께 기록할지를 먼저 정하면 데이터가 의사결정과 매출로 바로 연결될 수도 있으니까요.

물론 이 모든 과정을 처음부터 완벽하게 할 필요는 없습니다. 핵심 질문 3개를 정하고, 그 질문에 답할 수 있는 이벤트 20~30개부터 시작하는 것이 쓸모있는 데이터의 첫 단계입니다.

이러한 이벤트 택소노미 데이터에 실시간 타겟팅을 더했을 때 어떤 결과를 만들 수 있는지는 다음 글에서 더 상세히 이어 다뤄보겠습니다.

다음글 : SKAN 전환값 설정에서 흔히 하는 실수와 해결법

같은 유저 수로 더 버는 앱은 뭐가 다를까요 놓치고 있는 앱 추가 수익화 지점을 부담 없이 봐드릴게요 가볍게 진단받기