August 26, 2024
에어브릿지(Airbridge)는 데이터 수집부터 마케팅 성과 분석까지 하나의 대시보드에서 진행하는 마케팅 성과 분석 솔루션(MMP)으로, 라스트 터치 어트리뷰션, 멀티 터치 어트리뷰션, 마케팅 믹스 모델링 등 다양한 방법으로 앱과 웹사이트의 마케팅 성과를 함께 분석할 수 있는 통합 마테크 솔루션입니다.
오늘날 MMP 솔루션은 광고주들에게 필수적으로 사용되고 있습니다. 에어브릿지 역시 그 중 하나로, 별도의 연동 없이 통합된 데이터 분석과 어트리뷰션이 가능한 것이 강점입니다.
에어브릿지의 이벤트 구조는 타 플랫폼에 비해 비교적 복잡하기 때문에 이전에 GA4 및 타 분석 솔루션만을 사용하다 에어브릿지를 처음 접했다면 다소 혼란스러울 수 있습니다. 저 역시 꽤 헤맸던 것 같습니다.
이러한 계기로 에어브릿지 택소노미를 설계할 당시 이벤트 구조를 이해하는 데 실제로 도움이 됐던 자료들과 GA4의 구조를 비교하여 전체적인 구조를 설명드리고자 합니다.
ㅡ
에어브릿지의 이벤트 및 어트리뷰트 호출 코드의 작성 방법은 아래 세 가지 경로를 통해 확인하실 수 있습니다.
1. 에어브릿지 유저 가이드(Airbridge Help Center)
유저 가이드를 통해서도 코드를 작성하는 데에는 문제가 없지만 2번 자료의 코드 구조가 비교적 효율적이므로 가급적 2번 자료를 참고하시는 것을 권장드립니다.
2. AB180 깃허브(Github)
1번 유저 가이드의 코드 예시 보다 더욱 상세한 전체 코드를 확인하실 수 있습니다.
3. 유저 가이드 및 에어브릿지 공식 문서(Data Spec)
에어브릿지에서 제공하는 Event와 Attribute의 목록과 상세 정보들을 확인하실 수 있습니다.
에어브릿지 이벤트 구성 요소에는 카테고리(Event Category), 액션(Event Action), 라벨(Event Label), 밸류(Event Value), 어트리뷰트(Attribute), 트리거(Trigger)가 있습니다.
다소 복잡해 보이지만 조금만 들여다보면 이해하기 쉽습니다.
위 이벤트 구성 요소의 개념들이 조금 생소하신 분들은 GA4의 예시로 보면 이해하기 쉽습니다.
(GA4의 Metrics & Dimension에 대한 기본 개념이 궁금하신 분들은 관련 자료를 참고해 주세요)
- GA4 보고서
- Airbridge 보고서
GA4의 측정기준(Dimensions)이 에어브릿지의 카테고리, 액션, 라벨의 역할을 하고,
측정항목(Metrics)이 에어브릿지의 밸류의 역할을 한다고 비교해 볼 수 있습니다.
예를 들어, 의류를 판매하는 모 기업의 마케팅 담당자가 구매 이벤트 발생 시 아래와 같은 항목들의 데이터를 수집한다고 가정합니다.
Purchase
모두 시맨틱 어트리뷰트로 수집 가능한 항목들이지만 어트리뷰트의 경우 에어브릿지 리포트에서 확인할 수 없기 때문에 CDP와 같은 고객DB에 접근하거나 별도의 솔루션으로 전처리하여 확인해야 합니다. 이런 경우 유용하게 쓰일 수 있는 항목이 액션과 라벨입니다.
만일 자주 사용하는 어트리뷰트 항목을 에어브릿지의 리포트와 대시보드에서 활용하고자 한다면 어트리뷰트 항목을 액션과 라벨에 세팅하여 어트리뷰트에 대한 데이터를 리포트에서도 확인할 수 있습니다.
다시 말해, 1개의 카테고리와 2개의 어트리뷰트(액션, 라벨)에 대한 통계를 에어브릿지의 리포트와 대시보드에서 쉽고 빠르게 확인할 수 있습니다.
아래 이미지는 스탠다드 이벤트 중에서 일정 예약 이벤트(airbridge.subscribe)의 예시입니다. 일정을 예약한 지역은 액션 또는 라벨로 수집할 수 있으며, 시맨틱 어트리뷰트를 활용하면 예약한 ID(scheduleID)와 예약일시(datetime)를 수집할 수 있습니다.
밸류는 에어브릿지 이벤트가 수집한 숫자를 계산에 이용하기 위해서 선택해야 하는 구성요소입니다. 에어브릿지 이벤트의 밸류로 수집된 숫자만 계산에 이용할 수 있습니다. 밸류로 소수점 9자리 이하 숫자까지 수집할 수 있습니다.
예를 들어, 레비뉴 리포트(Revenue Report)에서 판매한 제품의 가격을 더해 전체 판매 가격을 계산하거나 디지털 서비스의 구독료를 전부 합해서 전체 구독료를 확인하기 위해서는 밸류를 반드시 이벤트 구성요소로 사용해야 합니다.
또한, 밸류로 수집된 데이터는 밸류로 수집된 다른 데이터와 계산할 수 있습니다. 액션이나 라벨로 수집된 데이터는 계산에 활용할 수 없습니다. 그러나 이벤트 발생 횟수는 밸류 사용 여부와 상관없이 확인할 수 있습니다.
예시) 구매 완료 이벤트
위 예시와 같이 액션과 라벨, 밸류 모두 숫자로 수집한다고 하더라도 밸류로 수집한 데이터만 계산할 수 있으며, 액션과 라벨로 수집한 데이터는 계산할 수 없습니다. 예시에서는 구매 완료 이벤트의 밸류로 수집한 데이터를 더해서 30,000이라는 수치를 얻을 수 있습니다.
매출 관련 데이터는 속성으로 수집하는 것이 일반적이나, 에어브릿지의 경우에는 Attribute가 아닌 Value로 수집합니다. 즉 밸류에는 보통 구매액이 들어가고, 어트리뷰트에서는 기타 정보들을 수집합니다.
Semantic Attribute로 사용할 수도 있지만, Actuals Report나 Revenue Report에서는 이벤트 밸류에 Semantic Attribute의 isRevenue 값을 True로 설정한 카테고리(이벤트)로부터 발생한 매출액(Value 값)을 기준으로 확인하기 때문에 이는 적절하지 않습니다. (설정 가능한 Revenue 이벤트 수: 최대 5개)
Revenue 이벤트를 설정할 때 한 가지 유의할 점은 Revenue의 구조가 다양한 서비스일 경우(전환 포인트: 포인트 충전, 제품 결제, 광고 충전 포인트 등), Revenue Report에서 확인할 최종 전환 기준 한 가지를 선정하셔야 합니다.
만일 아래와 같이 구매 완료 시 2개의 매출 관련 이벤트가 동시에 호출되고 2개의 이벤트 모두 Revenue 이벤트로 설정한 경우 중복집계가 될 수 있기 때문입니다.
예시)
- 주문 완료 이벤트 발생 시 단위별 이벤트 동시 호출
매출액 집계 기준을 제품 단위로 볼지, 주문서 단위로 볼지 결정하고 결정된 하나의 카테고리(이벤트)에 isRevenue를 세팅해야 중복집계를 방지할 수 있습니다.
따라서 Revenue로 집계할 이벤트와 기타 매출 관련 데이터를 집계해야 하는 이벤트를 별도로 관리하시는 것을 권장드립니다.
각 카테고리(이벤트)에는 다양한 속성 정보가 수집되는데, 플랫폼마다 정의하는 '속성명'이 상이합니다. GA의 경우 Parameter, 에어브릿지의 경우 Attribute로 정의합니다. 이벤트(카테고리)명 역시 GA4의 경우 Event, 에어브릿지의 경우 Standard Event라고 정의합니다. 각 플랫폼별로 기본적으로 제공되는 속성들이 있으며, 에어브릿지의 경우 Data Spec에서 확인이 가능합니다.
Airbridge Event
Airbridge Attribute
따라서 데이터의 수집 구조를 충분히 고려하여 분석 환경을 구축해 놓는 것이 좋습니다.
July 3, 2024
본업이 그로스마케터이므로... '그로스마케팅'와 관련된 포스팅을 지속적으로 작성하고 있는데요. 관련 키워드로 '패션마케팅'이 검색량이 높아 무신사, 29CM, W컨셉을 사례로 준비해 보았습니다. (좀 더 알아보니 패션마케팅은 대학교 학과가 있어 입시생들의 검색량이 높은 키워드인 듯은 하네요.)
무신사의 브랜드마케터 채용 공고를 먼저 보겠습니다.
cf. https://brunch.co.kr/@marketer-emje/13
퍼포먼스마케팅에서 배너 광고를 운영할 때 그 소재로 브랜드가 강조될 수 있고, 프로모션이 강조될 수도 있고, 인플루언서가 강조될 수도 있고 메인 콘셉트를 무엇으로 하느냐에 따라서 소재 베리에이션은 다채로울 수 있는데요. 예시와 함께 보겠습니다.
페이스북 광고 라이브러리에서 'WConcept'을 검색했을 때 결과 중 일부를 가져왔는데요.
W컨셉에서 W컨셉 페이지로 랜딩 시키는 것은 당연한데, W컨셉에 입점해있는 '브랜드'들이 광고의 랜딩을 랜딩을 W컨셉으로 보내네요!
소규모 브랜드라면 개별 웹사이트를 관리, 운영하는 것보다 수수료를 감안하더라도 의류 플랫폼(W컨셉 등)에서의 매출을 높이는 것이 더 낫다고 판단했다고 추측할 수 있습니다.
신규 가입과 앱 첫 구매의 내용이 담겼다는 것은 해당 광고의 세팅이 '리타겟팅'이 아닐 것이라 추측할 수 있습니다. 아마 성별만 '남성'으로 지정하고 오픈 타겟으로 열지 않았을까 싶네요. 디타겟팅(=타겟에서 제외하는 것)으로 이미 회원인 분들과 앱이 있는 분들을 타겟에서 제외하고요.
해당 업무는 일반적인 퍼포먼스마케터/그로스마케터가 진행하기보다는 무신사의 예시처럼 '인플루언서 마케터'의 직무가 따로 있는 경우가 많습니다.
인스타그래머라면 피드, 스토리의 이미지/워딩 그리고 유튜버라면 유튜브 구성안과 기획안을 검토하면서 논의를 이어가게 됩니다. 일정, 비용, 스토리라인, 강조되어야 하는 점, 해시태그 등을 이야기하고요.
하단 예시처럼 유상 광고 소재(인스타그램 광고 소재)로 인플루언서의 이미지를 활용하는 경우 추가 협의가 필요합니다.
새로운 회원들을 어느 정도 유치했다면, 그 회원들을 계속해서 유지하는 것이 관건이겠죠. 리텐션(=재방문율/재구매율)이 그 지표가 되는데요. 리텐션의 기본으로 여겨지는 것 중 하나가 멤버십입니다.
W컨셉은 5개의 멤버십 등급을 가지고 있고, 그 기준으로는 누적 구매액과 함께 구매'수량'을 같이 보고 있습니다. 해석해 보자면 딱 한 개의 상품만 샀는데 - 그 상품이 100만 원짜리였다 -라고 했을 때 한 번에 VIP로 가는 것을 방지하기 위함이라고 볼 수 있습니다. 한 번 들어와서 비싼 것 한 개 산 사람보다, 여러 번 들어와서 중고가를 여러 개 산 사람이 더 충성도가 높다고 판단하는 것이겠죠?
29CM의 경우 동일한 워딩에 여러 브랜드X상품 이미지를 활용하기 위해 조금 포괄적인 내용을 광고 워딩으로 썼는데요. 29CM의 아이덴티티 + 매월 멤버십 쿠폰 ~15% 혜택을 강조합니다. 여기엔 신규 회원 가입이나 앱 설치 쿠폰이 없는 것을 보아 신규를 대상으로만 하는 광고가 아님을 알 수 있고요.
무신사스탠다드(무신사의 PB브랜드)의 마케팅 팀장 채용 공고에도 '중요 이벤트와 프로모션 지원을 통해' 라는 워딩을 통해 마케팅과 연계된 프로모션의 중요성을 인지할 수 있습니다.
상품 할인과 쿠폰 할인(상품 쿠폰, 장바구니 쿠폰)의 구분은 커머스에서 혜택을 설계할 때나 손익을 계산할 떄 때 그리고 심지어 프로덕트 애널리틱스에서 이벤트/프로퍼티의 택소노미를 설계할 때도 아주 중요한 요소입니다.
앱 설치 쿠폰 및 가입 혜택 프로모션은 Always-on 올웨이즈온 캠페인에 속하고, 홀리데이 프로모션은 팝업/애드훅 캠페인으로 볼 수 있겠죠? (와 쉽다!)
보통 앱 설치, 가입의 경우 장기적인 관점의 KPI 달성을 위해 진행되는 캠페인으로 일간/주간/월간 성과를 지속적으로 모니터링하고요. 팝업/애드훅 캠페인의 경우 정해진 기간 동안 최대 매출 등의 목표치를 달성하는 것이 중요합니다. (무신사의 무진장세일이 매년 역대급 매출을 갱신한다고 하죠...? 그렇지만 무진장 정도면 이제는 정규 캠페인이라고도 볼 수 있겠네요)
CRM 수단으로는 앱 중심의 서비스인 경우 앱푸시, 카카오톡을 위주로 사용하고 웹의 경우 배너/팝업 또한 CRM의 일환으로 볼 수 있겠습니다. 문자 및 이메일은 조금 더 전통적인 수단이겠죠?
CRM 마케팅은 CRM 마케터 직무로도 많이 채용하지만, 그로스마케터의 수행 업무에 수반되는 경우도 꽤 있습니다. 29CM의 그로스 마케터 채용 공고를 보면 '고객 커뮤니케이션 타겟 / 채널 / 메시지 테스트 및 운영' 이라는 워딩을 볼 수 있는데요. 하단처럼 쪼개서 생각할 수 있고, 결국 CRM 마케팅에 대한 내용이라는 것을 알 수 있습니다.
CRM 마케팅이 최근 뜨는 이유는 개인 정보 보호 트렌드 때문인데요. 과거 퍼포먼스마케팅에서는 정교한 타겟팅을 위해 사용자가 웹 내에서 행동했던 것들을 추적하는 (cookie, 쿠키! 한 번쯤은 지워보셨죠?) 것이 중요했는데 이 쿠키 정보의 제공이 중단되면서 일반적인 퍼포먼스마케팅의 효율이 낮아지며 비용이 높아진 것도 일부 원인이 있고요.
상대적으로 CRM은 이미 보유한 회원 모수를 대상으로 메시지를 보내기에, 신규 사용자를 획득하는 것보다 효율이 높고(=비용이 낮고) 운영에 필요한 실 비용이 메시지 발송 비용 정도로 상대적으로 비용이 낮기 때문도 있습니다. CRM마케팅은 기회가 된다면 다음에 좀 더 자세하게 풀어보도록 할게요!
이렇게 패션 플랫폼의 그로스 마케팅 (ft. 무신사, 29CM, W컨셉)을 광고 소재와 채용 공고, 프로덕트를 통해서 Acquisition과 Retention 위주로 알아봤습니다.
[다른 글 보러 가기]
그로스마케팅과 AARRR 퍼널 분석 (ft. 29CM)
https://brunch.co.kr/@marketer-emje/11
그로스마케팅이란? 콘텐츠도 퍼포먼스도 UIUX개선도!
https://brunch.co.kr/@marketer-emje/10
그로스마케팅과 AARRR:Acquisition 획득
https://brunch.co.kr/@marketer-emje/13
풀스택 마케팅 컨설팅펌 마티니아이오
May 31, 2024
이벤트 택소노미 초기 설계 시, 어디에서부터, 무엇을, 어떻게 시작해야 할지 막막한 어려움을 조금이나마 해소해 드리고자, 밀리의 서재 · 버거킹 · 무신사 · 한샘 · 웍스아웃 · 발란 · KFC · 두나무 · 오늘의 집 등의 고객사들과 실제 프로젝트를 진행하며 얻은 인사이트를 공유드립니다.
2편에서는 <비용 최적화된 이벤트 택소노미를 설계하는 방법>을 상세히 다룹니다.
지난 글에서는 앞선 세 가지 단계를 통해 이벤트 택소노미의 정의와 설계 전 필독 유의사항을 살펴보았습니다.
본 글에서는 비용 최적화된 이벤트 택소노미를 설계하는 방법과 담당자 간 커뮤니케이션 단계를 다룰 예정입니다. 이벤트와 프로퍼티를 설계하는 단계부터는 단순히 내용과 방법을 나열하기보다, 실제 설계 사례를 중심으로 풀어보려 합니다.
ㅤ
많은 분들이 이벤트를 설계하고 난 다음 프로퍼티를 설계하는 순서로 이해하고 계시지만, 실제로 이벤트와 프로퍼티를 동시에 고려해야 하는 경우가 많습니다. 그러므로 본 글에서는 이벤트와 프로퍼티를 구분하지 않고 실제 현업에서 발생할 만한 택소노미 설계상 주요 이슈를 주제화하여 소개합니다.
이벤트 택소노미 설계 전 반드시 고려해야 할 필수 요소, 네이밍 컨벤션
ㅤ이벤트 택소노미 설계 시 네이밍 컨벤셔닝은 선택이 아닌 필수입니다. 이벤트와 각 프로퍼티를 정의할 때는 명확하고 일관된 명명법을 사용해야 하며, 사용자 행동을 명확하고 구체적으로 표현해야 합니다. '어느 누가 보아도 유추할 수 있는' 규칙을 지정해야 추후 개발과 분석에 혼동이 없습니다. 네이밍 컨벤션의 정의와 종류를 참고하여 담당자 간 규칙을 합의할 수 있습니다. 다양한 방법이 있지만 저는 주로 스네이크 표기법을 통해 소문자와 언더바(_)를 조합하여 이벤트와 프로퍼티명을 정의합니다.
좌측의 네이밍 컨벤션을 적용하지 않은 경우 'first_login'이 '로그인 페이지 조회'인지, 페이지 내의 '로그인 버튼 클릭'인지 구별이 어렵습니다. 반면 우측의 네이밍 컨벤션을 적용한 경우 가장 앞단에 행동 조건(trigger)과 이벤트명, 그리고 추가 정보까지 규칙적으로 정의되어 있어 비교적 구별하기가 수월합니다.
본격적인 설계 과정을 정독하기 전 아래의 '구매 퍼널'에 본인만의 네이밍 컨벤션을 적용한 이벤트와 각 프로퍼티를 직접 정의해 보시길 바랍니다.
ㅤ이벤트 택소노미를 설계하는 과정에서 중요한 것은 '생각하는 방법'과 '반복된 경험'입니다. 다양한 설계 방안들을 반복하여 구상하다 보면 향후 좋은 방안들만 솎아낼 수 있는 경험치가 쌓여 나만의 노하우를 형성할 수 있습니다. 이미 설계된 택소노미를 먼저 접하게 되면 추후 스스로 생각을 떠올리기가 어렵습니다. 누군가의 '완성된 결과물' 보다, '완성하는 과정'을 함께하셨으면 합니다.
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)가 통일되지 않고 다양할 경우 택소노미 설계 시 별도로 명시해 주는 것이 좋습니다.
ㅤ 이전 글에서 언급했듯 이벤트 택소노미를 설계할 때는 마케팅 관점과 개발 관점을 별도로 이해하고 적용해야 합니다. 예를 들어, 마케터에게는 유저 플로우를 이해하는 데 초점을 맞춘 시각화된 자료(피그마 등)를 제공하되, 개발자에게는 데이터 로그를 이해하는 데 도움될 만한 정리된 자료를 제공합니다. 이때 시트의 유형은 이벤트 프로퍼티(Event Property)와 유저 프로퍼티(User Property) 두 가지로 분류됩니다.
각 시트 내에는 아래와 같은 항목들이 포함됩니다. 필수 항목은 아니며, 자사의 서비스 특성을 고려하여 필요한 항목으로 구성할 수 있습니다.
[Columns of Event Propery Sheet]
[Columns of User Propery Sheet]
*제가 사용했던 택소노미 템플릿 양식은 아래 링크를 통해 다운받으실 수 있습니다. 이외에도 웹사이트 내에 다양한 템플릿이 존재하니 용도에 맞는 템플릿을 적절히 커스텀하여 사용하시길 바랍니다.
▶︎ Event Taxonomy Template (soyun)
ㅤ개발 지식이 부족하더라도, GA4 기반의 이벤트와 파라미터를 잘 정리해 놓은 자료를 참고하여 약간의 시간만 투자하면 주니어 마케터(혹은 엔지니어 등) 분들께서도 충분히 이와 같은 설계가 가능합니다. 또한 GA를 이용하는 경우가 아니라 하더라도 보편적으로 쓰이는 이벤트와 프로퍼티 (해당 페이지에서는 파라미터로 구분됩니다)의 예시를 살펴볼 수 있습니다.
전략에 녹일 수 없는 방대한 데이터는 묶음 처리
ㅤ택소노미 설계에 참여하는 담당자가 마케터와 개발자, 그리고 설계자 외에도 기획자나 상품 개발팀이 참여한다면 택소노미의 방향성이 현재와는 완전히 달라질 수 있습니다. 마케터가 아닌 기획자나 MD의 입장에서는 UI/UX상의 노출이나 클릭과 같은 단순 행동 추적을 넘어 특정 회차의 반응 정도가 중요할 수 있습니다. 그러나 연재본의 모든 회차를 추적하기란 비용상의 어려움이 있습니다. 아래 이미지와 같이 결정적인 지표의 경우 하나의 페이지를 추적하기 위한 다양한 프로퍼티가 존재하는데, 100화가 넘는 연재본이 무수히 존재하기 때문에 회차를 기준으로 실시간 추적하는 경우 서버 과부하로 비용이 과다하게 발생하여 관리상의 어려움이 있을 수 있습니다.
위 예시에서 수시로 발생하는 이벤트 중 'click_charge_cookie_tried'와 'charge_cookie_completed'와 같이 프로퍼티 데이터의 양이 상당한 경우를 예로 들 수 있습니다. 퍼널을 간소화하거나 프로퍼티를 줄일 수도 없는 상황이라면 최소한 이벤트 발생 횟수를 감소시키는 방안이 있을 수 있습니다. 예를 들어, 연재본을 10화씩 그룹으로 묶어 이벤트 발생횟수를 단축시킴으로써 서버상의 관리가 비교적 원활하게 이루어질 수 있도록 강제하는 방법이 있습니다.
- 연재 1회차당 1번 기록하는 경우
- 연재 10회차당 1번 기록하는 경우
ㅤ택소노미를 지속 수정 및 개선하기 위해 마케터와 정기적인 미팅을 진행합니다. 택소노미상의 모든 이벤트를 실제로 조합하고 분석하며 직접적으로 개입하는 당사자이자 결정권자이기 때문에, 설계의 전/중/후 모든 단계에서 끊임없는 QnA를 진행하게 됩니다. 설계 전 초기에 진행한 사전 인터뷰를 통해 이미 많은 정보를 얻었다고 생각할 수 있지만 더는 구체적일 수 없을 정도로 자세한 정보를 얻어야 합니다. 마케터의 관점을 정확히 파악해야 설계상의 번거로운 수정 작업을 최소화할 수 있습니다. 앞서 언급했듯 담당자 간 의견 차이는 매우 주관적이므로 지속적인 꼬리 질문을 통해 애매한 기준을 제거하는 것이 최선의 방법입니다.
ㅤ한 가지 좋은 예로, 담당자에게 Daily Check List를 실시간으로 공유하는 방법이 있습니다. 클라이언트 측에서는 택소노미상의 진행 상황과 상세 내용을 실시간으로 확인할 수 있고, 설계자 입장에서는 커뮤니케이션에 소요되는 시간을 절약할 수 있어 효율적입니다.
ㅤ1차 설계안에 대한 협의가 완료되었다면 백엔드에서 데이터 작업을 해 줄 개발팀과 협의를 해야 합니다. 이때 1차 설계안은 '대략적으로 설계'하여 이후 개발팀과의 미팅을 통해 택소노미를 구체화하는 것이 좋습니다. 개발자와의 협의 없이 마케터의 모든 요구사항을 즉시 반영하기 위해 한 번에 많은 에너지를 쏟게 되면, 이후 택소노미를 전면 수정하는 참사가 일어날 수 있기 때문입니다.
ㅤ 서비스마다 사용하는 분석 도구(analytics tool)와 데이터 구조가 저마다 상이하기 때문에 이를 먼저 파악해야 합니다. 일반적으로 타사(구글 애널리틱스, MMP 등) 애널리틱스를 사용하거나, 자사 자체 구축 애널리틱스를 사용하는 경우로 나뉘는데, 두 가지를 병용하는 경우도 다분합니다. 예를 들어, 자사 애널리틱스의 로그 이용 시 경로 추적에 한계가 있기 때문에 이에 최적화되어 있는 GA4와 병용하는 경우를 흔히 볼 수 있습니다. *GA4와 GTM을 사용한다면 [구글 애널리틱스] 데이터 레이어 (Data Layer) 총 정리 (1) 내용을 참고 바랍니다.
자사 자체 애널리틱스의 경우에는 개발상에 제약이 거의 없기 때문에 내부 개발 리소스만 충분하다면 설계와 분석이 매우 수월합니다. 단, 개발자에게 보다 명료한 자료를 제공해야 개발자와의 커뮤니케이션 오류를 최소화할 수 있습니다.
[택소노미 설계 시 사용 플랫폼]
다음 글에서는 QA를 통해 발생 가능한 개발상의 이슈와 이를 통해 얻을 수 있는 인사이트를 공유드릴 예정입니다.
원본 포스팅 링크
May 30, 2024
이벤트 택소노미 초기 설계 시, 어디에서부터, 무엇을, 어떻게 시작해야 할지 막막한 어려움을 조금이나마 해소해 드리고자, 밀리의 서재 · 버거킹 · 무신사 · 한샘 · 웍스아웃 · 발란 · KFC · 두나무 · 오늘의 집 등의 고객사들과 실제 프로젝트를 진행하며 얻은 인사이트를 공유드리게 되었습니다.
본 1편에서는 <이벤트 택소노미의 정의와 설계 전 필독 유의사항>에 대해 다룹니다.
ㅤ이벤트 택소노미는 크게 '이벤트 유형(Event Category)', '이벤트(Event)', '이벤트 속성(Property)'의 세 가지 항목으로 구성됩니다. '이벤트 카테고리'는 유저의 최종 행동 목적이며, '이벤트'는 이러한 목적을 달성하기 위한 주요 액션들의 묶음입니다. 그리고 각 이벤트 내에는 이벤트 발생 시 ‘추가적으로 수집하고 싶은 정보‘의 '속성'들로 구성됩니다. 이러한 이벤트와 프로퍼티를 특정 규칙에 따라 분류한 데이터 분류 체계를 ‘택소노미(Taxonomy)'라고 부릅니다. 즉, ‘이벤트 택소노미 설계'한다는 것은 자사 서비스 분석에 필요한 이벤트를 식별하고, 이벤트별로 어떤 속성이 들어가야 하는지 고민하여 데이터를 설계하는 작업을 의미합니다. 이를 통해 우리는 사용자의 행동 패턴을 이해하고, 그에 따른 마케팅 전략을 수립할 수 있습니다.
'이벤트 카테고리'란 이벤트의 유형을 정하기 위한 단위로, 유사한 이벤트를 하나로 묶어 관리할 때 유용한 요소입니다.
'이벤트 카테고리'는 주로 최종 전환 이벤트로 정의되어 전환까지의 하나의 퍼널을 총칭합니다.
예를 들어 이벤트 카테고리가 ‘회원가입’인 경우, 이벤트 카테고리 내에는 홈페이지에 접속하여 특정 서비스를 이용하고자 회원가입 버튼을 클릭하여 회원가입 완료 페이지까지 이어지는 퍼널이 포함됩니다.
즉 ’이벤트 카테고리‘ = ‘최종 전환 이벤트의 퍼널’이라고 생각하시면 이해가 수월합니다.
‘이벤트’란 사용자가 프로덕트를 사용하는 과정에서의 행동이나 그 결과로 발생하는 사건을 가리킵니다.
예를 들어, '로그인 버튼 클릭', ‘관심상품 추가', ‘장바구니 담기', ‘구매 완료' 등과 같은 일련의 사용자 행동이 이에 해당하며, 그 외에 ‘주문서 로딩 시간’, ‘서버 API 처리 시간’ 등도 이벤트로 볼 수 있습니다.
프로퍼티란, 웹 문서의 동적인 객체 속성을 의미합니다.
쉽게 말해, 사용자나 이벤트가 가진 동적인 특성을 의미하며 사용자 행동에 대한 세부 분석을 위해 이벤트와 함께 수집됩니다.
예를 들어, '회원가입일자', '회원가입 방법', '회원가입 페이지 유입 경로' 등의 속성값이 이에 해당합니다.
아래의 그림은 오프라인에서 우리의 행동을 온라인에서 발생하는 이벤트로 전환하여 표현했을 때 어떻게 정리할 수 있는지 보여주는 표입니다. 이를 통해 우리는 이벤트와 속성 간의 차이를 확인할 수 있습니다.
1. 택소노미의 목적 및 방향성 수립
2. 주요 지표(이벤트 카테고리) 설정
3. 사용자 여정(User flow) 스케치
4. 이벤트 & 프로퍼티 설계
5. 마케터 협의
6. 개발자 협의
7. QA 테스트
8. 최종 수정
본 글에서는 1번(이벤트 택소노미의 목적 및 방향성 수립)부터 3번(사용자 여정(User flow) 스케치)까지의 프로세스를 다룹니다.
4번(이벤트&프로퍼티 설계)부터의 프로세스가 궁금하시다면 아래 다음 글을 참고해 주세요.
▶︎ 다음 글 : 비용 최적화된 이벤트 택소노미 설계하기
ㅤ사실 이벤트 택소노미는 본격적으로 설계하는 당시보다, 설계하기 전 목적과 방향성을 분명히 하는 데 더 중점을 두어야 합니다. 목적과 방향성이 불분명한 상태로 설계를 시작하면 추후 수정이 잦아지고 설계가 복잡해지면서 혼동이 잦을 수 있기 때문입니다. 또한 복잡해진 설계를 해결하기 위해 수정을 지속 거치다 보면 택소노미 자체에 의미를 두게 되면서 정작 본연의 목적이 흐려질 수도 있습니다. 이벤트 택소노미는 데이터 분석을 위한 하나의 도구일 뿐이며, 택소노미를 설계하는 것 자체가 목적이 되어서는 안 됩니다. 마케팅 관점에서 분석이 용이해야 하고, 개발 관점에서 구현이 가능해야 하는 점을 기억해야 합니다.
ㅤ그러므로 최종 대시보드에서 데이터를 마주하게 될 관련 담당자들과 충분한 논의가 이루어져야 합니다. 네이버 시리즈의 경우 사용자가 회원가입 → 쿠키 충전 → 도서 구매 → 도서 열람의 퍼널이 매끄럽게 이어지도록 하는 것이 최종 목표라고 가정합니다. 여기에서 주요 이벤트는 각각 sign_up, charge_cookie, purchase_completed, view_episode가 될 수 있습니다. 이를 파악하기 위해서는 먼저 서비스에 대한 이해가 선행되어야 합니다. 핵심은 양 당사자(사용자와 플랫폼)의 입장을 모두 고려하여 서비스를 이해해야 한다는 점입니다.
첫 미팅 전 웹사이트를 점검하며 어떤 애널리틱스를 사용하고 있는지 확인하고 해당 애널리틱스 구조에 맞게 주요 지표들을 스케치해야 합니다.
ㅤ통상적으로 '구매(purchase)'하는 행위를 최종 전환 기준으로 보기 마련이지만, 전환의 기준은 서비스마다 천차만별입니다. 네이버 시리즈의 경우 실제로 카드에서 결제 내역이 기록되는 시점은 도서를 구매하기 위해 쿠키를 '충전(charge_cookie)'하는 시점이기 때문에 설계자 입장에서는 '결제'를 중점으로 퍼널을 설계할 가능성이 다분합니다. 그러나 마케터 입장에서는 도서 플랫폼 특성상 충전을 하더라도 실제로 도서를 소비하는 행위, 즉 도서를 '구매'하고 '열람'하지 않는다면 의미가 없을 수 있습니다.
ㅤ네이버 시리즈의 경우 ‘쿠키 충전, ‘도서 결제’ 후에도 실제로 전자책을 읽는 ‘소비’의 기준까지 있기 때문에 설계자는 어느 지점이 최종 전환의 기준인지, 2개 이상의 전환 기준이 있다면 우선순위는 어떻게 되는지 파악해야 합니다. 예를 들어, 네이버 시리즈의 사용자 입장에서는 '구매 완료(purchase_completed)' 이벤트가 중요할 수 있습니다. 결제가 완료되고 다운로드를 완료한 시점부터 서비스를 이용하고 있다는 인지를 하기 때문입니다. 반면 플랫폼 입장에서는 '도서 열람(view_episode)' 이벤트가 중요할 수 있습니다. 구매(purchase_completed)를 하더라도 실제로 상품(도서)을 소비(열람) 하지 않으면 ‘도서를 읽은 사람’이 아니라 단순히 ‘도서를 구매만 한 사람’이기 때문입니다. 그러나 이 두 경우 모두 동일하게 최종 구매 완료(purchase_completed) 이벤트로 카운트되기 때문에 플랫폼 입장에서는 purchase_completed 뿐만 아니라, 실제로 도서를 열람하는 view_episode까지의 퍼널이 필요합니다.
ㅤ이렇듯 데이터를 바라보는 관점은 직무에 따라, 혹은 서비스 행태에 따라 모두 상이합니다. 따라서 가급적 제품이나 서비스에 대한 이해가 최우선 되어야 하고, 꼬리 질문을 통해 담당자 측으로부터 분석하고자 하는 지표에 대한 정보를 이끌어내어 이러한 간극을 좁혀나가는 것이 중요합니다.
ㅤ마케터와 충분한 논의가 되었다면 개발 관점에서는 실제로 추적 가능한 데이터인지, 혹은 표현 가능한 데이터 형태인지를 판단해야 합니다. (*개발 관점에서의 택소노미 설계 방안은 다음 글에서 상세히 다룰 예정입니다) 만일 마케터의 관점만을 중점으로 택소노미를 설계한다면 추후 설계안 전체를 뒤엎어야 할 수도 있습니다.
- 마케터: "A 데이터와 B 데이터가 필요합니다."
- 엔지니어: "A, B 데이터 기반으로 택소노미 설계 완료되었습니다."
이례적인 경우이긴 하나, 위와 같은 상황이 닥치면 완전히 다른 형태의 택소노미를 처음부터 다시 설계해야 할 수도 있습니다. 따라서 택소노미를 설계하기 전 어떠한 분석 툴을 사용하고 있으며, 어떠한 지표들을 추적할 수 있는지에 대한 개발팀과의 커뮤니케이션 역시 매우 중요합니다.
ㅤ이벤트 카테고리를 설정하기 위해 서비스의 유저 플로우를 상상하며 아이데이션을 진행합니다. 서비스에 대한 시장 조사를 통해 이용자의 특성을 고려하여 실제 사용자 관점에서 퍼널에 유입되어 보기도 합니다. 일반적인 주요 지표로는 '회원가입(sign_up)', 장바구니 담기(add_to_cart)', '구매(purchase)'가 있으며, 이는 서비스마다 매우 다양하게 분류될 수 있습니다. 네이버 시리즈의 경우 '쿠키 충전(charge_cookie), '도서 다운로드(download_book)', '도서 열람(view_book)'의 추가적인 주요 지표가 있을 수 있습니다. 각각의 주요 지표들은 2-3가지를 하나의 카테고리로 묶을 수도 있고, 각각의 퍼널로 분류할 수도 있습니다.
[이벤트 카테고리 분류 예시]
이외에도 매우 다양한 경우의 수가 존재합니다. 다만 다섯 번째 케이스와 같이 하나의 퍼널에 모든 주요 카테고리를 연결하여 설계하게 되면 택소노미의 가독성이 현저히 떨어질 수 있어 권장하지는 않습니다.
ㅤ첫 미팅 전 인터뷰 질문을 사전 공유하여 답변을 미리 생각할 수 있도록 하는 것도 좋은 방법입니다. 특히 이미 론칭된 기존 서비스의 경우 접속에 제한이 없기 때문에 정보를 습득하기 수월하지만, 론칭 전 신규 서비스의 경우 내부 보안 문제로 접속이 불가하여 미팅 전 사전 자료 조사가 어려운 경우 사전 인터뷰지를 작성하는 것은 더욱 유용합니다. 인터뷰 질문의 경우 앞서 미팅 전 가정했던 주요 지표들을 기반으로 작성한다거나, 홈페이지의 UI/UX상으로는 명확히 파악하기 어려운 사항들을 리스트업 하고, 론칭 전 서비스의 경우 자사의 기존(과거) 서비스를 참고하거나, 경쟁사의 레퍼런스를 참고하여 설문지를 작성하는 것도 하나의 방법입니다.
이때 각 질문들은 가능한 구체적으로 풀어 작성하는 것이 중요합니다.
[인터뷰 질문 유형 예시]
ㅤ마케팅과 개발 모두의 관점에서 택소노미의 목적과 방향성을 분명히 하고 사전 자료 조사에 따라 인터뷰를 원활히 진행하여 택소노미의 뼈대를 완성했다면, 이제 설계에 돌입하여 주요 지표 사이 사이에 살을 붙여야 합니다. 예를 들어 '회원가입 완료(sign_up)'를 위해서는 회원가입 페이지에 진입하여 회원가입 시작을 클릭하고, 사용자 정보를 입력하여 최종적으로 회원가입 완료하기 버튼을 클릭하면 회원가입의 퍼널이 완성됩니다. 이러한 유저 플로우의 간략한 아키텍처를 스케치해 두면 추후 택소노미를 구체화하기가 훨씬 수월합니다.
--
다음 글에서는 본격적으로 이벤트 택소노미를 설계하는 방법과 실제 플랫폼 서비스의 택소노미 설계 사례를 자세히 다루어 볼 예정입니다.
▶︎ 다음 글 : 비용 최적화된 이벤트 택소노미 설계하기
[비용 최적화된 이벤트 택소노미 설계하기]
원본 포스팅 링크
https://brunch.co.kr/@soxxun/7