오늘은 "로그 유저인터뷰"를 소개드리려 합니다.

사실, 이런 비슷한 행동은 많은 사람들이 하는데요,

그런데 정작 제대로 하는 사람은 드물고

좋은 인사이트/성과를 얻지도 못합니다.

그래서 오늘은

1. 로그 유저인터뷰를 제대로 하는 방법과
2. 클래스101의 PM, 마케터 및 모든 팀원 분들이 이걸 수행할 수 있게 만든 Guide 문서 원문(실전 프롬프트)

이렇게 2가지를 공유드리려 합니다.

왜 필요한가?

제가 정말 싫어하는 말이 있습니다.

"가설이 없는데 분석을 어떻게 해요"

예전에는 이런 말을 해도, 누군가는 데이터 추출을 해야했습니다.

하지만, 이제 AI가 추출을 너무 빨리 도와주죠. 거기다 이제 가설이 뚜렷하면 분석은 AI가 해줍니다.

그래서 결국 중요한건 가설이 없는 상황에서도 팀이 움직일만한 가설을 도출해내는 능력이 되는 것이고,

그것을 우선순위별로 정렬 시켜주고 임팩트를 제안한다면 그것은 전략이 됩니다.

그리고 저는 주로 가설이 없는 상황에서 싸워왔습니다.

또한 그런 상황이 비즈니스에는 더 일반적입니다.

그래서 데이터 분석가가 데이터 추출가를 넘어서,

팀의 방향을 제시하는 사람으로 나아가려면

필연적으로 가설이 없는 상황에 팀을 움직일만한 전략을 도출할 수 있어야합니다.

(참고 : A&A Strategy)

그리고 AI가 이 중요성을 더 가속화시키고 있죠.

그래서 가설이 없는 상황에서 가설을 도출할만한 나만의 프레임워크/스킬을 고루 갖추고

상황별로 적절히 쓰는 것이 중요합니다.

그 중 제가 자주 쓰는게 로그 유저인터뷰입니다.

(줄여서 Log UT라고 표기하는데요, 사실 UT와 유저인터뷰는 다릅니다.

그런데 토스에 있던 시절에 워낙 두개를 섞어 쓰다보니.. 저도 버릇이 잘못들어서 이렇게 씁니다.

승건님의 토스 PO Session에서도 유저인터뷰를 UT라고 부르시는걸 볼 수 있습니다.

이런 걸 보면, 언어의 엄밀함은 비즈니스의 성공과는 크게 상관없는 것 같습니다.

또 다른 예시가 토스에서는 Squad를 Silo라고 부르는데 Silo는 부정적인 의미로도 쓰이곤 하죠)

Log UT / 유저인터뷰 / 데이터

일반적인 의사결정의 근거들로 우리는

정량적인 것(quantitative)과 정성적인 것(qualitative)을 씁니다.

제품에서는

정량적인 것으로 '데이터'를

정성적인 것으로 '유저인터뷰'를

거대한 양축으로 제품을 개선해 나가죠.

'데이터'와 '유저인터뷰'는 각각 장단점이 명확합니다.

데이터는 (일반적으로) '집계'되기 때문에

"전환율이 낮다" 정도의 파악을 하게 합니다.

다만 이것은 문제가 어디에(WHERE)있는지를 찾는데 매우 뛰어나지만,

Why를 설명하기는 매우 힘듭니다.

(참고 : 전략적 생각원칙 #4-1. 세 가지 프레임워크로 문제를 정확하게 정의하라(1) : https://buly.kr/1vSn2C)

반면 유저인터뷰는 유저들을 만나며

행동을 통해 패턴을 찾아내어 내러티브, 즉 더 구체적인 행동(WHY)를 얻기 좋습니다.

반면, 이 행동이 얼마나 지배적인 행동인지,

그리고 유저가 설명한 것이 진짜 사실인지는 알 수 없습니다.

또 유저인터뷰는 시간과 노력이 많이 듭니다.

요약하면,

즉, 데이터는 문제의 위치(Where)은 알 수 있어도, 문제의 내러티브(Why)를 알 수 없고,

유저인터뷰는 문제의 내러티브(Why)는 설명해주지만,

1. 유저의 말의 진실인지 알 수 없고,
2. 유저의 내러티브가 얼마나 지배적인지 알 수 없으며,
3. 그리고 한 번 수행의 Cost가 큽니다.

이런 장단점을 보완해 가기 위한 수단으로 하는 것이

Log User Interview입니다.

Log User Interview 제대로 하는 법

예시를 들어보겠습니다.

가령, 우리가 중고거래 플랫폼을 운영한다고 해봅시다.

가입한 고객이 일주일 내에 중고거래를 할 가능성을 높여주는 'Activation'은 무엇일까요?

이때, 채팅을 하면 50~60% 이상은

중고거래로 넘어간다는 사실은 이미 알고 있고,

채팅 자체는 너무 구매와 직접적인 연관 행동이니,

채팅보다 앞선 행동을 찾고싶다고 가정해봅시다.

이런 식으로 접근해 볼 수 있습니다.

🤨 [Step 1 : 빠른 의심]

1) 가입하고 일주일 내에 거래를 완료한 유저들을 뽑는다.

2) 이들의 주요 행동으로 생각되는 log_type (방문, 클릭)을

3) user_no 기준 내림차순, log_time 기준 오름차순으로 정렬한다.

4) 그리고 살펴보면서 '이 유저의 행동을 상상한다'

5) 사진처럼 로그를 보니, 유저가 초기에 본 게시글인 프린터 상품을 찜하고 이탈한 뒤

푸시를 받아서 들어오고

그 푸시를 통해 판매자와 채팅으로 넘어가는 것을 알 수 있다.

6) 이 유저가 받은 푸시 기록을 보니 그 '프린터'에 관한 푸시였다.

7) 이를 통해 "초기에 찜을 하는게 중요한가?"하는 의심을 하나 추가한다.

📶 [Step 2 : 빠른 집계]

1) 그렇다면, 판매자와 채팅으로 넘어간 유저들 중에 찜을 했던 유저는 어느 정도일까?를 집계한다 (보편적인 상황인가?)

2) 반대로 찜을 했던 유저들 중 판매자와 채팅으로 넘어가는 비율은 어느정도일까? (전환과 상관이 있는가?)

3) 🤨 [Step 1 : 빠른 의심] & 📶 [Step 2 : 빠른 집계] 의 단계를 약 50~100명 정도의 유저 로그를 보면서 진행한다.

4) 이렇게 '가설 백로그'를 작성한다.

✅ [Step 3 : 빠른 실행]

1) 찜한 사람과 그렇지 않은 사람의 채팅 전환율은 어느 정도 차이 날까?

2) 만약 모든 사람을 찜을 시킨다면 '중고 거래'가 얼마나 일어날까?

모든 사람이 불가능하다고 생각한다면, 가능한 범위의 최대한 사람을 전환시킨다면? (임팩트 추정)

3) 추정된 임팩트를 통해 내림차순 정렬하고,

당장 실행 가능한 액션 아이템이 있는지 '사람들을 모아 Ideation'한다.

여기까지 보신 분들은 '로그 까보기'네 라는 생각이 드셨을 겁니다.

네 :) 정확히 맞습니다.

진입장벽이 없는 만큼 모두가 할 수 있고,

그렇기에 이미 활용하시고 계신 분들이 계실 겁니다.

다만, 저는 여기서 가설리스트를 만들고,

빠르게 집계(Step 2), 임팩트를 추정하는 단계(Step 3)

까지 하는 분들은 거의 본 적이 없습니다.

그러다 보니 실행으로 이어지기 힘들고,

결과가 되지 않으니

결국 귀찮기만 한 작업으로 취급받게 되더라구요.

하지만, 귀찮고 부담되고 남이 하지 않을수록

수익이 커지는게 투자라는 점을 잊지 마세요.

조금 더 팁을 드리자면

이렇게 많은 유저들의 '거짓말 하나 없는 일기'를 훔쳐보고

상상하면서 실제 유저인터뷰를 보십시오.

반대로, 실제 유저인터뷰를 보면 그들의 의견을 집계해보십시오.

이 작업으로 가장 인사이트를 얻는 사람은?

이 작업으로 분석가는 집계값 <-> 유저 행동을 스위칭 해나가며,

유저 행동에 대한 이해를 늘려갑니다.

사실 전형적인 의도적 학습 과정이며,

동시에 이 과정에서 도메인 지식을 쌓아가게 됩니다.

(명심하세요, 도메인 지식은 누가 커리큘럼으로 알려주는게 아니라 본인이 배워나가는 겁니다 .

그리고 그 '학습 속도의 차이'가 실력 차이를 결정합니다.

남들이 10년에 걸쳐서 쌓을 경험치를 , 1년만에 배우는 방법은 의도적 학습 뿐입니다. )

사실 이 작업으로 인사이트를 가장 많이 얻는 사람은

고객 접점이 가까운 사람들입니다. 대표적으로 PO가 그러하죠.

그런데 대부분의 PO는 데이터를 직접 조회하지 못하거나,

조회하더라도 파이프라인에 익숙치 않아서 어려움을 겪곤하죠.

그래서 제가 어느날 이런 생각을 했습니다.

로그 유저인터뷰를 PM, PO, 마케터가 직접할 수 있게 하면 어떨까?

사실 제가 매번 로그 하나하나를 까봐서 인사이트를 찾아내는게 시간이 많이 걸리기도 하고,

진짜 문제는 고객에 대한 이해도를 '저만 소유하게'되는 것때문이었습니다.

그래서 늘 그런 고민을 합니다. 어떻게 팀을 다같이 똑똑하게 할 것인가?

그래서 클로드에 분석가이드를 만들었습니다.

여기서 잠깐 설명드리면, 클래스101의 데이터 AI 조회환경은 크게 아래 3가지로 이루어집니다.

1. Guide : 도메인 지식을 정리하는 방식. 비즈니스 도메인 별로 하나씩 가이드를 둠
2. Data Mart : 구글 Dataform에 적재된 마트 구조. AI가 Consume하기 편하도록 정리됨.
3. Instruction : 어떤 순서로 데이터를 참고하며, 언제 Guide를 호출할지를 결정함. 작동 순서와 방식을 결정.

여러 Guide를 가지고 있는데 그 중 로그 유저인터뷰 Guide라는 것을 만들었습니다.

가령

"최근 30일간 X 제품 구매한 유저를 Log UT해줘" 같은 식으로 입력하면 아래와 같은 답변을 해주는 식이죠.

사용자 반응.