"마케터 관점" 이벤트 텍소노미 설계해 보기(feat.앱스플라이어, 브레이즈 등)

최근 내부 데이터(first party data) 활용에 대한 관심이 높아지고 있다. 쿠키리스 정책으로 MMP, 매체 데이터와 같은 외부 데이터 정확도가 떨어지며 내부 데이터를 활용한 광고 운영 방식이 늘고 있고, 고객 데이터 분석 기반인 CRM이 급부상하면서 그 활용도는 더욱 높아지고 있다. 

 

이미 여러 솔루션을 사용하고 있는 곳이라면 트래킹 되고 있는 내부 데이터(first party data)를 잘 활용하는 것에 초점이 맞춰지겠지만 이제 막 MMP(앱스플라이어, 애드브릭스 등), 브레이즈와 같은 솔루션을 도입하고자 한다면 가장 고민되는 것이 "이벤트 텍소노미 설계"다. 

 

실제 개발자와 다이렉트로 협업하여 MMP 이벤트 텍소노미 설계> 구현까지 진행했던 경험을 토대로 이벤트 텍소노미 작업 과정과 알아두면 좋을 내용을 정리해 보았다. 

 

이벤트 텍소노미(Event taxonomy)란?

 

이벤트 택소노미(Event taxonomy)는 이벤트들을 특정 규칙에 따라 분류하는 것으로 여기서 이벤트(event)란 가입 완료, 구매 완료, 상세페이지 조회 등 웹 또는 앱에서 유저들의 "유의미한 행동"을 의미한다. 특정 규칙에 따른 구분은 AARRR 퍼널에 따라 분류할 수도 있고, 고객 구매 여정에 따라 분류할 수도 있다. 각자 분류 기준을 선정하면 된다. 만약 고객 구매 여정에 따라 분류해 본다면 아래와 같이 해볼 수 있다. 

​

[(예시)고객 구매 여정에 따른 이벤트 구성]​

​

이벤트 텍소노미를 고민하는 분들의 이야기를 들어보면 공통적으로 나오는 질문들이 있다. 

​

Q1. 이거 꼭 해야 하나요?

예를 들어보겠다. 퍼포먼스 광고를 통해 유입된 고객이 100명인데 구매로 이어지는 고객은 5명도 안되었다. 이벤트 텍소노미 작업 여부에 따라 대응 방법은 크게 달라진다. 

 

[대응] 이벤트 작업이 안되어있는 경우

- 매체별 예산을 다시 배분하고 예산을 증액한다

- 상품 이미지, 문구 등을 변경하며 소재 최적화를 한다. 

 

[대응] 이벤트 텍소노미 작업이 되어있는 경우

유입> 가입> 구매 여정에서 가입 후 구매하지 않고 이탈한 고객이 절반 이상임을 발견한다. 

▼

가입 후 이탈한 고객이 마지막으로 조회한 상품페이지를 확인한다. 

▼

전체 이탈 고객 중 고가 상품을 조회한 고객들의 비중이 높음을 확인한다.  

▼

첫구매 할인율을 조정한다. 

 

이벤트 텍소노미 작업이 되어있는 경우 심도 깊게 문제에 대한 원인을 파악할 수 있다. 퍼포먼스 광고에 한정지었지만 추후 CRM 캠페인을 진행하고자 한다면 이벤트 텍소노미 설계는 필수다. CRM은 고객 데이터 분석 기반으로 이뤄지기 때문이다. (솔루션을 도입한다면 무조건 해야 한다. 안 하면 손해다.) 

 

Q2. 이 작업은 마케터가 해야 하나요?

직접 해본 입장으로 설계는 마케터가 해야 한다고 생각한다. 마케팅에 어떤 데이터가 유의미한 지 PM이나 개발자가 파악하는데 어려움이 있기 때문이다. 설계 이후 구현 단계에서는 PM이나 개발자 협업이 필요하다. (다만 회사 상황에 따라 PM없이 진행하기도 하는데 아무래도 PM이 함께해야 과정이 좀 더 수월해진다.) 

 

그렇다면 이벤트 텍소노미 작업은 어떻게 진행해야할까. 차례대로 정리해 보겠다.   

 

[STEP 01] Event taxonomy 설계

 

이벤트 텍소노미를 설계할 때 중요한 것은 "우리가 고객 이벤트를 통해 뭘 얻을 것인지"를 고려하는 것인데, 막상 아무것도 없는 상태에서 작성하려면 쉽지 않다. 그래서 이벤트 텍소노미 작업 시 기본적으로 들어가는 이벤트 리스트를 공유한다. 실제 앱스플라이어, 브레이즈 이벤트 텍소노미 작업할 때 작성한 리스트 중 일부다. 

 

(예시) 이벤트 텍소노미 일부

 

※유의사항※ 이벤트 이름은 통일하자!!

어떻게 보면 당연한 거지만 MMP(앱스플라이어, 애드브릭스 등)나 CRM 솔루션 등 다양한 솔루션을 쓰는 경우라면 더더욱 이벤트명을 통일되게 가져가는 것이 좋다. 예를 들어 구매완료를 "purchase"로 한다면 앱스플라이어는 af_purchase, 브레이즈는 bz_purchase로 이벤트명 앞에 솔루션 약자를 추가해 구분하는 방식이다. 이벤트명에 규칙을 만들어놓는 것도 좋다. 소문자로 통일한다던가, 띄어쓰기에 "_"를 붙인다던가 하는 것들이다. 

 

[STEP 02] Trigger 시점 그리고 Event property 정리하기

 

수집할 event들이 정리되었다면 각 이벤트들의 trigger시점과 event property를 정리해야 한다. 하나씩 설명해 보겠다. 

 

1) Trigger 시점 정리하기 

트리거 시점은 이벤트가 기록되는 시점을 지정하는 것이다. 개발자와 다이렉트로 커뮤니케이션한다면 이 부분을 명확히 하는 것이 중요하다. "장바구니 담기" 이벤트를 예시로 들어보겠다. 

 

아래와 같이 "장바구니 클릭> 장바구니 완료창 노출"되는 로직이라면 트리거 시점을 "장바구니 버튼 클릭"으로 할 가능성이 높다. 그러나 이때 추가로 고려해야 할 것이 있다. 사이즈 옵션을 선택하지 않고 장바구니 버튼을 클릭했을 때이다. 

 

장바구니 버튼 클릭 시 2가지 상황이 있다. 

1) 사이즈 옵션 선택 후 장바구니 버튼 클릭> 장바구니 완료창 노출

2) 사이즈 옵션 미선택 후 장바구니 버튼 클릭> "사이즈를 선택해 주세요" 알럿 노출 

​

장바구니 버튼 클릭이 트리거 기준인 상황에서 만약 사이즈 옵션을 선택하지 않고 장바구니 버튼을 클릭했다면(사이즈 옵션 선택 후 장바구니 버튼을 다시 누를 것이므로) 장바구니 담기가 중복 트래킹될 가능성이 높다. 

​

따라서 트리거 시점을 장바구니 담기 완료 창이 떴을 때로 변경하거나, 사이즈 미선택 후 버튼 클릭한 경우 제외하는 등의 조건을 추가해야 한다. 이런 것들은 사실 PM의 업무이지만 회사 상황상 PM 도움을 받기 어렵다면 개발자와 논의하며 정확한 시점을 잡아야 한다.  

 

2) Event property 정리하기 ​

※ Event property란?

"상세페이지 조회"라는 이벤트에서 우리가 궁금한 건 "어떤 상품을 봤냐"일 것이다. 따라서 상품 상세페이지 조회 이벤트의 이벤트 프로퍼티는 상품 상세페이지 내 브랜드명, 상품 분류(대/중/소), 이벤트 구분(기획전, 이벤트), 가격, 상품명 등이 될 것이다. 결과적으로 이벤트 프로퍼티는 우리가 특정 이벤트에서 알고 싶은 세부 정보들이라 생각하면 이해하기 편하다. 그리고 이벤트 프로퍼티에 대한 값을 value라고 한다. 

  ▶이벤트: 상세페이지 조회
  ▶이벤트 프로퍼티: 상품 가격 
  ▶Value: 34,990원 

 

[상품 상세페이지 예시]

 

아래는 "상품 상세페이지 조회"이벤트에 대한 이벤트 프로퍼티와 value를 정리한 표이다. (노란 음영 내용은 CRM 이벤트 텍소노미 작업 시 추가되는 내용 일부다.)

​

​(예시) "상품 상세페이지 조회" 이벤트 프로퍼티

 

[STEP 03] QA 진행하기

 

QA는 Quality Assurance 약자로 품질 보증한다는 것인데 우리가 설계한 이벤트 텍소노미대로 데이터가 잘 들어오는지 확인하는 것이다. 주로 이벤트 트리거 시점, 프로퍼티 데이터가 정확히 들어오는지 확인한다. QA는 QA담당자 혹은 PM의 역할이지만 만약 두 담당자가 없다면 개발자와 마케터 몫이다. 

 

예를 들어 구매 완료 이벤트를 QA 한다고 하면 실제로 상품을 구매하고 우리가 설계한 대로 데이터가 잘 들어오는지 확인하면 된다. (최종적으로 아래와 같이 데이터가 잘 들어오는지 확인하는 것이다.)

​

(예시) 이벤트 데이터​

​

작업 전 미리 알아두면 좋을 것들

 

실제 MMP 이벤트 텍소노미 설계 > 구현 과정을 거치면서 시행착오들이 있었다. 그래서 작업 전 미리 알고가면 좋을 내용을 정리해 보았다. 

 

※value 형식이 통일되어 있는지 확인하자!! 

앱스플라이어의 경우 최근 3개월 데이터만 저장해 둔다. 이 말인즉슨 3개월 지난 데이터는 다운받을 수 없다는 것이다. 그래서 수동으로 다운받아놓아야하는데 데이터가 많아질수록 수동으로 일일이 다운받기는 어렵다. 그렇다면 손쉽게 API로 연결하여 앱스플라이어 데이터를 내부 DB로 쌓을 수 있는 방법이 있다. 이걸 고려하지 않고 VALUE 형식을 지정하면 나중에 앱스플라이어 데이터를 자동으로 받는 게 어려울 수 있다. 결과적으로 추후 상황을 고려해 내부 DB 형식에 맞게 VALUE 작업을 해야 한다는 것이다. 

 

말이 어려울 수 있는데 예를 들어 고객이 A, B 2개 상품을 구매해서 Purchase값에 2개 상품이 동시에 트래킹 되었다고 치자. 아래와 같이 [] 구분자로 상품 리스트가 들어올 것이다. 이 경우는 [] 와 , 구분자로 상품을 구분할 수 있다. (엑셀로 아래 Event Value값을 각각 구분하는 과정을 생각해 보면 이해가 쉬울 것이다.) 구분자가 통일되어있지 않으면 내부 DB에서 해당 데이터를 자동으로 구분해서 받아들이기 어려워진다. 

 

※데이터 유형을 알아보자!

이벤트 텍소노미를 설계할 때 각 이벤트마다 데이터 타입이 정해져 있다. 그래서 각 데이터 타입에 대해 알고 있으면 좋다.  

 

※SDK(Softwear development kit)와 S2S(Server to server)란?

이벤트 텍소노미 작업을 할 때 자주 언급되는 단어가 SDK와 S2S다. 2가지에 대해 설명해 보겠다.

​

SDK는 쉽게 말해서 개발자들이 편하게 개발하도록 돕는 소프트웨어 키트다. 예를 들어 앱스플라이어와 같은 MMP를 자사 앱과 연결하려면 연동도 하고 자사 앱이벤트를 MMP 가이드에 맞게 전송도 해줘야 한다. 이걸 하나하나 다 개발하면 엄청난 공수가 들 것이다. 그래서 MMP에서 개발에 필요한 가이드, API, 예시 코드 등을 키트로 제공하는 것이다. 

​

그럼 S2S는 뭘까? 앱용 SDK는 앱과의 연동을 위한 자료들인데 앱 중에는 웹과 앱이 섞인 하이브리드 앱인 경우가 있다. 예를 들어 앱 내 가입완료나 구매완료는 앱이 아닌 웹페이지로 구성되어 있는 것이다. 이 경우 앱용 SDK 활용이 어려우므로 자사 서버와 MMP 서버에 직접 통신하도록 하는 작업이 S2S다.