데이터가 없는 게 아니라, 아직 정하지 않은 것입니다

데이터가 안 쌓이는 게 아니라, 무엇을 기록할지 아직 정하지 않은 것입니다. 전부 정할 필요는 없습니다. 하나부터 시작하면 됩니다.

분석 인력이 없는 조직일수록 완벽한 설계를 먼저 만들려다 시작조차 못 하는 경우가 많습니다. 알고 싶은 것 하나를 정하고, 그 질문에 답하는 데 필요한 행동만 기록하는 방식으로 접근하면 됩니다. 한 바퀴를 돌고 나면 다음 질문이 생기고, 그것이 다음 기록 항목이 됩니다.

이벤트(Event): 사용자가 제품에서 한 행동을 기록한 데이터입니다. 장바구니에 담았다, 쿠폰을 조회했다, 결제 단계로 넘어갔다처럼 구체적인 행동 하나하나가 이벤트입니다. 기록하겠다고 정의해야만 쌓입니다.

택소노미(Taxonomy): 제품에서 어떤 행동을 어떤 이름으로 기록할지 정리해둔 목록입니다. 데이터 설계도에 해당합니다. 이것이 없으면 쌓인 데이터를 나중에 해석하기 어려워집니다.

퍼널(Funnel): 사용자가 목표 행동에 도달하기까지 거치는 단계입니다. 상품을 보고, 장바구니에 담고, 결제하는 흐름이 퍼널입니다. 각 단계가 이벤트로 기록되어야 어디서 이탈하는지 확인할 수 있습니다.

CRM: 고객의 행동에 맞춰 메시지나 혜택을 전달하는 활동입니다. 특정 행동을 한 사용자를 골라낼 수 있어야 가능합니다.

오늘의 Y’s Insight는 쿠팡·토스·크몽 등 프로덕트 회사에서 20년간 UX리서처로 일하며, 0-1 단계 스타트업부터 성장기 제품까지 고객의 문제를 직접 파악해온 멘토 Fred (서원용)님이 작성했습니다.

데이터가 없는 것과
정의되지 않은 것은 다릅니다

볼 데이터가 없다고 말하는 회사에도 숫자는 있습니다. 방문자 수가 보이고, 매출도 집계됩니다.

그런데 조금만 구체적으로 들어가면 답이 막힙니다.

어느 단계에서 이탈하는지, 장바구니에 담고 사지 않은 사람이 얼마나 되는지, 어떤 경로로 들어온 사람이 더 오래 남는지. 이런 질문에는 답할 수가 없습니다.

이유는 단순합니다. 그 행동들을 기록하겠다고 정한 적이 없기 때문입니다.

사용자가 버튼을 눌렀다는 사실은 누군가 "이 행동이 일어나면 이런 이름으로 남겨라"라고 정의해야만 데이터로 남습니다. 정의하지 않으면 그 행동은 일어났지만 기록되지 않은 채 사라집니다.

그래서 데이터가 없는 게 아니라, 아직 정하지 않은 상태입니다. 이 둘은 전혀 다른 문제입니다. 하나는 어쩔 수 없는 상황이고, 다른 하나는 지금 시작할 수 있는 일입니다.

한 번에 다 정하려다
시작하지 못합니다

이 문제를 인식한 조직이 다음으로 하는 일이 있습니다. 전체 설계를 먼저 하려고 합니다.

제품의 모든 화면을 훑으면서 기록해야 할 행동을 빠짐없이 뽑습니다. 이름 규칙을 정하고, 문서를 만들고, 검토 회의를 합니다.

그리고 대부분 여기서 멈춥니다.

이유가 몇 가지 있습니다.

무엇을 물어볼지 모르는 상태에서 뽑은 항목은 대부분 쓰이지 않습니다. 심어두고 한 번도 열어보지 않는 데이터가 쌓입니다. 문서는 길어지는데 분석은 시작되지 않습니다.

작업량도 문제입니다. 수십 개의 행동을 한꺼번에 개발팀에 요청하면 우선순위에서 밀립니다. 당장 만들어야 할 기능이 있는데 쓸지 안 쓸지 모르는 데이터 작업이 먼저 들어가기는 어렵습니다.

유지할 사람도 없습니다. 분석 인력이 없는 조직에서는 설계 문서를 관리할 주체가 애매합니다. 제품이 바뀌면 문서는 금방 현실과 어긋납니다.

완벽한 설계를 기다리다 1년이 지나는 경우를 여러 번 봤습니다.

알고 싶은 것 하나에서
시작하면 됩니다

순서를 바꾸면 훨씬 쉬워집니다.

지금 가장 답하고 싶은 질문 하나를 정합니다. "결제 단계에서 몇 명이 빠져나가는가" 같은 구체적인 질문이면 좋습니다.

그 질문에 답하려면 어떤 행동이 기록되어야 하는지 생각합니다. 결제 시작, 결제 완료. 두 개면 충분할 수도 있습니다.

그것만 요청합니다. 두세 개는 개발팀도 부담 없이 넣어줍니다.

데이터가 들어오면 차트를 만듭니다. 숫자를 보면 다음 질문이 생깁니다. "빠져나간 사람들은 어느 결제 수단을 선택했을까?" 그 질문이 다음에 정의할 항목이 됩니다.

이 방식의 장점이 있습니다. 쌓이는 데이터가 전부 쓰이는 데이터입니다. 질문에서 출발했기 때문에 반드시 들여다보게 됩니다. 그리고 한 바퀴를 돌 때마다 조직이 데이터를 보는 경험을 하게 됩니다.

느려 보이지만 실제로는 이쪽이 빠릅니다. 설계 문서를 만드는 몇 달 동안 아무것도 확인하지 못하는 것보다, 2주 만에 첫 번째 숫자를 보는 편이 낫습니다.

그로스는
함께 시작할 수 있습니다

데이터 환경이 완성된 다음에 그로스를 시작해야 한다고 생각하기 쉽습니다. 그럴 필요 없습니다.

이벤트 두세 개만 있어도 할 수 있는 일이 있습니다.

결제 시작과 완료가 기록되면 그 사이의 이탈률이 보입니다. 이탈률이 보이면 결제 화면에서 바꿔볼 것이 생깁니다. 작은 실험 하나를 돌려볼 수 있습니다.

사용자를 식별할 수 있다면 더 넓어집니다. 장바구니에 담고 구매하지 않은 사람을 골라낼 수 있고, 그 사람들에게 메시지를 보내볼 수 있습니다. 작은 CRM입니다.

중요한 건 완성을 기다리지 않는 것입니다. 질문 하나에서 시작한 데이터로 작은 실험을 돌리고, 그 결과를 보면서 다음 질문을 만들고, 그 질문이 다음 데이터를 부릅니다.

데이터 정의와 그로스는 순차적인 단계가 아닙니다. 같이 굴러가는 과정입니다.

지금 가장 답하고 싶은 질문 하나를 적어보세요.

"우리 사용자가 왜 안 살까"처럼 넓은 질문 말고, "결제 화면까지 온 사람 중 몇 명이 완료하는가"처럼 숫자로 답이 나오는 질문이어야 합니다. 질문이 구체적일수록 다음 단계가 쉬워집니다.

그 질문에 답하려면 무엇이 기록되어야 하는지 적어보세요.

대부분 두세 개면 충분합니다. 많이 적힌다면 질문이 아직 넓은 것입니다. 질문을 한 번 더 좁혀보세요.

그것만 개발팀에 요청하세요.

전체 설계 문서를 들고 가지 않아도 됩니다. "이 질문에 답하고 싶어서 이 두 개만 남기고 싶다"고 설명하면 훨씬 빠르게 진행됩니다. 목적이 분명한 요청은 우선순위에서 밀리지 않습니다.

이 방식에도 한계는 있습니다.

질문 단위로 하나씩 쌓다 보면 나중에 정리가 필요한 시점이 옵니다. 비슷한 행동이 다른 이름으로 기록되어 있거나, 기준이 조금씩 달라서 숫자를 합치기 어려워지는 경우가 생깁니다. 그때는 한 번 정비하는 작업이 필요합니다.

다만 그건 데이터를 실제로 보고 있는 조직이 된 다음의 문제입니다. 보는 사람이 있어야 정리할 이유도 생깁니다. 아무도 열어보지 않는 데이터를 미리 완벽하게 설계해두는 것보다는 나은 순서라고 생각합니다.

볼 데이터가 없다고 느껴진다면, 지금 가장 궁금한 것 하나를 정하는 것부터 시작하면 됩니다.