사용자 행동 데이터 설계/분석 현실 레슨 런

데이터 쌓은 거 있어요? 아니 없어요

쓸만한 데이터가 하나도 없어요? 없어요

아 있었는데? 아니 없어요 그냥

아니 없다고요

데이터를 기반으로 서비스를 개선해 나가는 것은 누구나 꿈꾸는 일이지만 경험해보니 생각보다 녹록치 않다. 일단 위 사례처럼 쌓아 놓은 데이터 자체가 없는 경우가 많다. 그래서 대부분 행동 로그라고도 부르는 사용자 행동 데이터부터 쌓기 시작할 것이다.

그런데 이 사용자 행동 데이터는 데이터량이 방대하고 결과물이 raw 데이터에 가깝기 때문에 설계 및 분석이 까다롭다. 설계 방법론에 대해 참고할 만한 글은 많은 것 같아서 나는 사용자 행동 데이터 설계/분석 등에 대한 현실 레슨런에 대해 남겨보려고 한다.

닭이 먼저냐 달걀이 먼저냐, 데이터가 먼저냐 서비스가 먼저냐

앞서 언급한 ‘데이터 기반의 서비스 개선’과 이어지는 내용이다. 서비스를 개선하려는데 근거 데이터가 없고, 근거 데이터를 수집하려면 서비스가 필요하다. 특히 신규 서비스나 기능을 제안하는 경우 이런 딜레마에 빠지게 된다.

일단 현상을 관찰할 수 없으니 데이터를 기반으로 문제의 당위성을 주장하기는 어렵다. 그래서 이러한 간극을 연결하기 위해 가설을 제시하고 실험을 할 수 있는데, 이 마저도 비교군(이전 버전)이 없어 영향도를 측정하기 애매하다.

또한 현재 존재하는 않는 기능에 대해 목표 지표와 수치를 정의하는 것이 밑도 끝도 없게 느껴졌다. 물론 목적 중심으로 생각하면 지표를 설정하는데 도움이 되긴 하지만 너무 커다란 지표(리텐션이라든지..)로 귀결되는 문제도 있었다. (기본적으로 실험 사고방식에 익숙하지 않았던 탓도 크겠지만)

이런 상황에서 어떻게든 데이터를 보려고 두 가지를 시도했는데, 좋은 방법인지는 모르겠다. 첫 번째로 관찰할 데이터와 비교군이 없는 상황에서는 연관지표를 최대한 긁어 모았다. 예를 들면 팔로잉 기능을 신규 도입할 때 관심도를 파악하기 위한 연관지표로 기존에 집계하고 있었던 프로필 조회 이벤트를 살펴보았다.

프로필 조회는 특정 유저에 대한 관심을 나타낸다
→ 유저 별 프로필 조회 수가 증가하는 현상이 관찰된다
→ 관심 있는 유저를 모아볼 수 있는 팔로잉 기능에 대한 니즈가 입증된다

 

연관지표를 통해 신규 카테고리(폰 케이스)에 대한 니즈를 확인한 에이블리의 사례도 참고할 수 있다. 샥출발 탭 내에 폰 케이스가 입점하기 전이기 때문에 해당 카테고리의 클릭량 자체는 알 수 없지만 관심도를 파악하기 위한 연관지표로 “샥출발 탭 내 폰 케이스 검색량”을 살펴본 것이다.

물론 이 경우 기적의 논리 비약을 하지 않도록 유의해야 한다. 그렇기 때문에 데이터 하나만 가지고 근거로 내세울 수는 없고 정성적 접근, 제안자(기획자나 분석가)의 판단을 종합해야 하는 것 같다. 예를 들면 위 에이블리 사례도 이미 아래와 같은 배경이 존재했다.

(비즈니스) 샥출발 카테고리 확장 계획이 원래 있었음
(비즈니스) 에이블리에서 폰케이스는 구매율이 매우 높은 카테고리임
(정성적) 입점 브랜드 측에서 샥출발 카테고리 확장(폰케이스)에 대해 꾸준히 문의가 있었음

 

팔로잉 기능 역시 정보를 탐색하는 유저의 행동 패턴에 대해 배경지식이 있었기 때문에 디벨롭이 가능했다. 어쨌든 취지는 어떻게든 ‘볼 수 있는 데이터를 보자’는 것이다.

두 번째로 목표 지표와 수치를 정의할 때는 타사 보도자료에 공개된 지표와 수치를 참고했다. 단, 프로덕트의 성숙도가 다르고, 정확한 집계 기준 등을 알 수 없어 절대적으로 비교할 수는 없으므로 MAU에 비례한 수치를 활용했다.

예를 들면 자사 MAU가 100이고 타사는 1,000일 때, 타사의 지표가 20,000,000이면 자사의 목표 지표(X)를 2,000,000으로 설정하는 식이다.

	자사	타사
MAU	100	1,000
목표 지표	X	20,000,000

X = 2,000,000

물론 이 방식도 당연히 허수가 너무 많지만… 도저히 지표와 수치에 대한 감이 안 온다면 이런 방식으로 가늠을 잡아보는 것도 방법 중 하나인 것 같다.

사람마다 생각하는 기준이 다르다 (정답이 없다)

앞서 언급한 대로 사용자 행동 데이터의 관리가 까다로운 이유 중 하나는 사람마다 이벤트와 속성을 정의하는 기준이 상이하기 때문이다.

예를 들면 세션과 같은 개념을 봐도 구글 애널리틱스에서 30분이라는 지속 시간을 새롭게 정의한 것이고, 게시판의 조회수 같은 수치도 정합성을 고려하여 새로고침 등으로 발생하는 중복 조회를 카운트하지 않는 것과 같이 추가 정의가 필요한 것을 알 수 있다.

그나마 세션이나 조회수는 1회성으로 종료되는 이벤트이기라도 하지, 찜하기(찜했다 찜 해제하면?), 팔로잉(팔로잉 했다가 해제하면?) 같은 이벤트는 생각보다 정의하기가 애매하다. 이처럼 정답이 없는 문제의 한계를 인정하고 다음 두 가지 방식으로 대응하려 했다.

첫 번째로 데이터를 flat 하게 수집하는 것이다. 다른 말로 하면 누구나 납득할 수 있도록 속성 단위로 수집한다는 뜻이다. 예를 들면 조회수를 알고 싶다면 단순 이벤트 발생 횟수만 집계하는 것이 아니라 상품명, 상품id, 유저id 등 로그 형태로 집계하였다.

raw 데이터를 확보한 상태이므로 여러 번 후가공 해도 원본 데이터는 손상이 되지 않는다. 각자 다른 기준으로 지표를 정의하는 과정에서 생각이 모아지기 때문에 데이터 활용 자유도가 보장되는 것이 중요하더라. 또 raw 데이터를 봐야 알 수 있는 패턴들도 있다. (이래서 현업/타 부서에서도 자꾸 raw 데이터로 달라고 요청하는 거겠지.. 이건 나중에 또..)

두 번째로는 이벤트의 정의와 목적, 속성 값들을 문서로 잘 남겨두는 것이다. raw 데이터 기반으로 후가공된 지표들 역시 집계 기준이나 쿼리를 남겨두는 것이 좋다. 개인적으로 문서화는 이걸 관리하는 나 자신을 위해서 하는 편이었지만, 나중에 기회가 되면 구성원들에게 내가 정의한 지표와 집계 기준을 공유하고 추가 지표에 대한 아이디어를 들어보는 등 활동을 해보고 싶기는 하다. 전사를 대상으로 이런 활동을 할 기회가 있을까?

생각보다 의미있는 데이터가 쌓이는 데 시간이 오래 걸린다

보통 스프린트 2주 단위로 배포가 이루어졌는데, 이전 스프린트에 배포된 기능의 현황을 이번 스프린트에 회고하는 식이었다. 배포와 동시에 사용자 행동 데이터를 집계한다고 해도 약 2주 간의 데이터가 쌓이는 것인데 이건 정말 어떤 판단을 하기에 택도 없는 시간과 데이터의 양이라는 것을 체감했다.

물론 이건 비즈니스와 서비스의 특성에 따라 천차만별이겠지만, 그리고 데이터의 양이 문제가 아닐 수도 있겠지만 도저히 어떤 경향성이나 흐름이 보이지 않아서 회고가 지지부진해졌다.

이 문제는 딱히 뾰족한 수가 없이 관찰 기간을 늘리는 식의 대응밖에 하지 못했는데, 지금 생각해보자면 가설과 연관 지표, 목표 지표 등을 더 작은 단위로 정의하여 분석을 효율적으로 하는 방법이 있지 않을까 싶다.

---

그리고 번외로 제일 중요한 레슨런은 내가 설계한 데이터는 내가 책임져야 한다는 것이다.. 데이터가 있으면 좋고 많으면 더 좋다라고만 생각했었는데 내가 설계한 이벤트들이 많아질수록 과거 데이터의 구멍을 수습하는 것도 나의 몫이다. 히스토리를 파악하고 있어야 하고 관리해야 할 쿼리나 대시보드 차트도 늘어나게 된다. 이건 정말 현실적으로 신중해야 하는 부분이었다. (데이터만 하는게 아니니까...)