Amplitude 이벤트 데이터(이벤트명 정하기)
수집방법부터 이벤트 명 정의하는 법
※ 해당 포스팅은 Amplitude의 Behavioral Data & Event Tracking Guide 2022 05를 참고하여 작성되었습니다.
※ 용어 통일을 위해 'entity property', '사용자 속성'을 'user property'라고, 이벤트 속성은 'event property'라고 지칭하겠습니다.
매트리스를 사려고 하는 사람이 있다고 가정해 보자. 그 사람은 A라는 쇼핑몰에서 베이직 제품이 좋을지, 프리미엄 제품이 좋을지 고민할 수도 있고, 리뷰나 상세페이지를 볼 수도 있다. 한편으로는 아예 다른 쇼핑몰, B 쇼핑몰의 제품이 좋아 이탈할 수도 있다. 우리가 만약 A쇼핑몰의 사장님이라면 무엇을 할 수 있을까?
나라면 가장 먼저 고객들이 우리 사이트에서 어떻게 행동하는지 그 흐름을 파악해 볼 것 같다. 고객들이 온라인 쇼핑몰을 방문해서 가장 먼저 하는 행동은 무엇일지, 구매까지의 과정이 어떻게 되는지, 어디서 이탈하는지를 확인해 볼 수 있겠다. 이러한 고객 행동을 파악하기 위해서는 '이벤트 데이터'를 알아야 한다.
이벤트 데이터 수집하기
이벤트 데이터는 다음과 같은 과정으로 수집할 수 있다.
1. 추적할 이벤트(행동) 정하기
2. 이벤트 이름 정하기
3. 이벤트 속성(event property) 정하기
4. 이벤트 속성(event property) 이름 정하기
이렇게 행동에 대한 정보만 수집할 수도 있겠지만, 조금 더 자세한 정보를 얻고 싶다면 event property를 따로 지정하여 수집할 수 있다.
이렇게 event property까지 파악한 이벤트는 여러 방법으로 활용, 분석될 수 있다.
1. 가장 결제 전환이 높았던 사람은 장바구니에 상품을 몇 개 담았는지
2. 상세페이지를 보다가 어느 내용에서 이탈이 많았는지
3. 결제까지의 단계 중 어떤 단계에서 이탈이 많았는지
4. 결제할 때 쿠폰을 사용했는지
이벤트 데이터 이름 정의하기
이벤트 데이터를 수집하고 사용하기 위해서는 정의를 위한 적절한 규칙이 필요하다. 적절한 명명 규칙과 분류체계를 만들어두면 이벤트가 중복으로 수집되거나 데이터가 오염되는 것을 방지할 수 있다. 특히 함께 일해야 하는 환경이라면 규칙을 미리 정해두는 것은 필수적이다.
규칙이 없으면 장바구니에 상품을 담는 액션을 보고 Add to Cart, added_to_cart, productAdded, add to cart, Added to cart, and Product Added 이만큼 다양한 이벤트가 생성될 수 있다. 사실 하나의 행동인데 말이다.
규칙의 필요성은 간단히 소개한 것 같고, 이제 이 규칙을 정해야 하는 입장에서는 어땠는지 경험을 공유해보려고 한다. 나의 경우에는 이러한 이벤트 수집을 전혀 하고 있지 않은 상황에서 규칙을 만들어야 했던 터라 오히려 조금 수월했다. 기존에 마구잡이로 쓰다가 잡으려고 했으면 '어떻게 통일하지?'와 같은 고민을 했어야 할 텐데 그런 과정이 없었기 때문이다. 사실 당시에는 이게 좋은 상황인지 몰랐다.
다만 나에게는 '규칙'이라는 단어가 조금 무거웠었다. '아무것도 없는 상황에서, 나도 잘 모르는데 전사에서 사용하는 시스템을 내가 만들어도 될까?' 지나고 나서 생각해 보니 그 부분이 부담스러웠던 것 같다. 그래서 레퍼런스도 찾아보고 개발팀과도 이야기를 많이 나눴던 것 같다.
그래서 내린 내 결론은'이 부분에 있어서는 정답이 없다.'였다.
이벤트를 분석하고 사용할 사람들이 같은 규칙으로 이해하고 있어 커뮤니케이션 비용이 과도하게 발생하지 않을 정도면 충분했다. (아예 규칙을 만들지 말라는 의미가 아니다!) 앰플리튜드에서는 아래 2가지 정도를 지키는 것을 권장한다.
1. 균일한 대소문자 사용
가장 많이 쓰는 애널리틱스 툴인 Google Analytics와 Amplitude에서는 이벤트 명의 대소문자를 구분한다. 즉, add_to_cart와 Add_To_Cart를 다른 이벤트로 인식한다는 뜻이다. 따라서 이러한 대소문자 사용체계가 명확하지 않으면 같은 행동인데도 불구하고 중복으로 데이터를 보내는 경우가 발생할 수 있어 함께 사용하는 팀 내에서는 규칙을 정해두고 쓰는 것이 좋다. '전부 소문자로 쓰자!', '단어 첫 글자는 대문자로 쓰자!' 등의 옵션을 고려할 수 있겠다. 참고로 우리 팀은 일괄 소문자로 쓰는 방식을 사용하고 있다. 이와 함께 띄어쓰기도 '_'를 쓸지, '-'를 쓸지, 공백으로 처리할지 등도 함께 논의해 보는 것을 추천한다.
2. 명명 가이드라인 정하기
이벤트 및 속성의 이름을 지정하는 규칙은 없지만 앰플리튜드에서는 이미 발생한 행동을 명확하게 설명할 수 있기 때문에 객체(Object)-행동(Action) 순서로 쓰는 것을 권장하고 있다. 자세한 내용은 Data Taxonomy 편으로 다시 다뤄봐도 좋을 것 같다.
여기서 궁금증이 생길 수 있다.
Q. 만약 이미 쓰고 있는 이벤트가 새로 정의하려는 규칙과 맞지 않다면 어떻게 해야 할까?
이 부분 역시 정답이 없는 것 같다. 보통 두 가지 방법을 고려해 볼 수 있는데,
1) 일정 기간 이벤트를 중복 집계한다.
이벤트 명을 바꾸면 새로 생긴 이벤트와 연동이 되지 않기 때문에 충분히 데이터가 쌓일 때까지 중복 집계하는 것을 고려할 수 있다. 단, amplitude는 무료 계정일 경우 월 이벤트 사용량이 한정되어 있기 때문에 사용량을 확인하고, 이 방법을 쓸 수 있는지 미리 확인해 보는 것이 좋다.
2) 앞으로 지정하는 이벤트에만 규칙을 적용한다.
이미 집계하던 것들은 살려두면 데이터 유실을 막을 수 있어 좋다. 다만 조직의 규모가 커지면 의사소통에 어려움이 발생할 수 있어 자주 쓰는 중요한 이벤트라면 이벤트 명을 바꾸는 것이 좋다.
이벤트 데이터 구성요소
위에서 잠깐 언급했었는데, 행동 데이터를 조금 더 세부적으로 수집하기 위해서 는 '이벤트 속성(event property)'를 활용할 수 있다. 제품을 구매했을 때(행동), 언제(속성) 구매했는지, 어떤 가격에 구입했는지 정보를 수집할 수 있다.
예를 들어 다음과 같이 수집할 수 있다.
· 이벤트: purchase
· 구매 시간(purchase_at): 2023-02-25 20:39
· 구매 상품(item): apple
· 구매 가격(price): 3,000
이 예시에서 이벤트(purchase)와 연결된 event property는 3가지 (purchase_at, item, price)이다. 이와 같은 event property는 이벤트의 맥락을 더 자세하게 파악하기 위한 것으로 필수는 아니다.
그런데 잘 보다 보면 이상한 게 껴있는 걸 볼 수 있다. 'user_id'?! user id는 'user property' 아닌가?라고 생각했다면, 맞다! 정확히 말하자면 user_id는 event property이라고 보기보다는 이벤트에 대한 식별자로 역할을 수행한다는 의미이다.
앰플리튜드 차트 생성 페이지를 보면 쉽게 이해할 수 있다. Play Song or Video라는 이벤트를 발생시키고, 그 사람들을 조금 더 세부적으로 나눠 보고 싶다면 여기서 where이라는 태그로 한번 더 필터링해 줄 수 있다. 즉, 이벤트 식별자를 통해 그룹을 나눴다는 의미이다.
두 가지(user property와 event property)의 차이는 고객 특성 기반이냐, 특정 행동 정보 기반이냐에 따라 달려있다. 여기서 말하는 user property에는 다음과 같은 항목이 포함될 수 있다.
· 이름, 이메일, 전화번호와 같은 개인 식별 정보
· 연령, 성별, 위치 등의 인구통계
· 구독 타입, 멤버십 가입 여부 등과 같은 계정 정보
Amplitude Segment 차트 페이지※ 아래 예시는 앰플리튜드에서 제시한 이벤트 사용 방식입니다. 이벤트 명, 속성 정하기가 막막하신 분들은 아래 표를 참고하세요!
출처: Behavioral_Data_&_Event_Tracking_Guide_2022_05