안녕하세요 오토피디아에서 데이터 엔지니어로 일하고 있는 김건우입니다.
이벤트 텍소노미는 앱 내에서 유저들이 하는 유의미한 행동인 이벤트와 분류라는 뜻의 텍소노미가 합쳐진 것으로 말 그대로 이벤트를 특정 규칙에 따라 정의하고 분류하는 체계를 정의하는 것을 말합니다.
오토피디아에서는 웹, 앱에서 발생하는 사용자 행동 로그를 수집하고 분석하기 위해 GA, firebase를 통해 이벤트 데이터를 수집하고 있습니다. 이를 통해서 프로젝터마다 필요한 고객 행동과 퍼널을 분석하고 시각화하고 있었습니다. 하지만 이벤트를 설계하고 활용하는 과정에서 몇 가지 아쉬운 부분이 있었는데요.
저는 앞으로 닥터차가 플랫폼화 되면서 앱 내에 더욱 다양한 기능들이 배포, 운영됨에 따라 고객 행동 데이터를 분석하고 관리하는 일이 매우 중요하다고 판단하였습니다. 이에 따라 이번 기회에 기존에 명확히 정리되지 않았던 오토피디아 이벤트 텍소노미 재정의하는 것이 좋겠다고 생각하였고 바로 실행에 옮기게 되었습니다.
이번 글에서는 제가 이러한 이벤트 텍소노미를 설계했던 과정과 어떤 부분을 해결할 수 있었는지를 공유드리려고 합니다.
먼저 정확히 어떤 부분에서 불편함을 느껴 이 문제를 해결하려 하였는지 설명드리려고 합니다. 다양한 문제들이 눈에 밟혔지만 이번 텍소노미 설계에서는 크게 두 가지 부분을 해결하려 하였습니다.
보통 저희는 이벤트를 새로운 프로젝트나 기능이 런칭될 때 만들어 심고는 하였습니다. 하지만 매번 정확히 보려는 핵심 지표없이 모든 버튼에 이벤트를 심는 경우가 많았는데요. 그러다 보니 처음에는 잘만 쓸 것 같은 이벤트를 며칠만 쓰고 버리는 경우가 생기기도 했습니다.
또한 이벤트 이름도 명확히 정의된 규칙이 없었기 때문에 click_call_button, inquiry_begin 등 온갖 이벤트 이름이 난무했습니다. 게다가 GA에서는 이벤트 생성 개수 제한이 있어 이벤트 이름을 무지성으로 짓다보면 언젠가는 limit에 걸리고 마는 일이 생길 수도 있습니다.
그리고 만든 이벤트를 관리하는 테이블인 트래킹 플랜의 업데이트 문제도 있었습니다. 저희는 노션으로 이벤트 트래킹 플랜을 관리하였는데요. 스타트업의 빠른 기능 추가와 배포는 트래킹 플랜이 이벤트의 SSOT로써 작동하지 않고 실제 운영중인 이벤트와 싱크가 안맞는 모습을 보였습니다.
제대로 동작 중인지를 알기 어려운 상태
이러한 두 가지 문제를 먼저 해결하는 것이 제대로 된 이벤트 활용을 할 수 있는 첫걸음이겠다는 생각과 함께 각각 해결방안을 탐색하고 정리해나갔습니다.
첫번째로 살펴볼 것은 이벤트 설계 규칙입니다. 앞서 말씀드린 것과 같이 저희 조직에서는 이벤트를 설계할 때 모두가 지켜야 하는 규칙이 부재했습니다. 그래서 이벤트 설계의 대전제가 가장 우선으로 필요했습니다. 이러한 규칙을 통해 이벤트를 왜 만들고 어떻게 만드는 지를 명확하게 하고자 했습니다. 또한 새로운 인원이 왔을 때도 흔들림 없이 이벤트 설계가 가능할 것입니다.
이를 위해 다양한 이벤트 텍소노미 가이드를 찾아보았는데요. 대부분의 가이드에서 이벤트에 대해 공통적으로 이야기 하는 부분이 있었습니다. 이벤트는 어떤 지표를 보기 위해 설계한다고 말이죠. 당연한 말 같겠지만 저는 이 부분이 생각보다 저희 조직에서는 잘 지켜지지 않고 있다고 생각했습니다.
지금까지는 새로운 기능이 추가되면 그냥 당연한 듯이 이벤트를 심고 이를 대시보드로 만들 때 즈음에 비로소 무엇을 보고자 하는지 생각하였는데요. 이제는 이를 이벤트 설계 과정부터 문서화해야겠다고 생각했습니다.