인사이트 - EVENT TAXONOMY

EVENT TAXONOMY_image_thumbnail
GROWTH

에어브릿지의 이벤트 구조 이해하기 (vs. GA4)

August 26, 2024

에어브릿지(Airbridge)는 데이터 수집부터 마케팅 성과 분석까지 하나의 대시보드에서 진행하는 마케팅 성과 분석 솔루션(MMP)으로, 라스트 터치 어트리뷰션, 멀티 터치 어트리뷰션, 마케팅 믹스 모델링 등 다양한 방법으로 앱과 웹사이트의 마케팅 성과를 함께 분석할 수 있는 통합 마테크 솔루션입니다.

오늘날 MMP 솔루션은 광고주들에게 필수적으로 사용되고 있습니다. 에어브릿지 역시 그 중 하나로, 별도의 연동 없이 통합된 데이터 분석과 어트리뷰션이 가능한 것이 강점입니다.

에어브릿지의 이벤트 구조는 타 플랫폼에 비해 비교적 복잡하기 때문에 이전에 GA4 및 타 분석 솔루션만을 사용하다 에어브릿지를 처음 접했다면 다소 혼란스러울 수 있습니다. 저 역시 꽤 헤맸던 것 같습니다.

이러한 계기로 에어브릿지 택소노미를 설계할 당시 이벤트 구조를 이해하는 데 실제로 도움이 됐던 자료들과 GA4의 구조를 비교하여 전체적인 구조를 설명드리고자 합니다.

에어브릿지 공식 가이드

에어브릿지의 이벤트 및 어트리뷰트 호출 코드의 작성 방법은 아래 세 가지 경로를 통해 확인하실 수 있습니다.

1. 에어브릿지 유저 가이드(Airbridge Help Center)

유저 가이드를 통해서도 코드를 작성하는 데에는 문제가 없지만 2번 자료의 코드 구조가 비교적 효율적이므로 가급적 2번 자료를 참고하시는 것을 권장드립니다.

에어브릿지 유저 가이드 - 이벤트 구성요소 | Airbridge Help Center

2. AB180 깃허브(Github)

1번 유저 가이드의 코드 예시 보다 더욱 상세한 전체 코드를 확인하실 수 있습니다.

AB180 깃허브 (Github)

3. 유저 가이드 및 에어브릿지 공식 문서(Data Spec)

에어브릿지에서 제공하는 Event와 Attribute의 목록과 상세 정보들을 확인하실 수 있습니다.

에어브릿지 이벤트 종류 | Airbridge Help Center
Airbridge Data Spec (Public)

에어브릿지 이벤트 구조 - 1

Text Example

카테고리(Category), 액션(Action), 라벨(Label)

에어브릿지 이벤트 구성 요소에는 카테고리(Event Category), 액션(Event Action), 라벨(Event Label), 밸류(Event Value), 어트리뷰트(Attribute), 트리거(Trigger)가 있습니다.

다소 복잡해 보이지만 조금만 들여다보면 이해하기 쉽습니다.

에어브릿지 이벤트 구성 요소 설명 이미지

위 이벤트 구성 요소의 개념들이 조금 생소하신 분들은 GA4의 예시로 보면 이해하기 쉽습니다.

(GA4의 Metrics & Dimension에 대한 기본 개념이 궁금하신 분들은 관련 자료를 참고해 주세요)

Text Example

GA4 vs. Airbridge

- GA4 보고서

GA4 보고서 예시 이미지

- Airbridge 보고서

Airbridge 보고서 예시 이미지

GA4의 측정기준(Dimensions)이 에어브릿지의 카테고리, 액션, 라벨의 역할을 하고,

측정항목(Metrics)이 에어브릿지의 밸류의 역할을 한다고 비교해 볼 수 있습니다.

Text with Underline

단, 액션과 라벨은 카테고리의 하위 속성으로서 리포트에서 확인 가능한 데이터로, 필요 시 선택적으로 세팅할 수 있습니다.

GA4와 Airbridge 구조 차이를 설명하는 이미지 표

예를 들어, 의류를 판매하는 모 기업의 마케팅 담당자가 구매 이벤트 발생 시 아래와 같은 항목들의 데이터를 수집한다고 가정합니다.

Purchase

{주문일자}
{브랜드명}
{제품명}
{색상}
{수량}

모두 시맨틱 어트리뷰트로 수집 가능한 항목들이지만 어트리뷰트의 경우 에어브릿지 리포트에서 확인할 수 없기 때문에 CDP와 같은 고객DB에 접근하거나 별도의 솔루션으로 전처리하여 확인해야 합니다. 이런 경우 유용하게 쓰일 수 있는 항목이 액션과 라벨입니다.

만일 자주 사용하는 어트리뷰트 항목을 에어브릿지의 리포트와 대시보드에서 활용하고자 한다면 어트리뷰트 항목을 액션과 라벨에 세팅하여 어트리뷰트에 대한 데이터를 리포트에서도 확인할 수 있습니다.

다시 말해, 1개의 카테고리2개의 어트리뷰트(액션, 라벨)에 대한 통계를 에어브릿지의 리포트와 대시보드에서 쉽고 빠르게 확인할 수 있습니다.

- Category: Purchase
- Action: {브랜드명}
- Label: {제품명}

아래 이미지는 스탠다드 이벤트 중에서 일정 예약 이벤트(airbridge.subscribe)의 예시입니다. 일정을 예약한 지역은 액션 또는 라벨로 수집할 수 있으며, 시맨틱 어트리뷰트를 활용하면 예약한 ID(scheduleID)와 예약일시(datetime)를 수집할 수 있습니다.

스탠다드 이벤트 중 일정 예약 이벤트(airbridge.subscribe) 예시 이미지

에어브릿지 이벤트 구조 - 2

Text Example

밸류(Value)

밸류는 에어브릿지 이벤트가 수집한 숫자를 계산에 이용하기 위해서 선택해야 하는 구성요소입니다. 에어브릿지 이벤트의 밸류로 수집된 숫자만 계산에 이용할 수 있습니다. 밸류로 소수점 9자리 이하 숫자까지 수집할 수 있습니다.

예를 들어, 레비뉴 리포트(Revenue Report)에서 판매한 제품의 가격을 더해 전체 판매 가격을 계산하거나 디지털 서비스의 구독료를 전부 합해서 전체 구독료를 확인하기 위해서는 밸류를 반드시 이벤트 구성요소로 사용해야 합니다.

또한, 밸류로 수집된 데이터는 밸류로 수집된 다른 데이터와 계산할 수 있습니다. 액션이나 라벨로 수집된 데이터는 계산에 활용할 수 없습니다. 그러나 이벤트 발생 횟수는 밸류 사용 여부와 상관없이 확인할 수 있습니다.

예시) 구매 완료 이벤트

구매 완료 이벤트 예시 이미지

위 예시와 같이 액션과 라벨, 밸류 모두 숫자로 수집한다고 하더라도 밸류로 수집한 데이터만 계산할 수 있으며, 액션과 라벨로 수집한 데이터는 계산할 수 없습니다. 예시에서는 구매 완료 이벤트의 밸류로 수집한 데이터를 더해서 30,000이라는 수치를 얻을 수 있습니다.

Text Color Change

단, 카테고리(이벤트)와 동일하게 이벤트가 발생한 횟수는 확인할 수 있습니다. 구매 완료 이벤트의 액션 중에서 1,000이라는 속성이 2번 발생한 것을 에어브릿지 리포트에서 확인할 수 있습니다.

매출 관련 데이터는 속성으로 수집하는 것이 일반적이나, 에어브릿지의 경우에는 Attribute가 아닌 Value로 수집합니다. 즉 밸류에는 보통 구매액이 들어가고, 어트리뷰트에서는 기타 정보들을 수집합니다.

에어브릿지의 매출 관련 데이터 수집 화면

Semantic Attribute로 사용할 수도 있지만, Actuals Report나 Revenue Report에서는 이벤트 밸류에 Semantic Attribute의 isRevenue 값을 True로 설정한 카테고리(이벤트)로부터 발생한 매출액(Value 값)을 기준으로 확인하기 때문에 이는 적절하지 않습니다. (설정 가능한 Revenue 이벤트 수: 최대 5개)

Revenue Report 내 이벤트 벨류 예시 이미지

Revenue 이벤트를 설정할 때 한 가지 유의할 점은 Revenue의 구조가 다양한 서비스일 경우(전환 포인트: 포인트 충전, 제품 결제, 광고 충전 포인트 등), Revenue Report에서 확인할 최종 전환 기준 한 가지를 선정하셔야 합니다.

만일 아래와 같이 구매 완료 시 2개의 매출 관련 이벤트가 동시에 호출되고 2개의 이벤트 모두 Revenue 이벤트로 설정한 경우 중복집계가 될 수 있기 때문입니다.

예시)

- 주문 완료 이벤트 발생 시 단위별 이벤트 동시 호출

  • airbridge.ecommerce.order.completed (주문서 단위 1건 로깅) > isRevenew(True)
  • confirm_item_order_completed (주문서 내 제품 단위 1건 로깅) > isRevenew(True)
Text Color Change

1건의 매출(=1만원) 중복 발생(=2만원)

매출액 집계 기준을 제품 단위로 볼지, 주문서 단위로 볼지 결정하고 결정된 하나의 카테고리(이벤트)에 isRevenue를 세팅해야 중복집계를 방지할 수 있습니다.

따라서 Revenue로 집계할 이벤트와 기타 매출 관련 데이터를 집계해야 하는 이벤트를 별도로 관리하시는 것을 권장드립니다.

에어브릿지 이벤트 구조 - 3

Text Example

어트리뷰트(Attribute)

GA4와 Airbridge의 이벤트 속성명 정의의 차이 비교 표

각 카테고리(이벤트)에는 다양한 속성 정보가 수집되는데, 플랫폼마다 정의하는 '속성명'이 상이합니다. GA의 경우 Parameter, 에어브릿지의 경우 Attribute로 정의합니다. 이벤트(카테고리)명 역시 GA4의 경우 Event, 에어브릿지의 경우 Standard Event라고 정의합니다. 각 플랫폼별로 기본적으로 제공되는 속성들이 있으며, 에어브릿지의 경우 Data Spec에서 확인이 가능합니다.

Text Color Change

단, 현재 버전의 SDK에서 제공되지 않는 일부 항목들도 포함되어 있으므로 명확한 확인이 필요합니다.

Airbridge Event

  • 스탠다드 이벤트: 에어브릿지는 주요 유저 행동 25개를 선정해 미리 정의한 이벤트
  • 커스텀 이벤트: 앱 서비스에 맞는 광고 성과를 추적하기 위해 스탠다드 이벤트에 해당하지 않는 유저의 행동을 새로 정의한 이벤트

Airbridge Attribute

  • 시맨틱 어트리뷰트: 에어브릿지가 수집하는 데이터를 미리 정한 어트리뷰트
  • 커스텀 어트리뷰트: 에어브릿지 사용자가 수집하기 위해서 새롭게 정의한 어트리뷰트

Text Color Change 한 가지 유의사항이 있다면, 에어브릿지 커스텀의 경우 원본 데이터 추출에서 수집된 모든 속성 데이터가 같은 칼럼에 담긴 상태로 확인이 가능 합니다. 아래 실시간 로그에서 형태를 확인하실 수 있습니다.

Airbridge의 앱 이벤트 실시간 로그 화면

따라서 데이터의 수집 구조를 충분히 고려하여 분석 환경을 구축해 놓는 것이 좋습니다.

EVENT TAXONOMY_image_thumbnail
GROWTH

패션 플랫폼의 그로스마케팅 (무신사/29CM/W컨셉)

July 3, 2024

본업이 그로스마케터이므로... '그로스마케팅'와 관련된 포스팅을 지속적으로 작성하고 있는데요. 관련 키워드로 '패션마케팅'이 검색량이 높아 무신사, 29CM, W컨셉을 사례로 준비해 보았습니다. (좀 더 알아보니 패션마케팅은 대학교 학과가 있어 입시생들의 검색량이 높은 키워드인 듯은 하네요.)

그럼에도 불구하고 의류는 생활에 밀접하게 맞닿아있는 산업이라 이해가 한결 쉬울 것 같으니, 그로스마케팅의 개념을 패션 플랫폼의 사례로 소개 해 볼게요. 1. Acquisition과 2. Retention의 관점으로 접근해보겠습니다.


1. Acquisition: 유입/가입 캠페인

무신사의 브랜드마케터 채용 공고를 먼저 보겠습니다.

무신사의 브랜드마케터 채용 공고
브랜드 마케터에게 필요한 직무 요건 중 하나로 User Acquisition을 이끌어낼 수 있는 콘텐츠 기획 이 있네요. User Acquisition 즉 사용자 획득에서는 지난 글에서도 다뤘는데요. 대다수의 웹/앱 서비스는 사용자가 획득(=유입, 가입, 구매) 되어야 활성화될 수 있는 구조이기 때문에 비즈니스 초반에 마케팅에서 가장 중요한 요소 로 손 꼽힙니다.

cf. https://brunch.co.kr/@marketer-emje/13

cf. https://brunch.co.kr/@marketer-emje/13

User Acquisition을 이끌어내기 위해서 여러 마케팅 방법론이 존재하겠지만, 무신사의 브랜드마케터 채용 공고에 있는 '콘텐츠 기획'은 아마 퍼포먼스마케팅, 배너 광고의 소재 기획일 가능성 이 높아 보입니다.

퍼포먼스마케팅에서 배너 광고를 운영할 때 그 소재로 브랜드가 강조될 수 있고, 프로모션이 강조될 수도 있고, 인플루언서가 강조될 수도 있고 메인 콘셉트를 무엇으로 하느냐에 따라서 소재 베리에이션은 다채로울 수 있는데요. 예시와 함께 보겠습니다.


(1) 퍼포먼스마케팅: 배너 광고

페이스북 광고 라이브러리에서 'WConcept'을 검색했을 때 결과 중 일부를 가져왔는데요.

� 여기서 두 광고의 차이점이 보이시나요?

Image 1 Image 2

� 광고를 클릭하면 랜딩은 모두 Wconcpet 페이지로 연결되지만, 해당 광고를 게재한 '주체'가 다릅니다.

W컨셉에서 W컨셉 페이지로 랜딩 시키는 것은 당연한데, W컨셉에 입점해있는 '브랜드'들이 광고의 랜딩을 랜딩을 W컨셉으로 보내네요!

소규모 브랜드라면 개별 웹사이트를 관리, 운영하는 것보다 수수료를 감안하더라도 의류 플랫폼(W컨셉 등)에서의 매출을 높이는 것이 더 낫다고 판단했다고 추측할 수 있습니다.


(2) 첫 구매 프로모션

첫 구매 혜택 (=신규 가입 시 10% 할인 쿠폰, 앱 첫 구매 15% 할인 쿠폰)은 소재와 워딩에서 공통적으로 강조 되기도 합니다. 즉 메인 소재는 남성 카테고리의 시즌오프이지만, 전환율을 올리기 위해 혜택을 수치화할 수 있는 부분을 담기도 합니다.

29CM의 메타 광고 라이브러리

신규 가입과 앱 첫 구매의 내용이 담겼다는 것은 해당 광고의 세팅이 '리타겟팅'이 아닐 것이라 추측할 수 있습니다. 아마 성별만 '남성'으로 지정하고 오픈 타겟으로 열지 않았을까 싶네요. 디타겟팅(=타겟에서 제외하는 것)으로 이미 회원인 분들과 앱이 있는 분들을 타겟에서 제외하고요.


(3) 인플루언서 마케팅

최근 인플루언서와 협업하는 마케팅 또한 빠질 수 없는 업무인데요. 플랫폼/브랜드의 아이덴티티와 정합성이 높은 인플루언서(주로 인스타그래머, 유투버)를 찾고 그분들과 혹은 그들의 소속사(MCN)와 컨택해서 브랜디드 콘텐츠(BDC) 혹은 PPL을 협의 합니다.

해당 업무는 일반적인 퍼포먼스마케터/그로스마케터가 진행하기보다는 무신사의 예시처럼 '인플루언서 마케터'의 직무가 따로 있는 경우가 많습니다.

무신사의 인플루언서 마케터 채용 공고
무신사의 인플루언서 마케터 채용 공고

인스타그래머라면 피드, 스토리의 이미지/워딩 그리고 유튜버라면 유튜브 구성안과 기획안을 검토하면서 논의를 이어가게 됩니다. 일정, 비용, 스토리라인, 강조되어야 하는 점, 해시태그 등을 이야기하고요.

하단 예시처럼 유상 광고 소재(인스타그램 광고 소재)로 인플루언서의 이미지를 활용하는 경우 추가 협의가 필요합니다.

Image 1 Image 2 Image 3


2. Retention: 재방문/재구매 캠페인

새로운 회원들을 어느 정도 유치했다면, 그 회원들을 계속해서 유지하는 것이 관건이겠죠. 리텐션(=재방문율/재구매율)이 그 지표가 되는데요. 리텐션의 기본으로 여겨지는 것 중 하나가 멤버십입니다.


(4) 멤버십

커머스/플랫폼의 경우 누적 구매액에 따라 주는 혜택이 점점 더 커지고 그 효용을 체감한 사용자들은 해당 커머스/플랫폼을 지속적으로 사용하게 되는데요. 이것은 락인(lock-in)효과 라고도 합니다. 구매할수록 혜택이 커지니, 다른 플랫폼을 이용할 필요 없이 해당 플랫폼에 대한 충성도가 높아지는 것이죠.

W컨셉은 5개의 멤버십 등급을 가지고 있고, 그 기준으로는 누적 구매액과 함께 구매'수량'을 같이 보고 있습니다. 해석해 보자면 딱 한 개의 상품만 샀는데 - 그 상품이 100만 원짜리였다 -라고 했을 때 한 번에 VIP로 가는 것을 방지하기 위함이라고 볼 수 있습니다. 한 번 들어와서 비싼 것 한 개 산 사람보다, 여러 번 들어와서 중고가를 여러 개 산 사람이 더 충성도가 높다고 판단하는 것이겠죠?

29CM의 경우 동일한 워딩에 여러 브랜드X상품 이미지를 활용하기 위해 조금 포괄적인 내용을 광고 워딩으로 썼는데요. 29CM의 아이덴티티 + 매월 멤버십 쿠폰 ~15% 혜택을 강조합니다. 여기엔 신규 회원 가입이나 앱 설치 쿠폰이 없는 것을 보아 신규를 대상으로만 하는 광고가 아님을 알 수 있고요.

Image 1 Image 2


(5) 프로모션

마케팅과 뗄레야 뗄 수 없는 것이 '프로모션' 입니다. 위에서 Acquisition을 다룰 때도, 신규 가입/앱 설치 혜택이 존재했고, 인플루언서와 협업할 때도 최저가나 가격/쿠폰 할인은 거의 필수입니다. Retention에서도 마찬가지로, 멤버에서도 혜택이 강조됩니다. 여기서 혜택이란 주로 '상품 할인' 혹은 '할인 쿠폰'인데요.

무신사스탠다드(무신사의 PB브랜드)의 마케팅 팀장 채용 공고에도 '중요 이벤트와 프로모션 지원을 통해' 라는 워딩을 통해 마케팅과 연계된 프로모션의 중요성을 인지할 수 있습니다.

‍무신사스탠다드(무신사의 PB브랜드)의 마케팅 팀장 채용 공고

일반적으로 정가 대비 판가에 미리 적용되어 있는 것을 '상품 할인' 이라고 볼 수 있고, 이후 주문서에서 추가로 붇는 할인들은 '할인 쿠폰'입니다. 이 할인 쿠폰은 개별 상품/브랜드에만 적용될 때와 장바구니 전체에 적용되는 경우로 나눠볼 수 있고요.

상품 할인과 쿠폰 할인(상품 쿠폰, 장바구니 쿠폰)의 구분은 커머스에서 혜택을 설계할 때나 손익을 계산할 떄 때 그리고 심지어 프로덕트 애널리틱스에서 이벤트/프로퍼티의 택소노미를 설계할 때도 아주 중요한 요소입니다.

Image 1 Image 2
상품 할인과 쿠폰(상품 쿠폰, 장바구니 쿠폰)

W컨셉의 장바구니/카테고리 쿠폰
W컨셉의 장바구니/카테고리 쿠폰


(5-1) 프로모션: 정기(Always-on), 비정기(Ad-hoc)

프로모션은 정기적으로 진행되고 있는 캠페인과 팝업으로 운영되는 캠페인으로 구분할 수 있는데요. 정기적으로 진행되는 캠페인은 올웨이즈온(Always-on) 캠페인, 특정 기간 동안만 일시적으로 진행되는 캠페인은 팝업/애드훅(pop-up, Ad-hoc)이라는 명칭을 자주 사용 합니다.

앱 설치 쿠폰 및 가입 혜택 프로모션은 Always-on 올웨이즈온 캠페인에 속하고, 홀리데이 프로모션은 팝업/애드훅 캠페인으로 볼 수 있겠죠? (와 쉽다!)

보통 앱 설치, 가입의 경우 장기적인 관점의 KPI 달성을 위해 진행되는 캠페인으로 일간/주간/월간 성과를 지속적으로 모니터링하고요. 팝업/애드훅 캠페인의 경우 정해진 기간 동안 최대 매출 등의 목표치를 달성하는 것이 중요합니다. (무신사의 무진장세일이 매년 역대급 매출을 갱신한다고 하죠...? 그렇지만 무진장 정도면 이제는 정규 캠페인이라고도 볼 수 있겠네요)

Image 1 Image 2


(6) CRM 마케팅

CRM 마케팅은 Customenr Relatinship Management의 약자로, 고객 관계 관리 마케팅인데요. 간단히는 문자/카톡/앱푸시/이메일 등으로 계속해서 사용자에게 메시지를 보내며 상호 작용을 꾀하는 것 입니다. (a.k.a 우리는 쿠폰을 보낼게 너는 들어와서 쿠폰을 써줘!)

CRM 수단으로는 앱 중심의 서비스인 경우 앱푸시, 카카오톡을 위주로 사용하고 웹의 경우 배너/팝업 또한 CRM의 일환으로 볼 수 있겠습니다. 문자 및 이메일은 조금 더 전통적인 수단이겠죠?

29CM 그로스 마케터 직무 요건

CRM 마케팅은 CRM 마케터 직무로도 많이 채용하지만, 그로스마케터의 수행 업무에 수반되는 경우도 꽤 있습니다. 29CM의 그로스 마케터 채용 공고를 보면 '고객 커뮤니케이션 타겟 / 채널 / 메시지 테스트 및 운영' 이라는 워딩을 볼 수 있는데요. 하단처럼 쪼개서 생각할 수 있고, 결국 CRM 마케팅에 대한 내용이라는 것을 알 수 있습니다.

  • 고객 커뮤니케이션 > 고객 관계 관리를 위한 커뮤니케이션 (메시지를 보내는 것!)
  • 타겟 > 누구에게 보낼 것인지?
  • 채널 > 어떤 채널로 보낼 것인지? 앱푸시/카톡/문자/이메일/팝업 배너 등
  • 메시지 > 어떤 워딩으로 보낼 것인지? 할인율을 강조할 것인지? 쿠폰의 유효기간을 강조할 것인지? 등

CRM 마케팅이 최근 뜨는 이유는 개인 정보 보호 트렌드 때문인데요. 과거 퍼포먼스마케팅에서는 정교한 타겟팅을 위해 사용자가 웹 내에서 행동했던 것들을 추적하는 (cookie, 쿠키! 한 번쯤은 지워보셨죠?) 것이 중요했는데 이 쿠키 정보의 제공이 중단되면서 일반적인 퍼포먼스마케팅의 효율이 낮아지며 비용이 높아진 것도 일부 원인이 있고요.

상대적으로 CRM은 이미 보유한 회원 모수를 대상으로 메시지를 보내기에, 신규 사용자를 획득하는 것보다 효율이 높고(=비용이 낮고) 운영에 필요한 실 비용이 메시지 발송 비용 정도로 상대적으로 비용이 낮기 때문도 있습니다. CRM마케팅은 기회가 된다면 다음에 좀 더 자세하게 풀어보도록 할게요!


이렇게 패션 플랫폼의 그로스 마케팅 (ft. 무신사, 29CM, W컨셉)을 광고 소재와 채용 공고, 프로덕트를 통해서 Acquisition과 Retention 위주로 알아봤습니다.

[다른 글 보러 가기]

그로스마케팅과 AARRR 퍼널 분석 (ft. 29CM)

https://brunch.co.kr/@marketer-emje/11

그로스마케팅과 AARRR 퍼널 분석 (ft. 29CM)

그로스마케팅이란? 콘텐츠도 퍼포먼스도 UIUX개선도!

https://brunch.co.kr/@marketer-emje/10

그로스마케팅이란? 콘텐츠도 퍼포먼스도 UIUX개선도!

그로스마케팅과 AARRR:Acquisition 획득

https://brunch.co.kr/@marketer-emje/13

그로스마케팅과 AARRR:Acquisition 획득

풀스택 마케팅 컨설팅펌 마티니아이오

https://martinee.io/

원본 포스팅 링크

패션 플랫폼의 그로스마케팅 (무신사/29CM/W컨셉)

EVENT TAXONOMY_image_thumbnail
GROWTH

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

May 31, 2024

이벤트 택소노미 초기 설계 시, 어디에서부터, 무엇을, 어떻게 시작해야 할지 막막한 어려움을 조금이나마 해소해 드리고자, 밀리의 서재 · 버거킹 · 무신사 · 한샘 · 웍스아웃 · 발란 · 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 이벤트가 동시에 추적해야 하는 경우 설명 이미지

ㅤ 네이버 시리즈의 도서 상세 페이지의 경우 view와 click이 동시에 필요합니다. 예를 들어 특정 도서의 상세 페이지 내에 '무료로 첫화보기' 혹은 '다음화 이어보기' 등의 버튼과 같이 결정적인 클릭 요소가 있는 동시에 신작 홍보 이벤트나 기간 한정 프로모션을 통한 유입 경로가 다양할 수 있습니다. 이러한 경우가 '조회'와 '클릭'을 동시 추적해야 하는 경우라고 볼 수 있습니다.

'구매(purchase)' 이벤트가 '무료'와 '유료'로 나뉘는 경우

ㅤ 지금까지 도서의 상세 페이지로 진입하여 충전과 구매가 이루어지는 단일 퍼널에 대해 살펴보았습니다. 그러나 일반적으로 단일 퍼널만으로 구성되는 경우는 드물며, 전환의 기준 또한 다양합니다. 도서 플랫폼의 경우 1화, 2화, 3화, ...로 이어지는 연재본이 있는 반면, 연재본의 묶음 단위인 단행본이 있습니다. 각각의 도서 유형 모두 '무료(혹은 미리보기)'의 개념이 있으며, 마케터는 무료와 유료 구매의 모든 경우를 분석하길 희망한다고 가정합니다. 이때 매우 다양한 경우의 수를 고려해 볼 수 있습니다.

  • 무료 회차를 열람하는 경우
  • 유료 회차를 열람하는 경우
  • 무료 회차를 열람한 후 유료 회차로 넘어가는 경우
  • 유료 회차를 열람한 후 상세 페이지에서 이전 페이지로 넘어가는 경우
  • 유료 회차를 열람한 후 상세 페이지에서 다음 페이지로 넘어가는 경우
  • 무료 회차를 열람한 후 다시 다른 무료 회차를 열람하는 경우

아래는 특정 도서의 상세 페이지에서 '무료' 전환과 '유료' 전환을 프로퍼티로 나눈 예시입니다. 사용자가 'click_episode'를 발생시킬 시 'item_preview'가 True(무료 회차)인 경우 즉시 도서 열람 페이지로, False(유료 회차)인 경우 구매 결정(click_purchase) 페이지로 이동하게 됩니다. 단, 유료 회차이지만 해당 회차를 이미 구매한 경우 무료 회차와 동일하게 즉시 열람 페이지로 이동합니다.

'구매(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)
*개발팀 전달용 택소노미 시트(Event Property)
개발팀 전달용 택소노미 시트(User 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: 비고(기타 특이사항)

*제가 사용했던 택소노미 템플릿 양식은 아래 링크를 통해 다운받으실 수 있습니다. 이외에도 웹사이트 내에 다양한 템플릿이 존재하니 용도에 맞는 템플릿을 적절히 커스텀하여 사용하시길 바랍니다.

▶︎ Event Taxonomy Template (soyun)

ㅤ개발 지식이 부족하더라도, 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를 실시간으로 공유하는 방법이 있습니다. 클라이언트 측에서는 택소노미상의 진행 상황과 상세 내용을 실시간으로 확인할 수 있고, 설계자 입장에서는 커뮤니케이션에 소요되는 시간을 절약할 수 있어 효율적입니다.

이벤트 택소노미 데일리 체크리스트
*Daily Check List

6. 개발자 협의

ㅤ1차 설계안에 대한 협의가 완료되었다면 백엔드에서 데이터 작업을 해 줄 개발팀과 협의를 해야 합니다. 이때 1차 설계안은 '대략적으로 설계'하여 이후 개발팀과의 미팅을 통해 택소노미를 구체화하는 것이 좋습니다. 개발자와의 협의 없이 마케터의 모든 요구사항을 즉시 반영하기 위해 한 번에 많은 에너지를 쏟게 되면, 이후 택소노미를 전면 수정하는 참사가 일어날 수 있기 때문입니다.

ㅤ 서비스마다 사용하는 분석 도구(analytics tool)와 데이터 구조가 저마다 상이하기 때문에 이를 먼저 파악해야 합니다. 일반적으로 타사(구글 애널리틱스, MMP 등) 애널리틱스를 사용하거나, 자사 자체 구축 애널리틱스를 사용하는 경우로 나뉘는데, 두 가지를 병용하는 경우도 다분합니다. 예를 들어, 자사 애널리틱스의 로그 이용 시 경로 추적에 한계가 있기 때문에 이에 최적화되어 있는 GA4와 병용하는 경우를 흔히 볼 수 있습니다. *GA4와 GTM을 사용한다면 [구글 애널리틱스] 데이터 레이어 (Data Layer) 총 정리 (1) 내용을 참고 바랍니다.

자사 자체 애널리틱스의 경우에는 개발상에 제약이 거의 없기 때문에 내부 개발 리소스만 충분하다면 설계와 분석이 매우 수월합니다. 단, 개발자에게 보다 명료한 자료를 제공해야 개발자와의 커뮤니케이션 오류를 최소화할 수 있습니다.

[택소노미 설계 시 사용 플랫폼]

다음 글에서는 QA를 통해 발생 가능한 개발상의 이슈와 이를 통해 얻을 수 있는 인사이트를 공유드릴 예정입니다.

원본 포스팅 링크

https://brunch.co.kr/@soxxun/8

EVENT TAXONOMY_image_thumbnail
GROWTH

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

May 30, 2024

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

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

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

이벤트 택소노미란?

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

이벤트 카테고리 분류 예시

  • 이벤트 유형(Event Category)
'이벤트 카테고리'란 이벤트의 유형을 정하기 위한 단위로, 유사한 이벤트를 하나로 묶어 관리할 때 유용한 요소입니다.
'이벤트 카테고리'는 주로 최종 전환 이벤트로 정의되어 전환까지의 하나의 퍼널을 총칭합니다.
예를 들어 이벤트 카테고리가 ‘회원가입’인 경우, 이벤트 카테고리 내에는 홈페이지에 접속하여 특정 서비스를 이용하고자 회원가입 버튼을 클릭하여 회원가입 완료 페이지까지 이어지는 퍼널이 포함됩니다.
즉 ’이벤트 카테고리‘ = ‘최종 전환 이벤트의 퍼널’이라고 생각하시면 이해가 수월합니다.
  • 이벤트(Event)
‘이벤트’란 사용자가 프로덕트를 사용하는 과정에서의 행동이나 그 결과로 발생하는 사건을 가리킵니다.
예를 들어, '로그인 버튼 클릭', ‘관심상품 추가', ‘장바구니 담기', ‘구매 완료' 등과 같은 일련의 사용자 행동이 이에 해당하며, 그 외에 ‘주문서 로딩 시간’, ‘서버 API 처리 시간’ 등도 이벤트로 볼 수 있습니다.
  • 속성(Property)
프로퍼티란, 웹 문서의 동적인 객체 속성을 의미합니다.
쉽게 말해, 사용자나 이벤트가 가진 동적인 특성을 의미하며 사용자 행동에 대한 세부 분석을 위해 이벤트와 함께 수집됩니다.
예를 들어, '회원가입일자', '회원가입 방법', '회원가입 페이지 유입 경로' 등의 속성값이 이에 해당합니다.
  • 이벤트(Event) vs. 속성(Property)
아래의 그림은 오프라인에서 우리의 행동을 온라인에서 발생하는 이벤트로 전환하여 표현했을 때 어떻게 정리할 수 있는지 보여주는 표입니다. 이를 통해 우리는 이벤트와 속성 간의 차이를 확인할 수 있습니다.

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

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

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

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

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

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

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

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

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

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

유입부터 최종 전환까지 이어지는 단일 퍼널을 그렸다면, 각 단계별로 노드를 추가해 줍니다. 특히 반드시 선택해야 하는 옵션이 있는 단계일 경우 필수로 추가해 주어야 퍼널상의 누락을 방지할 수 있습니다.
이벤트 & 프로퍼티 설계

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)'를 위해서는 회원가입 페이지에 진입하여 회원가입 시작을 클릭하고, 사용자 정보를 입력하여 최종적으로 회원가입 완료하기 버튼을 클릭하면 회원가입의 퍼널이 완성됩니다. 이러한 유저 플로우의 간략한 아키텍처를 스케치해 두면 추후 택소노미를 구체화하기가 훨씬 수월합니다.

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

--

다음 글에서는 본격적으로 이벤트 택소노미를 설계하는 방법과 실제 플랫폼 서비스의 택소노미 설계 사례를 자세히 다루어 볼 예정입니다.

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

[비용 최적화된 이벤트 택소노미 설계하기]

"이벤트 택소노미 설계 전 반드시 고려해야 할 필수 요소, 네이밍 컨벤션"
"1-2-3 퍼널에서 2 퍼널이 필요한가? Critical Path에 따른 필수 이벤트 설계하기"
"View와 Click 이벤트가 동시에 추적해야 하는 경우"
"'구매(purchase)' 이벤트가 '무료'와 '유료'로 나뉘는 경우"
"개발자가 한 번에 알아보는 '이벤트 택소노미 시트'"
"전략에 녹일 수 없는 방대한 데이터는 묶음 처리"


원본 포스팅 링크

https://brunch.co.kr/@soxxun/7