사용자 행동 로그, 쌓지만 말고 쓰세요!

9분

2022.06.17.

11.1K

우리 서비스를 이용하는 사용자, 얼마나 이해하고 계신가요? 이미 사용자 행동 로그를 쌓고 계신다고요? 최근에 데이터 분석 툴도 도입하셨군요! 다양한 채널을 통해 사용자 행동 로그를 잘 쌓고 계시는군요? 그런데 이 행동 로그를 활용하는 방법은 생각해 보셨나요?

이벤트 로그는 설계의 자유도와 변동성이 크기 때문에, 신경 써서 관리하지 않으면 쓸모없는 정보가 잔뜩 쌓이기도, 꼭 필요한 정보가 누락되기도 합니다. 아직 행동 로그 개념이 생소하다면, 먼저 ‘이 글’을 추천합니다. 사내 시스템에 많은 데이터가 쌓여 있더라도, 개별 이벤트 로그의 의미를 파악하기란 쉬운 일이 아닙니다. 결국, 어느 순간 사용자의 구체적인 행태는 모른 채, 주간 방문자 몇 명, 이탈 사용자 몇 명 등과 같이 단순 집계만 반복하게 됩니다.

그렇다면 조각조각 열심히 데이터를 모으는 분석가와 엔지니어, 사용자 데이터가 궁금한 기획자와 디자이너 등 조직 내의 다양한 구성원들에게 무엇을 설명해야 행동 로그를 잘 활용할까요? 이를 위해 사용자에 대한 객관적 이해도를 높이고, 나아가 제품 개발 과정에서 활용할 수 있도록 ‘사용자 행동 데이터 잘 쓰는 법’을 소개하겠습니다.

“이제 사내 데이터 교육이 필요한 시간입니다”

데이터를 잘 쌓고 있다면, 이제 직군 불문 조직 내 많은 사람이 데이터를 관찰하고, 데이터에 관해 이야기 나누며, 데이터를 기반으로 의사결정을 내릴 수 있게 도와줄 차례입니다. 우선 Amplitude, Mixpanel, Tableau, Snowflake 등 조직 내 데이터 사용자를 위한 분석 툴이 잘 사용될 수 있도록 사내 데이터 교육 시간을 운영하거나 관련 가이드 문서를 작성해 주시는 게 좋습니다.

위에 언급한 모든 3rd Party Tool(써드파티, 제작사에서 제작한 것이 아니라 다른 업체에서 만든 지원 툴) 개발사는 단순한 사용법을 넘어 다양한 예시를 담고 있는 가이드 문서를 제공합니다. 구글 검색창에 ‘{Tool 이름} document’ 또는 ‘{Tool 이름} official guide’를 검색해보면 쉽게 찾을 수 있습니다. 또한 여러 리셀러가 교육 문서를 제공하거나, 새로운 툴(Tool)을 도입하는 과정에서 온/오프라인 교육을 진행하기도 합니다. 리셀러 교육 자료는 한글로 쓰여 있어 접근성이 훨씬 높다는 장점도 있습니다. 그렇지만 단순히 이런 교육 자료에만 의지하면 데이터를 잘 활용하기 어렵습니다.

우선 개발사 또는 리셀러가 제공하는 자료는 아주 상세하고, 그 양 또한 방대하기 때문에 오히려 분석 도구를 사용하지 않은 구성원에게는 부담이 되는 경우가 많습니다. ‘회사에 Amplitude를 도입했으니, 이번 주랑 지난주의 신규 사용자 유입이 얼마나 되나 봐야겠다’라는 마음으로 Start Kit를 살펴봤는데 자료 확인하면 40분이 걸릴 때가 있습니다. 이러면 ‘급한 일 먼저 하고 다음에 봐야겠다’하는 상황이 발생하기 십상입니다.

이를 방지하기 위해서는 조직 내 전용 교육 자료를 만들어야 합니다. 특히 세부적인 사용법보다 메타 정보를 중심으로 구성해 주는 것이 좋습니다. 예를 들어 ‘우리 회사에서 쓰는 툴은 어떤 상황에서 사용할 수 있는지’, ‘이 툴에서 지원하는 기능과 지원하지 않는 기능은 무엇인지’, ‘전체적인 메뉴 구성은 어떻게 되는지’ 등입니다. 이렇게 전체적인 윤곽을 설명한 뒤에, 구체적인 사용법은 (뒤에서 다시 설명할 테지만) 별도 교육 시간을 통해 안내하는 것이 훨씬 효과적입니다.

또 한 가지, 사내용 자료가 필요한 이유는 우리 회사만의 데이터 혹은 서비스 특성을 반영할 수 있기 때문입니다. 사용자 행동 로그는 설계의 자유도가 높아 유사한 서비스라도 조직에 따라 이벤트를 매우 다양한 형태로 심고 관리할 수 있습니다. 작게는 이벤트 이름을 설정하는 규칙뿐 아니라, 이벤트별로 포함되어 있는 속성값의 범위 등 적용할 수 있는 곳이 천차만별입니다. 그리고 이 같은 이벤트 구조가 사용자 분석의 범위와 방법에 큰 영향을 주기 때문에 사내 자료에는 꼭 이벤트 데이터 카탈로그를 포함해 주는 것이 좋습니다.

실제 데이터 활용법 교육하기

사내 교육용 자료 작성으로 안심하기에는 아직 이릅니다. 이런 가이드 문서는 일종의 길거리 전단지이기 때문입니다. 조직 내 구성원이 데이터를 많이 사용하게 하려면, ‘주로 어떤 목적으로 데이터를 활용하는지’, ‘구체적으로 어떤 지표를 알고 싶은지’ 물어보고 이에 맞는 데이터 활용법을 알려주는 시간이 필요합니다. 요리 교실처럼 같이 모여서 화면을 띄워두고 한 단계씩 따라 해 보는 방식이 가장 좋습니다.

가능하다면 제품팀에서 진행되는 ‘제품 개선 주기(Iteration)’에 참여해 보는 것도 좋습니다. 이번 제품 개선 사항을 어떤 지표로 측정할지, 성공의 기준은 얼마로 할지 논의하고, 실제 반영 후 모니터링을 위한 대시보드를 함께 만들며, 결과에 대해 분석하고 함께 이야기 나누는 전체 과정을 경험하고 나면 데이터에 관한 이해도가 훨씬 빠르게 높아지기 때문입니다.

‘왜?’에서 시작하는 지표와 목표 설정

앞에서 설명한 제품 개선 주기에 참여할 때, 데이터 활용에 관해 더 자세히 설명해 보겠습니다. 기획자들에게 ‘감이 아니라 데이터로 일하고 싶은 마음은 가득한데, 어디서부터 시작해야 할지 모르겠다’라는 이야기를 종종 듣습니다.

그럴 때마다 ‘곧바로 데이터나 숫자를 생각하지 말 것’이라고 먼저 설명합니다. 시작부터 데이터나 숫자를 생각하면 머리가 복잡하기 때문입니다. 대신 내가 지금 담당하고 있는 제품과 이 제품의 성과를 측정할 수 있는 ‘기준’이 무엇일지 먼저 생각하라고 권유합니다. 이 단계에서 해당 지표의 현재 값과 목푯값은 아직 중요하지 않습니다. 생각을 시작하면 으레 ‘이 일(제품 개선)을 왜 하는가?’라는 질문으로 귀결됩니다. 그리고 이 질문에 답변하다 보면 “남들 다 있는 리뷰 시스템이 없으니 빠르게 만든다”가 아니라 “다른 사용자의 후기를 보면 구매 의사결정을 쉽게 내릴 수 있을 테니 리뷰 시스템을 만든다”라고 생각을 바꾸게 됩니다.

여기서 ‘사용자가 이렇게 인식하거나, 이렇게 생각할 거야’라고 하는 부분이 바로 우리의 가설입니다. 그리고 이 가설이 맞는지 검증할 수 있는 기준을 설정하면, 이게 바로 정량적인 지표와 목표가 됩니다. 가설은 써놓고 보면 당연한 이야기일 수 있지만, 가설을 명확하게 설정했는지 여부에 따라 우리가 설정하는 지표가 분명히 달라집니다.

가설이 없을 때의 측정 지표 예시:

리뷰 시스템 런칭 후 한 달 간 등록되는 신규 리뷰 수
구매 대비 리뷰 작성률 등

가설이 있을 때의 측정 지표 예시:

리뷰 시스템 런칭 후 한 달 간 등록되는 신규 리뷰 수
이 중 다른 사람의 구매 의사결정에 도움이 되는 리뷰 비중(단, 추가로 ‘구매 의사결정에 도움이 되는 리뷰는 무엇인가’라는 정의가 필요)
리뷰가 실질적인 구매 의사결정에 도움이 되는지를 확인하기 위한 목적으로 리뷰가 있는 상품과 없는 상품의 구매 전환율 비교 등

열심히 쌓은 사용자 행동 로그를 활용해 가설과 지표를 무사히 설정했다면, 목푯값을 설정할 차례입니다. 보통 목표 설정은 숫자보다 관리의 영역에 속합니다. 흔히 ‘의지치’라고 얘기를 합니다. 여기서 목표를 설정하는 과정에서 누구의 의지를 가장 많이 담을 것인가는 조직의 문화, 의사결정 체계, 문제의 유형에 따라서 크게 달라집니다. 만족할 만한 성과(개선) 수준을 상위 리포팅 라인에 물어볼지, 함께 일하는 팀원에게 물어볼지는 각자의 몫입니다.

완전히 새로운 기능을 도입하거나, 기존에 관련 지표를 측정한 이력이 없을 때, 목푯값에 대해 어떤 논리적인 근거를 만들기 어려울 때, 저는 통상 주관적인 ‘신뢰 구간(Confidence Level)’에 따라 10~30% 사이의 값을 임의로 설정합니다. 기본값을 20%로 두고, 자신이 없으면 10%로 낮추고, 잘 될 것 같은 느낌이 들면 30%로 올리는 식입니다. 이 범위는 사업이나 회사의 성숙도에 따라서도 달라질 수 있습니다. 이렇게 단순한 과정을 통해 목푯값을 설정하는 이유는 결과를 정확히 예측하는 것보다, 측정하고 회고하는 과정이 중요하기 때문입니다.

이 단계까지 진행했다면, 데이터 활용에 대한 부담은 훨씬 경감되었을 거라고 생각합니다. 구체적으로 어떤 지표를 측정할지 결정되었다면, 현재 상태에서 저장되고 있는 이벤트 로그를 활용해서 해당 지표를 곧바로 측정할 수 있는지 확인해봅니다. 만약, 관련 데이터가 시스템에 기록되고 있지 않은 상황이라면, 제품 개선 과정에서 필요한 데이터를 새롭게 정의하고, 기록해 가면 됩니다.

결과를 확인했다면 다시 ‘왜?’로 돌아가기

제품 개선 결과는 곧바로 확인할 수 없는 경우가 많습니다. 1주, 2주, 한 달 등 약속한 주기에 맞춰 결과를 확인할 수 있도록, 대시보드를 만들어 두고, 미리 일정을 지정해 두세요. 배포 이후 다음 제품의 반복 업무를 논의하고 실행하다 보면 어느새 앞선 내용은 잊히는 경우가 많기 때문입니다. 이렇게 몇 번의 잊힘이 반복되면 열심히 쌓아온 조직의 데이터 문화가 사라질 수 있습니다.

결과를 확인할 때는 숫자와 달성률만 보지 말고, 이 지표가 왜 달성되었는지, 왜 달성되지 못했는지를 알아야 합니다. 과정에 함께 참여한 팀원들과 논의해보는 것도 중요하고, 지표와 관련된 세부 퍼널(Funnel)을 보다 세부적으로 뜯어보는 것도 중요합니다.

‘물건을 구매한 사용자들이 리뷰를 기대보다 리뷰를 많이 안 썼다. -> 왜? -> 리뷰 작성의 보상이 없다.’라거나 ‘물건을 구매한 뒤에 사용자가 서비스에 다시 재방문 하지 않는다. -> 왜?’처럼 이 과정은 ‘왜?’의 연속입니다. 나는 A를 기대했는데, 왜 사용자는 B를 했을까? 나는 10을 기대했는데, 왜 사용자는 5만 반응했을까? 등을 질문하고, 파고드는 과정에서 사용자에 대한 이해도가 쌓이고, 전체 팀의 수준이 발전합니다.

마무리

데이터를 잘 사용하기 위한 가장 기본적이고, 중요한 것은 끊임없이 ‘왜’를 질문하고, 찾아가는 과정입니다. 그러니 같은 맥락으로, 글을 마무리해보겠습니다. 왜 데이터를 적극적으로 활용해야 할까요?

데이터를 잘 활용하면 근거 있는 자신감을 쌓을 수 있어요.
궁극적으로 사용자에게 더 높은 가치를 제공할 수 있습니다.