고객의 구매 여정 데이터 분석하기(feat. Amplitude)

안녕하세요. 와이즐리컴퍼니 그로스 엔지니어 김재민입니다. 와이즐리컴퍼니는 “어떻게 하면 고객이 더 쉽고 편하게 우리 제품을 구매할 수 있을까?”를 항상 고민합니다. 그 고민에 답을 찾기 위해 Google Analytics(이하 GA), Amplitude와 같은 툴을 도입해 퍼널 분석에 필요한 데이터를 수집하고 있고, 수집한 행동 데이터 및 주문∙재고 데이터를 분석해 더 좋은 고객 경험을 만들고자 노력하고 있습니다.

저는 그중에서도 Amplitude를 활용한 분석 시스템을 구축하며 고객의 행동 데이터를 어떻게 수집하고 이용할지 많이 고민했는데요. 이번 글에서 고민을 풀어내는 과정과 그 과정에서 얻은 작은 팁을 적어보려 합니다.

Amplitude를 도입한 이유

홈페이지에서 Event 정의하기

　Event Taxonomy의 중요성

　이해하기 쉬운 택소노미 작성하기

　와이즐리컴퍼니에 필요한 이벤트는?

Amplitude 데이터를 고객 데이터와 합치기

　추가 과금이 필요했던 두 가지 시도

　작은 데이터 파이프라인 만들기

와이즐리컴퍼니에서 Amplitude를 활용하는 사례

　코호트별 분석

　홈페이지 리뉴얼 성과분석

　랜딩 페이지별 광고 성과 비교

　A/B Test 결과 deep-dive

글을 마무리하며

* 목차를 클릭하면 해당하는 본문을 바로 보실 수 있어요.

Amplitude를 도입한 이유

와이즐리컴퍼니는 웹 스토어도 하나의 프로덕트로 보고 있습니다. 고객님들이 스토어 페이지를 만족하며 이용하실 수 있도록 다양한 분석 및 실험을 진행하는데요. 기존에 사용하던 툴인 GA는 무료였지만 몇 가지 아쉬운 점이 있었습니다.

● GA는 개인별 추적을 지원하지 않습니다. 특정인 또는 특정 집단이 어떤 양상을 보이는지 확인할 수 없습니다.

● GA는 데이터가 실시간으로 수집되지 않습니다. 수치가 업데이트될 때까지 수십 분을 기다린 적도 있었습니다. 특히, QA처럼 즉각적인 변화를 확인해야 할 때 큰 단점으로 작용했습니다.

● GA에서는 보고서를 작성할 때 트래픽 수가 50만을 넘어가면 샘플링된 데이터를 이용합니다. 경향성은 파악할 수 있겠지만 정확도를 신뢰하기 어렵습니다. 현재도 꽤 많은 트래픽이 발생하고 있고, 회사가 커질수록 더 많은 데이터가 쌓일 예정이므로 이것은 단점이라고 판단했습니다.

Amplitude는 이러한 GA의 단점을 모두 보완하는 툴이어서 도입하게 되었습니다. 고객 여정을 직접 확인할 수 있고, 데이터가 실시간으로 업데이트됩니다. 또한 신규 고객 여부, 유입 경로, 특정 브랜드 경험 여부 등 다양한 조건으로 코호트를 생성할 수 있다는 장점도 있습니다. 현재 와이즐리컴퍼니에서는 Amplitude를 통해 퍼널 및 이벤트 분석, 개별 고객 여정 추적, Pathfinder 그래프 기능을 활용한 전체적인 구매 여정 모니터링 등을 하고 있습니다.

홈페이지에서 Event 정의하기

Event Taxonomy의 중요성

Amplitude를 사용하기 위해서는 홈페이지에서 어떤 이벤트를 잡을지 정해야 합니다. 각 이벤트의 이름, 발생 조건, 이벤트가 가진 property(이하 이벤트 속성)를 정의한 것을 Event Taxonomy(이하 택소노미)라고 합니다.

처음 스크립트를 설치할 때 이 택소노미를 잘 정의해두어야 합니다. 만약 택소노미 시트를 대충 만들면서 확인하고 싶은 이벤트를 모두 정의해두지 않는다면, 나중에 이벤트를 추가하고 데이터가 쌓일 때까지 다시 기다려야 합니다. 반대로 너무 세세한 행동까지 추적한다면 비용이 커지며 분석에 방해가 될 수 있습니다. 따라서, 이벤트를 정의할 때 각 이벤트의 활용성을 신중하게 계산하는 것이 중요합니다.

비슷한 위계의 이벤트를 각각 따로 둘지, 한 이벤트로 처리할지는 분석하는 사람 입장에 따라 판단해야 하는데요. 이때 이벤트 속성을 적극적으로 활용해서 불필요한 이벤트 종류를 줄이면 좋습니다.

예를 들어, 메인페이지 아이템 카드의 click 이벤트를 정의한다고 할 때 click_main_item_blade, click_main_item_starter 등을 하나씩 만들기보다는 click_main_item 이라는 하나의 이벤트 안의 속성으로 “itemid:101”을 잡는 것이 좋습니다. 이렇게 하면 메인페이지에서 아이템 카드를 누르는 비율을 볼 때 click_main_item 이벤트를 이용하면 되고, 특정 아이템 카드의 클릭 수를 볼 때는 itemid 조건을 걸면 되므로 분석가에게 좀 더 직관적인 데이터를 제공할 수 있습니다.

와이즐리컴퍼니에 필요한 이벤트는?

Amplitude를 사용하는 회사들은 보통 컴포넌트를 클릭할 때 발생하는 클릭 이벤트, 페이지가 바뀔 때마다 발생하는 뷰 이벤트를 주로 잡습니다(구체적인 이벤트 명칭은 회사마다 다릅니다). Amplitude 파트너사에서도 이런 방식을 권장해 초기에는 두 종류의 이벤트와 구매 전환 이벤트를 추적했습니다. 이렇게만 잡아도 고객의 여정을 추적하고 분석하는 건 가능했지만, 조금 아쉬운 점이 있었습니다.

와이즐리컴퍼니의 뷰 이벤트는 모든 페이지 접속마다 발생합니다. 그래서 고객이 새로고침을 하거나 React.js 및 Angular.js와 같은 SPA(Single Page Application) 라이브러리로 개발된 페이지에서 새로 렌더링 될 때마다 발생합니다(이 글을 읽고 계신 분이 개발자가 아니라면, 회사 개발자에게 SPA 페이지 여부를 문의해보세요). 그래서 Pathfinder 그래프를 보면 중요하지 않거나 중복된 뷰 이벤트가 분석을 방해하고 있어 퍼널 단위 분석이 어려웠습니다.

뷰 이벤트 로직을 수정하는 방법도 있지만, 사용자의 새로고침 여부처럼 나중에 필요할 수도 있는 분석을 위해 그대로 두었습니다. 대신 새로운 이벤트 유형인 퍼널 이벤트를 추가로 잡았습니다.

퍼널 이벤트의 경우 메인 페이지 진입, 제품 상세페이지 진입, 장바구니 담기 등 유저가 사전에 정의한 퍼널에 진입할 때 발생하도록 했습니다. 또한 퍼널 이벤트는 다른 퍼널에서 진입하는 경우만 발생하며, 새로고침이나 리렌더링 시에는 발생하지 않도록 했습니다.

퍼널 이벤트 구현에는 브라우저의 Session Storage를 활용했습니다. Session Storage란 브라우저의 탭마다 생기는 작은 저장소이고, 탭이 종료되면 내용이 삭제되는 특성을 가진 브라우저 저장소인데요. 아래는 Session Storage를 통해 새로고침, 리렌더링 이슈의 영향을 받지 않고 현재 퍼널과 직전 퍼널의 구매 여정 단계를 구했던 방법입니다.

1. Session Storage에는 현재 퍼널, 직전 단계 퍼널을 저장합니다.

a. 현재 퍼널은 currentFunnel, 직전 퍼널은 prevFunnel라는 이름의 변수에 저장합니다.

b. 첫 진입일 경우 prevFunnel은 null로 저장합니다.

2. 어떤 페이지에 진입할 때 Session Storage에 저장된 currentFunnel과 현재 퍼널을 비교합니다.

a. 만약 두 개가 다르다면, 퍼널이 바뀐 것이므로 퍼널 이벤트를 발생시킵니다.

i. prevFunnel에는 currentFunnel 값을 저장하고, currentFunnel에는 바뀐 퍼널의 이름을 저장합니다.

b. 만약 두 개가 같다면, 새로고침 한 상황이므로 퍼널 이벤트를 발생시키지 않습니다.

와이즐리컴퍼니는 모든 이벤트에 currentFunnel, prevFunnel 값을 이벤트 속성으로 저장하고 있습니다. 이벤트만 보고도 어느 퍼널에서 왔는지 확인할 수 있어, 구매 여정 분석을 좀 더 수월하게 할 수 있습니다.

제품 상세페이지 진입 이벤트. 이벤트만 보고도 어느 단계에서 상세페이지로 넘어왔는지 previousfunnel을 통해 확인 가능합니다. 참고로 Amplitude Event Explorer 크롬 확장 프로그램을 설치하면 수집하는 이벤트를 바로 확인할 수 있어 편리합니다.

추가 과금이 필요했던 두 가지 시도

1. Snowflake에 저장한 후, BigQuery로 옮기기

Amplitude에서 제공하는 파이프라인으로 Snowflake에 데이터를 옮깁니다. 그리고 기존에 사용하고 있던 ETL 툴인 Stitch를 통해 Snowflake에서 BigQuery로 데이터를 전송하면 BigQuery에 웹 이벤트 데이터를 쌓을 수 있습니다. 그러나 이 방식은 DW인 Snowflake를 사용하는 데 적지 않은 과금이 필요했고, Stitch가 이 데이터를 추가로 옮겨야 하므로 이전보다 더 비싼 요금제를 선택해야 했습니다.

2. Google Cloud Storage(이하 GCS)에 저장한 후, BigQuery에서 GCS에 있는 데이터로 테이블 생성하기

Amplitude에서 제공하는 파이프라인으로 GCS에 데이터를 옮깁니다. 그 후 BigQuery에서 테이블을 하나 만들고, 이 테이블이 GCS 데이터를 가져오도록 설정해두는 방법이 있습니다. 하지만 이 방식 역시 새로운 데이터베이스 시스템을 사용하기 때문에 추가 과금이 발생합니다. 또한, 이벤트의 모든 컬럼 값을 다 저장하면 용량이 커지기 때문에 필요한 컬럼만 저장하기 위해서 직접 파이프라인을 개발하는 것이 낫겠다고 판단했습니다. GCS에 있는 데이터를 BigQuery로 옮기는 과정에서 알 수 없는 에러가 계속 발생하기도 해서 더 시도하지 않았습니다.

불필요한 과금이 발생하는 방식 대신, 와이즐리컴퍼니는 Amplitude와 BigQuery의 API를 이용해 작은 데이터 파이프라인을 직접 만들었습니다. Amplitude에서 API로 raw data를 받아오고, 그것을 BigQuery에 저장하는 로직을 서버에서 주기적으로 실행시키는 것입니다. AWS Lambda의 프리 티어를 적절히 이용하면 과금 또한 없거나 적고, BigQuery에 저장하는 연산에만 비용을 지불하면 됩니다. 와이즐리컴퍼니는 현재 Lambda를 사용해 구현한 파이프라인이 매시간 자동으로 돌아가도록 하고 있습니다.

작은 데이터 파이프라인 만들기

Amplitude Export API를 이용하면 raw event data를 받아올 수 있습니다. API_Key, Secret_Key는 Amplitude 콘솔 페이지의 Settings > Projects에서 확인할 수 있습니다. 여기에서 시간은 UTC 기준임을 항상 조심하면서 API 요청을 보내면 응답으로 raw data가 json형태로 저장된 zip 파일을 받습니다. 그 후 아래의 로직으로 코드를 작성합니다.

1. API로 raw data를 받은 후(zip 파일로 전송) 압축 해제

2. 전처리 후 json파일로 저장

● BigQuery 테이블과 컬럼 이름, 타입 맞추기

○ 필요없다고 판단되는 컬럼은 없애도 무방합니다.

● event property, user property는 (Python 기준) 딕셔너리 타입이므로 문자열로 파싱

● (구현 로직에 따라) null값 처리

3. 저장한 json파일을 BigQuery 테이블에 로드

3에서 데이터를 DW에 전송하려면 해당 DW의 API나 SDK를 이용하면 됩니다. 우리의 최종 목적은 BigQuery에 이벤트 데이터를 쌓는 것이므로 BigQuery에서 제공하는 Python SDK를 사용했습니다. 전처리된 json파일을 통째로 BigQuery에 전송하면 코드가 종료됩니다.

이 로직을 Lambda에서 한 시간에 한 번씩 실행되도록 설정하면 됩니다. Amplitude 서버에서 한 시간에 한 번씩 로그 json파일을 생성하므로, 굳이 한 시간보다 빠른 주기를 가질 필요는 없습니다. 또한 서버에서 로그 파일이 생성되는 데 최대 2시간이 소요되므로, 현재 시각보다 여유롭게 3시간 전 데이터를 받아오도록 설정했습니다. 정상적으로 데이터를 받아왔다면 user id로 기존 데이터베이스의 테이블과 join하여 좀 더 폭넓은 분석을 할 수 있습니다.

코호트별 분석

Amplitude는 코호트를 만들 수 있다는 큰 장점이 있습니다. 와이즐리컴퍼니에서는 코호트 기능을 적극 활용하여 각 고객군의 특성에 맞춰 분석을 하고 있습니다.

● 구독 고객과 일반 고객

● 신규 고객과 기존 고객

● 와이즐리 스토어 개편 이전에 첫 구매한 고객과 이후에 첫 구매한 고객

● 나이

● 성별

위의 고객군은 대체로 상대 집단과 큰 차이를 보이기에 저희가 주목하고 있는 기준 중 일부입니다. 아래에 소개할 테스트를 할 때 상대 집단과 유의미한 성과 차이가 있다는 가설을 세우고, 그 가설을 검증하기 위해 노력했습니다.

홈페이지 리뉴얼 성과분석

와이즐리컴퍼니는 올해 3월에 가격 정책을 대폭 변경했습니다. 가격이 평균 43% 낮아졌기에 고객들의 구매 패턴도 크게 바뀌었습니다. 낮아진 가격으로 AOQ(Average Order Quantity), AOV(Average Order Value)가 상승했는데, 이러한 상황에서 고객들의 구매 경험 향상을 위해 새단장한 스토어의 UI/UX 성과 분석을 위해서도 Amplitude를 사용하고 있습니다.

● 전체적인 모니터링을 통해 각 퍼널이 기능을 잘 하는지 체크하고 있습니다.

동일한 광고에 랜딩 url을 다르게 넣어 어떤 페이지가 랜딩 페이지일 때 성과가 제일 좋은지 실험하고 분석했습니다. 이때 주의했던 점은 광고 컨텐츠, 매체, 대상에 따라 결과가 왜곡될 수 있으므로 정확한 실험을 위해 변수를 통제해야 한다는 것이었습니다. 와이즐리컴퍼니에서는 광고 조건이 비슷할 경우 스토어 페이지를 랜딩페이지로 보내는 것이 전환율, AOV, 다음 퍼널로 넘어가는 비율 모두 좋았습니다.

2번 실험의 경우, 신규 고객의 전환율 및 스토어 페이지에서 제품 상세 페이지로 넘어가는 비율을 체크했습니다.

Amplitude의 코호트 기능으로 기존 및 신규 고객 코호트를 만들 수 있었고, 각 페이지에서 목표한 페이지로 넘어가는 비율과 구매 전환율을 추적했습니다. 각 실험 모두 개선안이 원안보다 오차 범위보다 큰 값으로 우세했습니다. 위의 두 실험 및 추가 실험을 통해 좋은 개선안은 살리면서 스토어 페이지를 그로스 해킹했고, 최종 전환율을 약 2배 올리는 성과를 기록했습니다.

글을 마무리하며

utm을 통해서만 고객을 분류할 수 있던 GA와 달리, Amplitude는 구매 횟수나 가입일 등 다양한 조건으로 코호트를 생성해 더 정확한 분석을 할 수 있었습니다. GA를 쓸 때 “이 수치가 정확한 게 맞나요?”라는 질문이 들어오면 식은땀이 나기도 했는데, Amplitude에서는 샘플링이 없고 실시간으로 데이터 저장을 확인할 수 있어 스크립트만 잘 짠다면 GA보다 정확도를 더 신뢰할 수 있어 좋았습니다. GA가 그래프 하나 그리는 데 수십 초 걸리는 것에 비해 Amplitude는 로딩 시간이 거의 없는 것도 대조적입니다.

하지만 GA는 무료인 반면 Amplitude는 큰 금액을 지불해야 합니다. 도입할지 말지 고민 중이시라면, 앞서 말씀드린 장점과 비용을 잘 계산해본 후 신중하게 결정하시기 바랍니다.

지금까지 와이즐리컴퍼니에서 어떻게 웹 퍼널 분석 시스템을 만들었는지, 이 시스템으로 무엇을 분석하고 있는지 소개했습니다. 저희의 방식일 뿐 공식 가이드나 정답이 아니지만, 각자의 회사 특성에 맞도록 커스텀해 Amplitude를 효율적으로 사용하시는 데 도움이 된다면 좋겠습니다. 이 글을 읽으시는 분들 모두가 진짜 성장을 위한 Growth Hacking을 이루어내시길 바라겠습니다.

함께 읽기 좋은 아티클

와이즐리가 제품을 만드는 원칙과 과정

우리가 와이즐리에서 일하는 이유

WISELY PRO 런칭, 1년 동안 PM으로서 배운 것들

팀 와이즐리

고객의 구매 여정 데이터 분석하기(feat. Amplitude)

와이즐리컴퍼니가 Amplitude로 더 좋은 고객 경험을 만드는 방식