데이터의 바다에서 살아남는 PO의 수영 방법 - 1편
데이터 바다의 첫 번째 파도, 데이터 수집
Product Owner가 갖추어야 할 필수역량에 빠지지 않는 키워드가 하나 있습니다. 바로 데이터입니다.
저 또한 누군가 데이터의 중요성에 대해 수백 번을 강조한다고 해도 고개를 끄덕일 자신이 있을 정도로 데이터를 신뢰합니다. 이제는 데이터 없이 그 어떤 의사결정도 내리면 안 된다고 느껴질 정도로 모든 기업들도 데이터 마인드셋을 강조합니다. 대기업부터 스타트업까지 모든 기업이 똑같습니다. (물론 직관이 훨씬 무서울 때도 많고, 직관에 의한 의사결정도 아직은 많습니다. )
특히 Product Market Fit을 찾아야 하는 PO라면 더더욱 데이터가 중요하죠. 정성적 (Qulitative) 데이터와 정량적 (Quantitative) 데이터를 아우르는 데이터의 바다에서 살아남아야 합니다.
그런데 제 문제는, 백그라운드 중에 데이터와 관련된 것은 아득히 먼 옛날 대학교 전공 수업으로 들었던 기초통계학이 전부라는 것. 그 마저도 하나도 기억이 나지 않습니다. 그래서 당최 ‘데이터’를 어떻게 수집하고, 분석하고, 해석해야 하는지 정말 하나도 모르겠다고 느낀 적이 한두 번이 아닙니다.
왜 공부를 안 했니... 왜!!그렇다면 방법은 배우거나, 배우거나, 배우거나…!!
네, 그래서 열심히 배우고 있습니다!
최근에는 Amplitude라는 솔루션을 사용하면서 Event, Event Property, User Property를 위한 Taxonomy를 설계할 일이 많아졌고, 데이터의 수집이라는 첫 단계부터 제대로 정면돌파 중입니다. 특히 앱 환경에서의 데이터 수집 세팅은 처음이라서 여러 가지 방식으로 가장 신뢰할 수 있는 데이터, 정합성이 높은 데이터를 수집하기 위해 실험을 하고 있습니다. 그리고 이렇게 맨몸으로 부딪혀가며 배우면서 깨달음을 얻고 있습니다.
오늘은 데이터의 수집에서 깨달은 두 가지 중 하나에 대해서 써보려고 합니다. 두 번째 깨달음도 곧 한 번 써볼게요.
데이터를 수집하는 목표를 명확하게 하자
처음 Taxonomy를 설계할 때 범했던 큰 실수 중 하나가, 스프린트 하고 있는 기능과 관련된 최대한 많은, 그리고 다양한 이벤트를 수집하려고 한 것이었습니다. 명백한 목표가 없이 ‘발생하는 이벤트’이기 때문에 Taxonomy를 설계했기 때문에 불필요한 데이터가 마구 쌓여갔습니다. 그리고, 막상 수집해놓고 보니, 제대로 활용이 되지 않거나 정합성이 떨어지는 데이터도 많았죠. 나름대로 중복 없이 데이터를 수집하자고 했지만, 막상 뚜껑을 열어보니 하나의 event와 event property로 여러 데이터를 뽑아낼 수 있는 경우도 생겼습니다. 낭비 제거가 중요한 스타트업에 여러 낭비를 만들어냈습니다.
이때 깨달은 것이 데이터를 수집하는 목표가 중요하다는 것이었습니다. 낭비를 제거하는 관점도 있지만, 이번에 수집할 데이터가 무엇을 측정하기 위한 것이고, 해당 데이터가 유저의 어떤 흐름과 행동을 의미하는지 파악하지 못하면 쓸모없는 쓰레기 데이터가 되어버리고 맙니다.
잘못하면 쓰레기 바다에서 춤추고 있을지도…예를 들어, 앱에서 유저에게 앱의 주요 기능에 대한 푸시 알림을 해주는 feature를 새로 개발한다고 가정해 보겠습니다. 여기에는 푸시 알림을 on/off 할 수 있는 기능과, 푸시 알림을 받을 요일과 시간을 정할 수 있는 기능까지 포함이 됩니다.
자, 이제 유저가 푸시 알림을 보고, 설정하고, 메뉴에서 exit 하는 여정을 그려봅니다.
엡의 기존 유저에게 푸시 알림을 설정을 유도할 것이기 때문에 앱 내에서 푸시 알림 설정에 대한 팝업을 띄울 예정입니다. 그렇다면 팝업을 보고 반응을 했는지 안 했는지도 수집할 수 있는 Event네요. 그다음은 푸시 알림 설정 페이지 내에서 알림 설정을 on으로 변경하는지, 또는 off로 변경하는지 Event를 발생시킬 수 있고, on일 경우 설정한 요일과 시간에 대한 Event Property도 수집할 수 있을 것 같습니다. 푸시 알림 설정 여부에 따라 User Property도 수집할 수 있습니다. 만약 설정하지 않는 유저라면, 설정 없이 벗어나는 Event도 수집이 가능할 것 같습니다.
간단하게만 봐도 수집할 수 있는 Event, Event Property, 그리고 User Property가 이렇게나 많습니다.
그런데 이 데이터들을 수집하는 이유가 명확하지 않다면, 언제 다시 이 데이터를 사용하게 될까요? 분명 모두 의미가 있는 데이터입니다. 그리고 추후에 유저의 행동과 흐름을 파악하기 위해 반드시 필요한 데이터도 있습니다. 하지만, 이 모든 데이터가 앱에서 유저에게 푸시 알림을 해주려는 목표와 그 목표에 대한 해답을 준다고 할 수 있을까요?
푸시 알림의 목표가 리텐션이었다고 가정한다면 가장 중요한 데이터는 ‘푸시 알림을 설정한 유저의 리텐션’을 측정해야 됩니다. 그 이외의 데이터는 우선순위가 다릅니다. 하나하나 정확하게 측정할 수 있다면 너무 좋겠지만, 스타트업에서는 수많은 데이터를 모두 정제하고 분석할 수 있는 리소스가 부족합니다.
그래서 명확한 목표와 목표의 달성할 수 있는 데이터 수집에 집중해야 합니다.
부족한 리소스이지만 최대한의 효과를 내는 것이 스타트업에게는 숙명입니다. 그리고 스타트업의 이러한 특성상 최소한의 낭비, 그리고 낭비의 제거는 굉장히 중요합니다.
데이터를 바라보는 관점도 마찬가지입니다.
1. 정말 필요한 데이터만 수집하고 검증하거나
2. 모든 데이터를 수집해서 모든 데이터를 검증하거나
낭비되는 데이터가 없기 위해서는 둘 중 하나를 택해야 합니다. 하지만 리소스가 부족한 상태에서는 모든 데이터를 검증하려다가 하나조차 제대로 검증하지 못하게 될 가능성이 높습니다.
특히 시간이 곧 생명이고 생존인 스타트업에서는 더더욱!
그렇기 때문에 저는 정말 필요한 데이터만 수집하고 검증하는 첫 번째 방법으로 이 데이터의 바다에서 헤엄치고 있는 것이죠.
언제나 그렇듯 제 방법이 완전한 정답은 아닙니다.
하지만 개헤엄이라 할지라도 데이터의 바다에서 살아남게만 해준다면 자유형을 거쳐 접영을 마스터할 날이 반드시 올 겁니다!
마스터가 될 때까지! 잃지 말자 미소!오늘 글은 스타트업의 제한적인 리소스가 중요한 전제입니다.
데이터 전문가 분들이 계신 곳에서는 완전 다른 방식으로 데이터를 수집하실 겁니다.
데이터 관련해서는 앞으로도 맨몸으로 부딪히면서 배워가는 단계에 얻게 되는 소소한 느낌표(!)를 나눌 계획입니다.
데이터를 전문적으로 다루시는 분들이 보시기에 많이 부족한 글일 테지만,
어떻게 보면 전문가 분들께 날리는 저의 SOS와도 같으니 노여워 마시고 피드백 부탁드립니다 :)
감사합니다.
