2. 이벤트 설계 원칙
1장에서 이벤트 패스와 택소노미의 전반적인 구조를 다루었다면, 이제 개별 이벤트를 어떻게 설계해야 하는지에 대해 고민해볼 차례다. 택소노미는 단순히 이벤트를 나열하는 것이 아니라, 어떤 이벤트를 정의할지, 각 이벤트가 어떤 역할을 해야 하는지, 그리고 데이터 분석에 실질적으로 도움이 되는지를 고려하며 설계해야 한다.
버거킹 택소노미를 설계하면서 나는 처음에 “이벤트를 최대한 많이 수집하는 것이 좋은 것 아닌가?”라는 생각을 했다. 하지만 이는 큰 착각이었다. 불필요한 이벤트를 줄이고, 필요한 이벤트만 남기는 것이 너무나 중요했다. 너무 많은 이벤트가 있으면 데이터가 복잡해지고, 분석 과정이 오히려 더 어려워지기 때문이다.
이벤트를 정의할 때 중요한 것은 단순히 많은 데이터를 쌓는 것이 아니라, 데이터가 실제로 분석에 활용될 수 있도록 구조적으로 설계하는 것이다. 그렇다면, 실무에서 효율적인 이벤트 설계란 무엇일까?
2.1. 모든 이벤트를 잡지 마세요. 제발!
웹 및 앱에서는 다양한 이벤트가 발생하게 된다. 누군가는 제품을 검색할 수도, 추천 제품에 호기심을 가지고 해당 제품의 상세페이지를 확인할 수도, 장바구니에 담긴 제품들을 점검할 수도 있다. 그렇다면 우리는 발생할 수 있는 모든 경우의 수의 이벤트를 수집해야만할까? 당연히 그렇지 않다. 특히 Amplitude에서는 모든 이벤트를 수집하면 고객사가 어마어마한 비용을 지불하게 된다. 그럼 어떠한 이벤트를 잡아야 할까?
해답은 간단하다. 마케터의 관점에서 생각하는 것이다.
해당 이벤트를 수집하는 것이 마케팅의 측면에서 유의미할까?
해당 이벤트에서 수집한 정보를 바탕으로 마케팅 개선을 유도할 수 있을까?
버거킹 프로젝트에서는 다음과 같은 상황이 있었다. 사이드 추천 팝업을 닫을 때 “오늘 하루 추천 받지 않음”과 “닫기”의 두 가지의 버튼이 존재하였고, 이에 따라 이벤트를 구분하는 2가지의 시나리오가 발생하였다. 어떤 방법이 나아보이는가?
🍔 버거킹 프로젝트 - 사이드 추천 팝업 닫기
stop_side_recommend_button/close_side_recommend_button
: 두 가지 케이스를 별도의 이벤트로 나누어 수집closed_side_recommend_popup
: 두 가지 케이스를 하나의 이벤트로 통합하여 수집
팀장님과 상의 후 내린 결론은 "해당 이벤트는 수집하지 않는다"였다. 이유는 마케팅적 관점에서 생각해보면된다.
사이드 추천 팝업으로 발생하는 정보로 활용할 수 있는 마케팅적 분석은 “추천에 대한 고객 전환율”이다. 다시 말해 마케터가 궁금한 것은 해당 팝업의 제품을 클릭하여 구매까지 이어지는 고객의 비율이며, 해당 팝업을 닫는 유저 비율을 만약 알고 싶다면 (1 - 추천에 대한 고객 전환율)을 통해 충분히 쉽게 파악할 수 있다. 따라서 사이드 팝업을 닫는 것에 대한 이벤트는 마케팅 관점에서 낮은 효용을 가지며, 해당 이벤트를 수집한다면 이는 의미없이 과도한 이벤트를 집계하는 것이 될 수 있다.
물론, 택소노미에 정답은 없다. 고객사의 다양한 니즈에 따라, 그리고 그로스 매니저의 판단에 따라 얼마든지 변화할 수 있기 때문이다. 예를 들어 버거킹에서 UI/UX 관점에서의 개발도 요구되는 상황이었다면, 시나리오 1번처럼 두 가지 이벤트를 별개로 수집하는 것이 필요했을지도 모른다. 택소노미의 본질은 데이터 분석을 위한 구조를 설계하는 데 있다. 즉, 수집되는 이벤트는 항상 분석 목적이 명확해야 한다. 단순히 “이벤트를 기록하면 좋을 것 같아서”라는 이유로 데이터를 쌓는 것이 아니라, 이벤트를 어떻게 활용할 것인지 먼저 정의한 후 수집해야 한다.
예를 들어, 설문조사를 설계할 때도 어떤 분석을 수행할 것인지 먼저 고려하고, 그에 필요한 질문을 구성한다. 마찬가지로, 택소노미 설계에서도 최종적으로 어떤 인사이트를 얻을 것인지 미리 정의한 후, 이를 달성하는 데 꼭 필요한 이벤트만을 수집하는 것이 중요하다. 이를 통해 불필요한 이벤트를 배제하고, 최적화된 구조를 설계할 수 있다. 다시 말해, “데이터를 수집하는 것”이 목표가 아니라, “데이터를 활용할 수 있도록 설계하는 것”이 목표가 되어야 한다.
2.2. 이벤트? 이벤트 프로퍼티?
버거킹 주문에는 “킹오더”와 “딜리버리오더”의 두 가지 타입이 존재한다. 킹오더는 직접 매장에서 식사하거나, 포장하는 등 대면을 통해 제품을 수령받아야하는 방식이며 딜리버리 오더는 제품을 지정된 주소로 배달받는 방식의 주문이다. 그리고 2023년도 택소노미에서는 두 가지 오더를 각각 k와 d로 구분하여 모든 이벤트를 분리 하였다.
예를 들어 제품의 상세페이지를 조회하는 이벤트인 item_detail_viewed를 킹오더 채널을 통한 경우라면 k_item_detail_viewed로, 딜리버리오더 채널을 통한 경우라면 d_item_detail_viewed로 구분하는 식이다. 그런데 해당 이벤트들을 처음 보자마자 가진 의문점이 하나 있었다.
이벤트 종류를 왜 이렇게 과도하게 많이 잡았을까?동일한 이벤트인데 굳이 왜 k와 d로 나누어 수집해야만 하는거지?
이벤트를 과도하게 세분화하는 것은 관리의 복잡성을 증가시키고, 데이터 분석의 일관성을 해칠 수 있다. 따라서 주문 유형을 구분해야 한다면, order_type을 이벤트 프로퍼티로 추가하는 것이 더 효율적이라고 생각했다. 이에 대한 해답을 찾기 위해 또다시, 팀장님을 찾아갔다.🥺
이유는 간단했다. 고객사가 생각하는 해당 이벤트의 중요도, 그리고 분석의 용이성 때문이었다. 택소노미는 그 자체가 목적이 아니라 후에 앰플리튜드를 활용한 데이터 분석 및 시각화에 사용되는 입력값이라는 것을 기억할 것이다. 따라서 택소노미는 고객사가 데이터를 쉽고 유용하게 활용할 수 있도록 작성되어야 한다.
예시를 들어보자. 다음은 버거킹 앰플리튜드 내 퍼널 차트 영역이다.
첫번째 사진의 차트는 k_item_list_viewed 이벤트를 실행한 유저 중 k_order_clicked 이벤트를 실행한 유저의 비율을 시각화하고 있다. 즉, [킹오더] 중에서 [아이템 목록을 조회한] 유저의 [주문하기 버튼 클릭] 전환율을 나타내고 있다.
현재는 오더의 종류를 k와 d 로 이벤트 상에서 구분해 놓았기 때문에 해당 차트를 제작하기 위해서는 [Events] 영역 내에서 이벤트를 클릭한 후 k_item_list_viewed, k_order_clicked 의 두 이벤트를 순차적으로 선택하면 된다. 만약 두 오더를 이벤트 상에서 구분하지 않고, 프로퍼티로 구분한다면 동일한 차트를 나타내기 위해서 어떻게 해야할까?
기존에는 두 번의 클릭으로 해당 차트를 만들어 낼 수 있었지만, 두 오더를 통합한다면 이벤트를 선택하고, 각 이벤트의 프로퍼티를 선택하고, 프로퍼티의 값을 선택하면서 총 6번의 클릭이 요구된다.
엥? 이게 왜 복잡하지. 그냥 클릭 좀 하면 되는거 아닌가?
위와 같이 생각할 수 있지만 고객사의 입장은 매우 다르다.
요식업에서 고객의 방문과 배달은 완벽히 분리되어있는 두 주요 구매 퍼널이고, 이에 따라 분석 시 통합된 하나의 분석보다 별개의 분석으로 나누어 보는 것이 더 유용한 인사이트를 제공한다.
마찬가지로 버거킹 입장에서 킹오더와 딜리버리 오더는 완벽히 구분하여 분석되어야 하는 두 가지의 구매 퍼널이다. 즉, 모든 분석에 기본적으로 두 오더가 구분되어야 하는데 모든 이벤트에 [+ Filter by]를 추가적으로 걸어주어야하는 구조라면 고객사의 마케터 입장에서 피로도는 매우 상승할 것이다. 또한 고객사의 모두가 택소노미와 앰플리튜드에 숙달되는 것은 매우 힘든 일이다. 만일 초보자가 이를 사용한다면 계속해서 가이드를 확인해야만 하며 이는 고객사 데이터 문해력을 저해하는 행위일 것이다.
쪼갰을 때 장점은 알겠어. 근데 합쳐서 보고싶다면? 전체 주문에 대한 전환율이 보고 싶을 때도 많잖아.
혹시 이런 생각을 했다면 당신은 나와 아주 그냥 똑같은 사람이다! 해당 질문에 대한 해답은 커스텀 이벤트(Custom Event)이다.
✅ 커스텀 이벤트(Custom Event) 생성법
: Amplitude에서는 두 가지 이상의 이벤트를 묶어서 볼 수 있는 커스텀 이벤트가 존재한다. 해당 커스텀 이벤트를 정의하면 이후에도 쉽게 이벤트를 불러올 수 있다.
1. [Combine events inline]을 통해 두 가지 이벤트를 삽입하기
2.[Save Custom Event]를 통해 두 이벤트를 하나의 이벤트로 묶기
3. 커스텀 이벤트를 생성할 수 있는 마케터가 되어보자!
계속해서 말했지만 택소노미에 정답은 없다. 그러나 왜 그렇게 택소노미를 구현했는지에 대하여 다른 사람을 설득할 수 있는 논리가 필요하다. 그리고 그 논리가 이번엔 고객사의 편의성이다.
2.3. View 이벤트의 효용성 고민하기
이벤트 트리거에는 몇 가지 방식이 존재하지만, 주로 click과 view 가 활용된다. 버거킹 택소노미에서도 소수의 complete 트리거를 제외하고는 대부분의 이벤트가 click 혹은 view 로 트리거되었다.
신기한 점은 2023 버전 버거킹의 택소노미에는 유독 view 이벤트가 많았다는 것이다. view 이벤트는 어떨 때 활용하면 좋을까?
그러나 View 이벤트를 과도하게 사용하면 데이터 최적화에 문제가 생길 수 있다. 페이지를 로드할 때마다 트리거가 된다면 불필요한 이벤트가 대량으로 수집될 위험이 있기 때문이다.
따라서 특정 이벤트의 트리거를 view 로 잡는 것은 정보 수집 측면에서 하이 리스크, 하이 리턴 (High Risk, High Return)이 될 수 있으므로 우리는 이벤트 트리거를 설정할 때 view 의 효용성을 항상 생각해야 한다. 이에 따라 버거킹 택소노미의 일부 이벤트에도 변경점이 발생하였다.
이 과정을 통해서 무의미해진 기존의 6개의 이벤트는 삭제, 2개의 이벤트가 추가되면서 이벤트 패스의 최적화가 이루어졌다. 이처럼 트리거 방식 하나를 선택하는 것만으로도 데이터의 질과 분석의 신뢰도가 달라질 수 있다. 이벤트 설계에서 view 이벤트는 사용 목적이 명확할 때 신중하게 활용하는 것이 바람직하다.
(3부에서 계속)
관련 블로그글 링크
1부 : MZ 그로스 매니저의 택소노미 설계 꿀팁 대방출(1) (ft. 버거킹)
3부 : MZ 그로스 매니저의 택소노미 설계 꿀팁 대방출(3) (ft. 버거킹)
