이벤트 택소노미 완벽 설계하기⑵ (ft.네이버 시리즈)
비용 최적화된 이벤트 택소노미 설계하기
이벤트 택소노미 초기 설계 시, 어디에서부터, 무엇을, 어떻게 시작해야 할지 막막한 어려움을 조금이나마 해소해 드리고자, 밀리의 서재 · 버거킹 · 무신사 · 한샘 · 웍스아웃 · 발란 · KFC · 두나무 · 오늘의 집 등의 고객사들과 실제 프로젝트를 진행하며 얻은 인사이트를 공유드립니다.
2편에서는 <비용 최적화된 이벤트 택소노미를 설계하는 방법>을 상세히 다룹니다.
*보안상의 이유로 자료는 <네이버 시리즈>로 대체하였으며, 실제 데이터와는 무관한 자료임을 재차 고지드립니다.
지난 글에서는 앞선 세 가지 단계를 통해 이벤트 택소노미의 정의와 설계 전 필독 유의사항을 살펴보았습니다.
본 글에서는 비용 최적화된 이벤트 택소노미를 설계하는 방법과 담당자 간 커뮤니케이션 단계를 다룰 예정입니다. 이벤트와 프로퍼티를 설계하는 단계부터는 단순히 내용과 방법을 나열하기보다, 실제 설계 사례를 중심으로 풀어보려 합니다.
비용 최적화된 이벤트 택소노미 설계하기
"이벤트 택소노미 설계 전 반드시 고려해야 할 필수 요소, 네이밍 컨벤션"
"1-2-3 퍼널에서 2 퍼널이 필요한가? Critical Path에 따른 필수 이벤트 설계하기"
"View와 Click 이벤트가 동시에 추적해야 하는 경우"
"'구매(purchase)' 이벤트가 '무료'와 '유료'로 나뉘는 경우"
"개발자가 한 번에 알아보는 '이벤트 택소노미 시트'"
"전략에 녹일 수 없는 방대한 데이터는 묶음 처리"
4. 이벤트 & 프로퍼티 설계
많은 분들이 이벤트를 설계하고 난 다음 프로퍼티를 설계하는 순서로 이해하고 계시지만, 실제로 이벤트와 프로퍼티를 동시에 고려해야 하는 경우가 많습니다. 그러므로 본 글에서는 이벤트와 프로퍼티를 구분하지 않고 실제 현업에서 발생할 만한 택소노미 설계상 주요 이슈를 주제화하여 소개합니다.
이벤트 택소노미 설계 전 반드시 고려해야 할 필수 요소, 네이밍 컨벤션
*네이밍 컨벤션(Naming Convention)이란? 하나 이상의 영어 단어로 구성된 식별자를 만들 때 가독성이 좋도록 한눈에 구분하기 위해 규정한 명명 규칙
이벤트 택소노미 설계 시 네이밍 컨벤셔닝은 선택이 아닌 필수입니다. 이벤트와 각 프로퍼티를 정의할 때는 명확하고 일관된 명명법을 사용해야 하며, 사용자 행동을 명확하고 구체적으로 표현해야 합니다. '어느 누가 보아도 유추할 수 있는' 규칙을 지정해야 추후 개발과 분석에 혼동이 없습니다. 네이밍 컨벤션의 정의와 종류를 참고하여 담당자 간 규칙을 합의할 수 있습니다. 다양한 방법이 있지만 저는 주로 스네이크 표기법을 통해 소문자와 언더바(_)를 조합하여 이벤트와 프로퍼티명을 정의합니다.
좌측의 네이밍 컨벤션을 적용하지 않은 경우 'first_login'이 '로그인 페이지 조회'인지, 페이지 내의 '로그인 버튼 클릭'인지 구별이 어렵습니다. 반면 우측의 네이밍 컨벤션을 적용한 경우 가장 앞단에 행동 조건(trigger)과 이벤트명, 그리고 추가 정보까지 규칙적으로 정의되어 있어 비교적 구별하기가 수월합니다.
** 스크롤 내리기 전 준비사항 **
본격적인 설계 과정을 정독하기 전 아래의 '구매 퍼널'에 본인만의 네이밍 컨벤션을 적용한 이벤트와 각 프로퍼티를 직접 정의해 보시길 바랍니다.
*네이버 시리즈 구매 퍼널 예시이벤트 택소노미를 설계하는 과정에서 중요한 것은 '생각하는 방법'과 '반복된 경험'입니다. 다양한 설계 방안들을 반복하여 구상하다 보면 향후 좋은 방안들만 솎아낼 수 있는 경험치가 쌓여 나만의 노하우를 형성할 수 있습니다. 이미 설계된 택소노미를 먼저 접하게 되면 추후 스스로 생각을 떠올리기가 어렵습니다. 누군가의 '완성된 결과물' 보다, '완성하는 과정'을 함께하셨으면 합니다.
끊임없이 질문하고 끊임없이 생각하며 끊임없는 연결 고리를 찾아야 합니다.
- 어떻게 해야 분석에 특화된 택소노미를 설계할 수 있을까?
- 어떻게 해야 개발 편의적인 택소노미를 설계할 수 있을까?
- 어떻게 해야 지속적이고 확장 가능한 택소노미를 설계할 수 있을까?
- 어떻게 해야 모든 요구사항을 충족하되 깔끔한 택소노미를 설계할 수 있을까?
- 각 주요 퍼널들을 어떻게 분류하고 조합해야 비즈니스 KPI에 적합한 택소노미를 설계할 수 있을까?
1-2-3 퍼널에서 2 퍼널이 필요한가? Critical Path에 따른 필수 이벤트 설계하기
네이밍 컨벤션을 정의하고 나면 전체 이벤트와 프로퍼티들을 설계해야 합니다. 이전에 정의했던 주요 이벤트를 기반으로 사용자의 여정을 그려봅니다. 이때 모든 이벤트는 중대한 경로(critical path)로 설계되어야 합니다. 즉 최종 전환 이벤트에 도달하는 퍼널이 반드시 필요한 이벤트로만 구성되어야 함을 의미합니다. 택소노미가 복잡해질수록 가독성이 떨어지고 이에 따라 보완 및 개선 작업이 까다로워질 수 있기 때문에 카테고리를 적절히 분류하는 것이 좋습니다. 아래 이미지는 '결제 완료' 카테고리를 기준으로 사용자가 자사 홈페이지에 진입하는 시점부터 결제를 완료하는 시점까지의 퍼널을 그린 예시입니다.
간소화 전위 간소화 전 퍼널을 살펴보면 메인 페이지 내에 도서 상세 페이지까지 진입할 수 있는 경로가 다양합니다. 메인 페이지에서 개별 도서를 클릭하여 도서 상세 페이지로 곧바로 이동할 수도 있고, 'ㅇㅇ님이 좋아할 만한 작품', 혹은 '이번주 베스트셀러'와 같은 특정 카테고리 경로를 거친 후에 상세 페이지로 이동할 수도 있습니다. 그러나 이처럼 다양한 경우의 수를 각각의 이벤트로 설계하게 되면 효율성이 떨어지게 됩니다. 사용자가 메인 홈페이지에서 곧바로 개별 도서 클릭 시 'click_item_list'와 'click_item'의 클릭 이벤트가 동시 발생하게 되며, 이때 ‘click_item_list' 이벤트는 'null' 값으로만 채워지기 때문입니다.
또한 도서 클릭 시 'click_item'과 'view_item'이 동시 발생하는 것을 볼 수 있는데, 마케터가 클릭 관련 성과를 분석하고자 하는 특정 페이지가 도서의 상세 페이지라면 그 외 페이지, 즉 메인 홈페이지에서 모든 클릭을 추적할 필요는 없습니다. 만일 모든 페이지의 이벤트를 조회와 클릭 이벤트로 동시 설계한다면 이벤트 발생 시마다 유사 이벤트가 중복 발생하므로 이 또한 매우 비효율적이게 됩니다. 모든 경로를 이벤트로 설계하기보다 프로퍼티를 이용하여 경로를 간소화하는 것이 비교적 효율적입니다. 아래 이미지는 '도서 카테고리(item_list)'와 '개별 도서(item)' 프로퍼티를 구분하여 이벤트를 간소화한 예시입니다.
간소화 후위 간소화된 퍼널을 기반으로, '메인 홈페이지' 진입 > '베스트랭킹' 카테고리 클릭 > '특정 상품' 클릭의 상황을 가정한다면, 아래 이미지와 같이 'click_item_list', 'click_item' 이벤트 없이도 프로퍼티를 통해 중간 경로값을 얻을 수 있습니다.
View와 Click 이벤트가 동시에 추적해야 하는 경우
특정 프로모션 페이지 내에 '신작 첫 화 무료보기' 혹은 유료 광고의 '더 알아보기 버튼 클릭' 등 다양한 유입이 있을 수 있습니다. 이러한 경우 페이지 상의 유입 경로를 분석해야 하기 때문에 '조회'를 기준으로 추적합니다. 한편 클릭 혹은 스크롤 뎁스와 같이 특정 페이지에 한정하여 분석이 필요한 경우에는 페이지 내의 ‘액션‘을 기준으로 추적합니다.
네이버 시리즈의 도서 상세 페이지의 경우 view와 click이 동시에 필요합니다. 예를 들어 특정 도서의 상세 페이지 내에 '무료로 첫화보기' 혹은 '다음화 이어보기' 등의 버튼과 같이 결정적인 클릭 요소가 있는 동시에 신작 홍보 이벤트나 기간 한정 프로모션을 통한 유입 경로가 다양할 수 있습니다. 이러한 경우가 '조회'와 '클릭'을 동시 추적해야 하는 경우라고 볼 수 있습니다.
'구매(purchase)' 이벤트가 '무료'와 '유료'로 나뉘는 경우
지금까지 도서의 상세 페이지로 진입하여 충전과 구매가 이루어지는 단일 퍼널에 대해 살펴보았습니다. 그러나 일반적으로 단일 퍼널만으로 구성되는 경우는 드물며, 전환의 기준 또한 다양합니다. 도서 플랫폼의 경우 1화, 2화, 3화, ...로 이어지는 연재본이 있는 반면, 연재본의 묶음 단위인 단행본이 있습니다. 각각의 도서 유형 모두 '무료(혹은 미리보기)'의 개념이 있으며, 마케터는 무료와 유료 구매의 모든 경우를 분석하길 희망한다고 가정합니다. 이때 매우 다양한 경우의 수를 고려해 볼 수 있습니다.
무료 회차를 열람하는 경우
유료 회차를 열람하는 경우
무료 회차를 열람한 후 유료 회차로 넘어가는 경우
유료 회차를 열람한 후 상세 페이지에서 이전 페이지로 넘어가는 경우
유료 회차를 열람한 후 상세 페이지에서 다음 페이지로 넘어가는 경우
무료 회차를 열람한 후 다시 다른 무료 회차를 열람하는 경우
아래는 특정 도서의 상세 페이지에서 '무료' 전환과 '유료' 전환을 프로퍼티로 나눈 예시입니다. 사용자가 'click_episode'를 발생시킬 시 'item_preview'가 True(무료 회차)인 경우 즉시 도서 열람 페이지로, False(유료 회차)인 경우 구매 결정(click_purchase) 페이지로 이동하게 됩니다. 단, 유료 회차이지만 해당 회차를 이미 구매한 경우 무료 회차와 동일하게 즉시 열람 페이지로 이동합니다.
이처럼 프로퍼티를 잘 활용하면 택소노미의 설계를 간소화할 수 있습니다.
개발자가 한 번에 알아보는 '이벤트 택소노미 시트'
마케터와 마찬가지로 개발자 역시 마케터와 설계자의 관점을 알지 못하기 때문에 개발자 편의적인 택소노미(Dev. Sheet)를 별도로 작성하여 전달하여야 하며, 이러한 세부 자료를 전달함과 동시에 충분한 구두 설명이 뒷받침되어야 합니다. 네이버 시리즈 웹/앱 내에서 사용자가 상호작용을 일으키면 개발자는 설계자가 요청한 정보(미리 정의해 둔 이벤트나 프로퍼티)들을 데이터 레이어 형태로 푸시해 줍니다. 그러면 우리는 디버깅을 통해 요청한 데이터가 올바르게 푸시되는지 실시간 로그로 확인할 수 있습니다. 데이터 레이어란 웹사이트에서 정보를 담고 있는 자바스크립트 배열입니다. 쉽게 말해, '데이터 송수신을 하기 위한 매개체'로, 백단에서 특정 이벤트 데이터를 푸시(push)하면 디버깅 시 프론트에서 확인 가능한 형태로 전달받는 식입니다. 일반적으로 속성(key)과 속성값(value)이 아래와 같은 형태로 구성되어 전달됩니다. *빠른 이해를 돕기 위해 최소한의 단계로 표현한 점 참고 부탁드립니다.
*이벤트 전송 과정의 예시
*파이어베이스의 디버깅 예시이때, 클릭(click) 또는 조회(page_view)와 같은 일반적인 이벤트 외에 모든 In-web/app 이벤트의 하위 속성으로 호출되는 사용자 속성(user property)이나, 특정 데이터 타입(data type), 혹은 자료 구조(data structure hierarchy)가 통일되지 않고 다양할 경우 택소노미 설계 시 별도로 명시해 주는 것이 좋습니다. (e.g. value 외 array 혹은 float 등 다양한 형태의 프로퍼티가 존재하는 경우)
*프로퍼티 정보 입력 예시이전 글에서 언급했듯 이벤트 택소노미를 설계할 때는 마케팅 관점과 개발 관점을 별도로 이해하고 적용해야 합니다. 예를 들어, 마케터에게는 유저 플로우를 이해하는 데 초점을 맞춘 시각화된 자료(피그마 등)를 제공하되, 개발자에게는 데이터 로그를 이해하는 데 도움될 만한 정리된 자료를 제공합니다. 이때 시트의 유형은 이벤트 프로퍼티(Event Property)와 유저 프로퍼티(User Property) 두 가지로 분류됩니다.
*Event Property란? 이벤트가 수집되는 시점의 이벤트에 대한 자세한 속성 정보
*User Property란? 유저의 속성 정보로 서비스를 사용하는 각 개인의 특성을 반영하여 보다 세분화된 수준에서 유저 분석에 도움을 주는 정보
e.g. "'2024-01-01' 일자에 '홍길동' 사용자가 '회원가입'을 완료했습니다."
- Event: '회원가입'
- Event Property: '2024-01-01'
- User Property: '홍길동'
*개발팀 전달용 택소노미 시트(Event Property)
*개발팀 전달용 택소노미 시트(User Property)각 시트 내에는 아래와 같은 항목들이 포함됩니다. 필수 항목은 아니며, 자사의 서비스 특성을 고려하여 필요한 항목으로 구성할 수 있습니다.
[Columns of Event Propery Sheet]
No: 행 번호
Label: 이벤트 카테고리
Event Name: 이벤트 이름
Trigger: 이벤트 조건(행동 조건)
Required: 필수 개발 여부
Importance: 우선 순위(중요도)
GA4 Event: GA4 전자상거래 이벤트
Event Property: 이벤트 프로퍼티 이름
Description: 프로퍼티 설명
Data Type: 데이터 유형
Value Type: 데이터 형태
Value Example: 데이터 예시
Analysis: 분석 방안
Note: 비고(기타 특이사항)
[Columns of User Propery Sheet]
No: 행 번호
Event Property: 이벤트 프로퍼티 이름
Value Type: 데이터 형태
Value Example: 데이터 예시
Analysis: 분석 방안
Note: 비고(기타 특이사항)
*제가 사용했던 택소노미 템플릿 양식은 아래 링크를 통해 다운받으실 수 있습니다. 이외에도 웹사이트 내에 다양한 템플릿이 존재하니 용도에 맞는 템플릿을 적절히 커스텀하여 사용하시길 바랍니다.
개발 지식이 부족하더라도, GA4 기반의 이벤트와 파라미터를 잘 정리해 놓은 자료를 참고하여 약간의 시간만 투자하면 주니어 마케터(혹은 엔지니어 등) 분들께서도 충분히 이와 같은 설계가 가능합니다. 또한 GA를 이용하는 경우가 아니라 하더라도 보편적으로 쓰이는 이벤트와 프로퍼티(해당 페이지에서는 파라미터로 구분됩니다)의 예시를 살펴볼 수 있습니다.
전략에 녹일 수 없는 방대한 데이터는 묶음 처리
택소노미 설계에 참여하는 담당자가 마케터와 개발자, 그리고 설계자 외에도 기획자나 상품 개발팀이 참여한다면 택소노미의 방향성이 현재와는 완전히 달라질 수 있습니다. 마케터가 아닌 기획자나 MD의 입장에서는 UI/UX상의 노출이나 클릭과 같은 단순 행동 추적을 넘어 특정 회차의 반응 정도가 중요할 수 있습니다. 그러나 연재본의 모든 회차를 추적하기란 비용상의 어려움이 있습니다. 아래 이미지와 같이 결정적인 지표의 경우 하나의 페이지를 추적하기 위한 다양한 프로퍼티가 존재하는데, 100화가 넘는 연재본이 무수히 존재하기 때문에 회차를 기준으로 실시간 추적하는 경우 서버 과부하로 비용이 과다하게 발생하여 관리상의 어려움이 있을 수 있습니다.
위 예시에서 수시로 발생하는 이벤트 중 'click_charge_cookie_tried'와 'charge_cookie_completed'와 같이 프로퍼티 데이터의 양이 상당한 경우를 예로 들 수 있습니다. 퍼널을 간소화하거나 프로퍼티를 줄일 수도 없는 상황이라면 최소한 이벤트 발생 횟수를 감소시키는 방안이 있을 수 있습니다. 예를 들어, 연재본을 10화씩 그룹으로 묶어 이벤트 발생횟수를 단축시킴으로써 서버상의 관리가 비교적 원활하게 이루어질 수 있도록 강제하는 방법이 있습니다.
e.g.) 변경 전 택소노미
- 연재 1회차당 1번 기록하는 경우
연재본 100화의 이벤트 발생 수: 100회
연재본 100화의 프로퍼티 적재 수: 150회
연재 100화분의 총 데이터 적재 수: 250회
e.g.) 변경 후 택소노미
- 연재 10회차당 1번 기록하는 경우
연재본 100화분의 이벤트 발생 수: 10회
연재본 100화분의 프로퍼티 적재 수: 15회
연재 100화분의 총 데이터 적재 수: 25회
5. 마케터 협의
택소노미를 지속 수정 및 개선하기 위해 마케터와 정기적인 미팅을 진행합니다. 택소노미상의 모든 이벤트를 실제로 조합하고 분석하며 직접적으로 개입하는 당사자이자 결정권자이기 때문에, 설계의 전/중/후 모든 단계에서 끊임없는 QnA를 진행하게 됩니다. 설계 전 초기에 진행한 사전 인터뷰를 통해 이미 많은 정보를 얻었다고 생각할 수 있지만 더는 구체적일 수 없을 정도로 자세한 정보를 얻어야 합니다. 마케터의 관점을 정확히 파악해야 설계상의 번거로운 수정 작업을 최소화할 수 있습니다. 앞서 언급했듯 담당자 간 의견 차이는 매우 주관적이므로 지속적인 꼬리 질문을 통해 애매한 기준을 제거하는 것이 최선의 방법입니다.
한 가지 좋은 예로, 담당자에게 Daily Check List를 실시간으로 공유하는 방법이 있습니다. 클라이언트 측에서는 택소노미상의 진행 상황과 상세 내용을 실시간으로 확인할 수 있고, 설계자 입장에서는 커뮤니케이션에 소요되는 시간을 절약할 수 있어 효율적입니다.
6. 개발자 협의
1차 설계안에 대한 협의가 완료되었다면 백엔드에서 데이터 작업을 해 줄 개발팀과 협의를 해야 합니다. 이때 1차 설계안은 '대략적으로 설계'하여 이후 개발팀과의 미팅을 통해 택소노미를 구체화하는 것이 좋습니다. 개발자와의 협의 없이 마케터의 모든 요구사항을 즉시 반영하기 위해 한 번에 많은 에너지를 쏟게 되면, 이후 택소노미를 전면 수정하는 참사가 일어날 수 있기 때문입니다.
서비스마다 사용하는 분석 도구(analytics tool)와 데이터 구조가 저마다 상이하기 때문에 이를 먼저 파악해야 합니다. 일반적으로 타사(구글 애널리틱스, MMP 등) 애널리틱스를 사용하거나, 자사 자체 구축 애널리틱스를 사용하는 경우로 나뉘는데, 두 가지를 병용하는 경우도 다분합니다. 예를 들어, 자사 애널리틱스의 로그 이용 시 경로 추적에 한계가 있기 때문에 이에 최적화되어 있는 GA4와 병용하는 경우를 흔히 볼 수 있습니다. *GA4와 GTM을 사용한다면 [구글 애널리틱스] 데이터 레이어 (Data Layer) 총 정리 (1) 내용을 참고 바랍니다.
자사 자체 애널리틱스의 경우 개발상에 제약이 거의 없기 때문에 내부 개발 리소스만 충분하다면 설계와 분석이 매우 수월합니다. 단, 개발자에게 보다 명료한 자료를 제공해야 개발자와의 커뮤니케이션 오류를 최소화할 수 있습니다.
[택소노미 설계 시 사용 플랫폼]
- 피그마(Figma)
- 구글 스프레드시트(Google Spreadsheet)
다음 글에서는 QA를 통해 발생 가능한 개발상의 이슈와 이를 통해 얻을 수 있는 인사이트를 공유드릴 예정입니다.
풀스택 마케팅 컨설팅 펌, 마티니아이오
