brunch

You can make anything
by writing

C.S.Lewis

by 엠지니어 May 30. 2024

이벤트 택소노미 완벽 설계하기⑴ (ft.네이버 시리즈)

이벤트 택소노미 설계 전 필독 유의사항

이벤트 택소노미 초기 설계 시, 어디에서부터, 무엇을, 어떻게 시작해야 할지 막막한 어려움을 조금이나마 해소해 드리고자, 밀리의 서재 · 버거킹 · 무신사 · 한샘 · 웍스아웃 · 발란 · KFC · 두나무 · 오늘의 집 등의 고객사들과 실제 프로젝트를 진행하며 얻은 인사이트를 공유드립니다.

본 1편에서는 <이벤트 택소노미의 정의와 설계 전 필독 유의사항>에 대해 다룹니다.

*보안상의 이유로 자료는 <네이버 시리즈>로 대체하였으며, 실제 데이터와는 무관한 자료임을 참고 부탁드립니다.

이벤트 택소노미란?

이벤트 택소노미는 크게 '이벤트 유형(Event Category)', '이벤트(Event)', '이벤트 속성(Property)'의 세 가지 항목으로 구성됩니다. '이벤트 카테고리'는 유저의 최종 행동 목적이며, '이벤트'는 이러한 목적을 달성하기 위한 주요 액션들의 묶음입니다. 그리고 각 이벤트 내에는 이벤트 발생 시 ‘추가적으로 수집하고 싶은 정보‘의 '속성'들로 구성됩니다. 이러한 이벤트와 프로퍼티를 특정 규칙에 따라 분류한 데이터 분류 체계를 ‘택소노미(Taxonomy)'라고 부릅니다. 즉, ‘이벤트 택소노미 설계'한다는 것은 자사 서비스 분석에 필요한 이벤트를 식별하고, 이벤트별로 어떤 속성이 들어가야 하는지 고민하여 데이터를 설계하는 작업을 의미합니다. 이를 통해 우리는 사용자의 행동 패턴을 이해하고, 그에 따른 마케팅 전략을 수립할 수 있습니다.

- 이벤트 유형(Event Category)

'이벤트 카테고리'란 이벤트의 유형을 정하기 위한 단위로, 유사한 이벤트를 하나로 묶어 관리할 때 유용한 요소입니다. '이벤트 카테고리'는 주로 최종 전환 이벤트로 정의되어 전환까지의 하나의 퍼널을 총칭합니다. 예를 들어 이벤트 카테고리가 ‘회원가입’인 경우, 이벤트 카테고리 내에는 홈페이지에 접속하여 특정 서비스를 이용하고자 회원가입 버튼을 클릭하여 회원가입 완료 페이지까지 이어지는 퍼널이 포함됩니다. 즉 ’이벤트 카테고리‘ = ‘최종 전환 이벤트의 퍼널’이라고 생각하시면 이해가 수월합니다.

- 이벤트(Event)

‘이벤트’란 사용자가 프로덕트를 사용하는 과정에서의 행동이나 그 결과로 발생하는 사건을 가리킵니다. 예를 들어, '로그인 버튼 클릭', ‘관심상품 추가', ‘장바구니 담기', ‘구매 완료' 등과 같은 일련의 사용자 행동이 이에 해당하며, 그 외에 ‘주문서 로딩 시간’, ‘서버 API 처리 시간’ 등도 이벤트로 볼 수 있습니다.

- 속성(Property)

프로퍼티란, 웹 문서의 동적인 객체 속성을 의미합니다. 쉽게 말해, 사용자나 이벤트가 가진 동적인 특성을 의미하며 사용자 행동에 대한 세부 분석을 위해 이벤트와 함께 수집됩니다. 예를 들어, '회원가입일자', '회원가입 방법', '회원가입 페이지 유입 경로' 등의 속성값이 이에 해당합니다.

- 이벤트(Event) vs. 속성(Property)

아래의 그림은 오프라인에서 우리의 행동을 온라인에서 발생하는 이벤트로 전환하여 표현했을 때 어떻게 정리할 수 있는지 보여주는 표입니다. 이를 통해 우리는 이벤트와 속성 간의 차이를 확인할 수 있습니다.

이벤트 택소노미 구축 프로세스 개요

1. 택소노미의 목적 및 방향성 수립

이벤트 택소노미를 설계하기 위해서는 먼저 이벤트의 목적과 방향성을 분명히 해야 합니다. 단순히 데이터 분석을 위해 택소노미를 설계한다는 것보다는 보다 명확하고 구체적인 목적이어야 합니다.

2. 주요 지표(이벤트 카테고리) 설정

다음으로 첫 미팅 시 담당자와 진행될 질의사항을 사전에 작성하여 공유합니다. 첫 협업인 만큼 질문자의 의도가 명확히 전달되지 않거나 답변자의 답변 내용이 충분히 공유되기 어려울 수 있습니다. 이후 지속적인 논의를 통해 주요 지표를 설정합니다.

3. 사용자 여정(User flow) 스케치

서비스의 주요 지표를 설정하고 나면 주요 지표로 도달하기까지의 대략적인 유저 플로우를 그립니다. 실제 사용자 입장으로 퍼널에 진입하여 최종 전환까지의 최소한의 경로를 그립니다.

4. 이벤트 & 프로퍼티 설계

유입부터 최종 전환까지 이어지는 단일 퍼널을 그렸다면, 각 단계별로 노드를 추가해 줍니다. 특히 반드시 선택해야 하는 필수 옵션이 있는 단계일 경우(e.g. 결제 버튼 클릭 시 ‘대여’와 ‘구매’ 중 한 가지를 선택해야 하는 경우) 이벤트, 혹은 이벤트 하위에 프로퍼티를 추가해 주어야 퍼널상의 누락을 방지할 수 있습니다.

5. 마케터 협의

5-6번 프로세스의 경우 수차례 반복될 수 있습니다. 모든 담당자들과의 합의점이 반영된 택소노미를 설계하기까지란 많은 소통과 협의가 필요한 데다, 마케터의 요구사항을 운 좋게 완벽히 반영했다고 하더라도 기능상 점검과 동작 검증이 불가피하기 때문입니다.

6. 개발자 협의

마케터와 협의 하에 설계된 1차 택소노미를 바탕으로 개발자와 검토하는 단계입니다. 개발자에게 택소노미의 전반적인 프로세스를 설명하면 개발자는 애널리틱스를 토대로 구현 가능성을 판단합니다. 일반적으로 마케터와 함께 미팅에 참석해 개발상의 이슈를 파악하고 개선점을 논의합니다.

7. QA 테스트

QA 테스트는 서비스 론칭 전 전반적인 개발 프로세스를 점검하고 개발상의 이슈를 조기 발견하여 조치하는 단계로, 담당자와 최종 협의된 논리적 설계에 따라 데이터 로그가 올바르게 적재되는지 확인합니다. 이 단계에서 잔존된 오류 및 결함을 발견하게 되거나, 더욱 효율적인 방안을 제안할 수도 있기 때문에 놓치는 부분이 없는지 특히 유의하여야 서비스 론칭 이후의 이슈를 최소화할 수 있습니다.

*QA(Quality Assurance)란?
사전적 의미로 '품질보증'을 의미하며, 일정 기간을 두고 프로덕트의 기능 검증 및 품질 테스트를 의미합니다. 단순한 기능 동작 통합 테스트뿐만 아니라 프로덕트의 시작과 마무리까지 모든 과정을 함께 기획하고 품질을 저하시키는 결함 요소들을 찾아 전체적인 품질을 향상하는 데 주목적이 있습니다.

8. 최종 수정

모든 설계 과정과 QA까지 마무리되었다면, 전반적으로 개선해야 할 작업이 있을지 최종적으로 점검합니다. 이후 광고를 운영할 수도 있고 신규 기능을 추가할 수도 있으며, 신규 서비스를 출시할 수도 있습니다. 최종 수정을 마친 후의 액션에 따라 위 단계를 반복하거나 건너뛸 수도 있습니다.

*본 글에서는 1번(이벤트 택소노미의 목적 및 방향성 수립)부터 3번(사용자 여정(User flow) 스케치)까지의 프로세스를 다룹니다. 4번(이벤트&프로퍼티 설계)부터의 프로세스가 궁금하시다면 아래 다음 글을 참고해 주세요.

▶︎ 다음 글 : 비용 최적화된 이벤트 택소노미 설계하기

이벤트 택소노미 설계 전 필독 유의사항

1. 이벤트 택소노미의 목적 및 방향성 수립

사실 이벤트 택소노미는 본격적으로 설계하는 시점보다, 설계하기 전 목적과 방향성을 분명히 하는 데 더 중점을 두어야 합니다. 목적과 방향성이 불분명한 상태로 설계를 시작하면 추후 수정이 잦아지고 설계가 복잡해지면서 혼동이 잦을 수 있기 때문입니다. 또한 복잡해진 설계를 해결하기 위해 수정을 지속 거치다 보면 택소노미 자체에 의미를 두게 되면서 정작 본연의 목적이 흐려질 수도 있습니다. 이벤트 택소노미는 데이터 분석을 위한 하나의 도구일 뿐이며, 택소노미를 설계하는 것 자체가 목적이 되어서는 안 됩니다. 마케팅 관점에서 분석에 용이해야 하고, 개발 관점에서 구현이 가능해야 하는 점을 기억해야 합니다.

마케팅 관점

*편의상 '마케팅'으로 총칭했으나, 실제로는 다양한 영역이 있을 수 있습니다. (e.g. 기획, 분석, 상품 개발 등)

마케터는 엔지니어가 택소노미를 설계하기 위해 필요한 정보가 무엇인지 알 수 없습니다.

엔지니어 역시 마케터가 광고 운영 성과를 개선하기 위해 필요한 분석 항목이 무엇인지 알 수 없습니다.

그러므로 최종 대시보드에서 데이터를 마주하게 될 관련 담당자들과 충분한 논의가 이루어져야 합니다. 네이버 시리즈의 경우 사용자가 회원가입 → 쿠키 충전 → 도서 구매 → 도서 열람의 퍼널이 매끄럽게 이어지도록 하는 것이 최종 목표라고 가정합니다. 여기에서 주요 이벤트는 각각 sign_up, charge_cookie, purchase_completed, view_episode가 될 수 있습니다. 이를 파악하기 위해서는 먼저 서비스에 대한 이해가 선행되어야 합니다. 핵심은 양 당사자(사용자와 플랫폼)의 입장을 모두 고려하여 서비스를 이해해야 한다는 점입니다. 첫 미팅 전 웹사이트를 점검하며 어떤 애널리틱스를 사용하고 있는지 확인하고 해당 애널리틱스 구조에 맞게 주요 지표들을 스케치해야 합니다.

통상적으로 '구매(purchase)'하는 행위를 최종 전환 기준으로 보기 마련이지만, 전환의 기준은 서비스마다 천차만별입니다. 네이버 시리즈의 경우 실제로 카드에서 결제 내역이 기록되는 시점은 도서를 구매하기 위해 쿠키를 '충전(charge_cookie)'하는 시점이기 때문에 설계자 입장에서는 '결제'를 중점으로 퍼널을 설계할 가능성이 다분합니다. 그러나 마케터 입장에서는 도서 플랫폼 특성상 충전을 하더라도 실제로 도서를 소비하는 행위, 즉 도서를 구매한 뒤 '열람'하지 않는다면 의미가 없을 수 있습니다.

설계자 관점의 최종 퍼널 )

마케터 관점의 최종 퍼널 )

네이버 시리즈의 경우 ‘쿠키 충전, ‘도서 결제’ 후에도 실제로 전자책을 읽는 ‘소비’의 기준까지 있기 때문에 설계자는 어느 지점이 최종 전환의 기준인지, 2개 이상의 전환 기준이 있다면 우선순위는 어떻게 되는지 파악해야 합니다. 예를 들어, 네이버 시리즈의 사용자 입장에서는 '구매 완료(purchase_completed)' 이벤트가 중요할 수 있습니다. 결제가 완료되고 다운로드를 완료한 시점부터 서비스를 이용하고 있다는 인지를 하기 때문입니다. 반면 플랫폼 입장에서는 '도서 열람(view_episode)' 이벤트가 중요할 수 있습니다. 구매(purchase_completed)를 하더라도 실제로 상품(도서)을 소비(열람) 하지 않으면 ‘도서를 읽은 사람’이 아니라 단순히 ‘도서를 구매만 한 사람’이기 때문입니다. 그러나 이 두 경우 모두 동일하게 최종 구매 완료(purchase_completed) 이벤트로 카운트되기 때문에 플랫폼 입장에서는 purchase_completed 뿐만 아니라, 실제로 도서를 열람하는 view_episode까지의 퍼널이 필요합니다.

*도서 구독 플랫폼의 경우 도서를 ‘대여(혹은 소장)’하는 특정 횟수를 기준으로 출판사와 일정 비율 배분하여 정산하는 수익 구조라 다소 복잡한 부분이 있습니다. 만약 도서를 15회 대여 시 네이버 시리즈 측에서 80%의 수익을 창출할 수 있는 구조라고 가정했을 때, 충전을 하더라도 실제로 도서를 구매하고 열람하지 않으면 출판사 측과의 정산 기준을 충족하지 않기 때문에 충전 자체만으로는 의미가 없게 됩니다. 또한 구매 횟수를 기준으로 카운트되기 때문에, 한 사용자가 각종 도서를 15회 다운로드 하더라도 실제로 열람하지 않으면 출판사(혹은 작가) 입장에서의 판매 관점에서는 이 역시 의미가 없습니다.

이렇듯 데이터를 바라보는 관점은 직무에 따라, 혹은 서비스 행태에 따라 모두 상이합니다. 따라서 가급적 제품이나 서비스에 대한 이해가 최우선 되어야 하고, 꼬리 질문을 통해 담당자 측으로부터 분석하고자 하는 지표에 대한 정보를 최대한 이끌어내어 이러한 간극을 좁혀나가는 것이 중요합니다.

개발 관점

마케터와 충분한 논의가 되었다면 개발 관점에서는 실제로 추적 가능한 데이터인지, 혹은 표현 가능한 데이터 형태인지를 판단해야 합니다. (*개발 관점에서의 택소노미 설계 방안은 다음 글에서 상세히 다룰 예정입니다) 만일 마케터의 관점만을 중점으로 택소노미를 설계한다면 추후 설계안 전체를 뒤엎어야 할 수도 있습니다.

- 마케터: "A 데이터와 B 데이터가 필요합니다."

- 엔지니어: "A, B 데이터 기반으로 택소노미 설계 완료되었습니다."

- 개발자: "택소노미상의 로직은 구현이 불가합니다."

이례적인 경우이긴 하나, 위와 같은 극단적인 상황이 닥치면 완전히 다른 형태의 택소노미를 처음부터 다시 설계해야 할 수도 있습니다. 따라서 택소노미를 설계하기 전 어떠한 분석 툴을 사용하고 있으며, 어떠한 지표들을 추적할 수 있는지에 대한 개발팀과의 커뮤니케이션 역시 매우 중요합니다.

2. 주요 지표(이벤트 카테고리) 설정

이벤트 카테고리를 설정하기 위해 서비스의 유저 플로우를 상상하며 아이데이션을 진행합니다. 서비스에 대한 시장 조사를 통해 이용자의 특성을 고려하여 실제 사용자 관점에서 퍼널에 유입되어 보기도 합니다. 일반적인 주요 지표로는 '회원가입(sign_up)', 장바구니 담기(add_to_cart)', '구매(purchase)'가 있으며, 이는 서비스마다 매우 다양하게 분류될 수 있습니다. 네이버 시리즈의 경우 '쿠키 충전(charge_cookie), '도서 다운로드(download_book)', '도서 열람(view_book)'의 추가적인 주요 지표가 있을 수 있습니다. 각각의 주요 지표들은 2-3가지를 하나의 카테고리로 묶을 수도 있고, 각각의 퍼널로 분류할 수도 있습니다.

[이벤트 카테고리 분류 예시]

Case.1 ) 모두 각각의 퍼널로 분류

Case.2 ) 장바구니와 구매 퍼널 병합

Case.3 ) 충전과 구매 퍼널 병합

Case.4 ) 장바구니, 충전, 구매 퍼널 병합

Case.5 ) 모든 퍼널 병합

이외에도 매우 다양한 경우의 수가 존재합니다. 다만 다섯 번째 케이스와 같이 하나의 퍼널에 모든 주요 카테고리를 연결하여 설계하게 되면 택소노미의 가독성이 현저히 떨어질 수 있어 권장하지는 않습니다.

첫 미팅 전 인터뷰 질문을 사전 공유하여 답변을 미리 생각할 수 있도록 하는 것도 좋은 방법입니다. 특히 이미 론칭된 기존 서비스의 경우 접속에 제한이 없기 때문에 정보를 습득하기 수월하지만, 론칭 전 신규 서비스의 경우 내부 보안 문제로 접속이 불가하여 미팅 전 사전 자료 조사가 어려운 경우 사전 인터뷰지를 작성하는 것은 더욱 유용합니다. 인터뷰 질문의 경우 앞서 미팅 전 가정했던 주요 지표들을 기반으로 작성한다거나, 홈페이지의 UI/UX상으로는 명확히 파악하기 어려운 사항들을 리스트업 하고, 론칭 전 서비스의 경우 자사의 기존(과거) 서비스를 참고하거나, 경쟁사의 레퍼런스를 참고하여 설문지를 작성하는 것도 하나의 방법입니다. 이때 각 질문들은 가능한 구체적으로 풀어 작성하는 것이 중요합니다.

[인터뷰 질문 유형 예시]

유형 1 ) 자사 내부의 주요 지표

유형 2 ) 지표별 데이터의 집계 기준

유형 3 ) 데이터 분석의 성공/실패 사례

유형 4) 기존(혹은 현재)의 최종 KPI

유형 5) 서비스 특성

유형 6 ) 서비스 기능

유형 7 ) UI/UX상 주요한 부분

유형 8 ) 사용자 분류 기준

유형 9 ) 택소노미로부터 얻고 싶은 분석 데이터

유형 10 ) 서비스 기능상의 추가 개발 계획 여부

*사전 인터뷰 설문지 예시

3. 사용자 여정(User flow) 스케치

마케팅과 개발 모두의 관점에서 택소노미의 목적과 방향성을 분명히 하고 사전 자료 조사에 따라 인터뷰를 원활히 진행하여 택소노미의 뼈대를 완성했다면, 이제 설계에 돌입하여 주요 지표 사이 사이에 살을 붙여야 합니다. 예를 들어 '회원가입 완료(sign_up)'를 위해서는 회원가입 페이지에 진입하여 회원가입 시작을 클릭하고, 사용자 정보를 입력하여 최종적으로 회원가입 완료하기 버튼을 클릭하면 회원가입의 퍼널이 완성됩니다. 이러한 유저 플로우의 간략한 아키텍처를 스케치해 두면 추후 택소노미를 구체화하기가 훨씬 수월합니다.