데이터의 흐름과 용도를 생각하는 기획
맨땅에 데이터 나오지 않는다
책임님, 저 궁금한 게 있는데요
평균 구매 전환율, 위시리스트 전환율, 장바구니 전환율, 위시리스트 유입수, 장바구니 유입수, 평균 위시리스트 상품수, 평균 장바구니 상품수 알려주세요
메신저에 갑자기 폭탄이 날아들었다. 한 의욕 넘치는 인턴 친구가 던진 폭탄이었다. 뭔가 기획과제를 받은 모양이었는데 데이터를 충분히 보고 기획하라고 조언을 했더니 이런 질문을 보내왔다. 내부에서 사용하는 애널리틱스 화면을 봐도 잘 모르겠으니까 물어본 듯했다. 그렇지만 이 메시지를 받은 나로서는 본인이 폭탄 인지도 모르고 던진 폭탄이라 더 아팠다.
저 정상적이고 의욕적인 질문이 폭탄인 이유는 사실 이런 '데이터의 탄생'이 생각보다 많은 고민과 노력에 의해서 만들어지기 때문이다.
폭탄 맞은 마음을 부여잡고 인턴에게 회신을 보냈다.
제가 정말 바로 대답해주고 싶지만, 이것만으로는 데이터를 뽑아 줄 수가 없어요.
평균의 기간은 어떻게 돼요?
구매 전환율의 기준 공식은요?
유입수는 PV 기준인가요 UV 기준인가요?
이 데이터를 뽑아서 보려는 목표는 무엇이죠?
인턴은 당황했다. 그런 기준은 이미 정해져 있는 것 아니냐고 물었다. 물론 생각해보지 못했다며 대답도 하지 못했다.
그래도 인턴이니까 목적이나 목표를 꼬치꼬치 캐물은 뒤 내 나름대로 기준을 정리해서 이 자료를 최대한 뽑아줘서 보내줬다. 하지만 단 하나의 자료도 쉬운 게 없었다. 야근을 하며 따로 시간을 내야 했다. 원하는 목표에 적합한 데이터를 뽑는 건 아무리 애널리틱스가 있어도 기준에 맞춰 가공이 필요하기 때문이다. 게다가 일부는 수집하고 있지 않아서 아예 구할 수조차 없었다. 인턴이 퇴사 전에 확인할 수 있길 바라며 수집을 위한 개발 요청서도 넘겨야 했다.
맨땅에 데이터 나오지 않는다
구글 애널리틱스와 같은 BI(businese intelligence) 프로그램에 대한 중요성이 논해지면서 모든 기획자들이 데이터를 이야기한다. 그리고 우리 회사는 해석할 데이터가 없다며 한탄하기도 한다.
하지만 지금 볼 만한 데이터가 없다고 해서 오늘 당장 구글 애널리틱스를 도입하겠다고 결정한다고 해도 당장 내일 볼 만한 데이터는 생겨나지 않는다. 데이터를 모으기 위해서도 데이터를 해석하기 위해서도 기획과 개발이 필요하기 때문이다.
구글 애널리틱스의 도입을 예로 들어보자. 가장 먼저 해야 할 일은 구글에 가서 가입을 하는 것이다. 하지만 이렇게 한다고 나올 데이터는 없다. 화면 내의 영역별 클릭수를 보려고 해도 적어도 몇 가지 절차를 거쳐야 한다.
웹과 앱 내에 구글 제공 스크립트나 SDK삽입
각 화면 영역별로 클릭수 체크를 위한 파라미터 값 정의
영역별로 해당 파라미터 삽입되도록 개발
정상 수집 테스트 및 부하 테스트
웹과 앱 배포 및 데이터 정상 수집 여부 확인
이렇게 하면 적어도 화면 내의 특정 영역에 대한 클릭수 체크는 가능해진다. 물론 이렇게 하는 것도 운영 서비스가 크면 클수록 오래 걸릴 수밖에 없다.
하지만 이 정도로는 인턴이 말한 '구매전환율'은 구할 수가 없다. 구매전환율을 구하려면 명확한 기준에 대한 기획 절차가 있어야 한다.
목적에 맞는 데이터가 필요하다
데이터 활용을 위해서 가장 중요한 부분은 기준을 마련하는 일이다. 구글 애널리틱스에서 클릭 클릭해서 원하는 데이터 값이 나온다면 누군가가 그 페이지에 기준을 잡아놨단 소리다. 그러면 도대체 그 기준은 '누가' 그리고 '어떻게' 정했냐는 것이 그 데이터의 활용에 핵심이 된다. 아무리 이름이 같은 데이터라고 해도 내가 생각한 가설과 완전 다른 데이터라면 목적에 맞춰 활용할 수가 없다. 즉, 데이터는 생성되기 전부터 활용 목적이 분명해야 한다.
이 개념이 바로 '빅데이터(Big Data)'에 대해 활용 가능한 데이터인 '스몰데이터(Small Data)'의 개념이라고 할 수 있다. 사실 아무것도 하지 않아도 데이터가 쌓이긴 쌓인다. 그러나 주문 데이터처럼 명확한 데이터를 제외하고는 모든 화면에서 모든 사람의 로그를 쌓아놓진 않는다. 만약에 쌓아놓는다고 해도 가설이 없이는 해석이 불가능한 데이터다.
이 지점에서 어떤 데이터도 해석할 수 있을 것만 같은 '데이터 사이언티스트'가 출현한다. 이름만 보면 연금술사처럼 데이터를 만들어줄 것 같지만 그들의 역할은 명확하다. 운영하는 서비스의 데이터를 쌓는 방식을 나중에 활용 가능하도록 설계해주고 또 이미 쌓아놓은 데이터를 명확하게 분석하는 것에 도움을 주는 것이다. 그리고 이 과정에서 여러 가지 분석 툴이자 파이썬 같은 개발언어가 등장한다. 능숙한 데이터 사이언티스트는 이런 데이터를 갖고 놀면서 구글 애널리틱스보다 좀 더 합목적적인 데이터를 만들어준다. 하지만 이런 전문적인 데이터 사이언티스트가 없다면 결국 목마른 사람이 우물을 파야한다.
맨날 목마른 사람은 뭔가 분석하려는 기획자뿐이다.(물론 기획 능력이 있는 개발자와 디자이너도 포함)
쓸만한 데이터를 뽑아내기 위해서
'가설의 우물' 파는 기획자
다시 우리 인턴의 요청으로 돌아와 보면 우리 인턴은 무엇을 했어야 했을까? 데이터를 내가 뽑아주든 개발자가 뽑아주든 BI로 찾아봤든 그것은 중요하지 않았다. 가장 먼저 데이터에 대한 가설이 있어야 했다.
덮어놓고 이 화면에 대한 데이터를 다 뽑아본다면 뭔가 나오지 않을까 생각했던 적이 나도 있었다. 하지만 그런 중구난방 데이터를 모두 뽑는 것도 어렵지만, 보통 의미 있는 데이터는 원데이터(raw data)인 1차 데이터가 아니라 가공된 2차 데이터였다. 인간이 데이터를 다 꺼내놓고 규칙을 찾는다는 것은, 딥러닝 하는 AI가 아니기에 도리어 비효율적이다. 우린 AI처럼 다방면으로 사고할 수 없다. 다만 우리는 여러 가지 비즈니스에 대한 이해를 바탕으로 가설을 검증하는 것을 반복하는 것이 도리어 효율적이다.
인턴이 말한 '위시리스트 페이지의 구매전환율'이란 항목도 분석 목적에 따라 얼마든지 기준이 변경될 수 있다.
1) 위시리스트 대비 주문 완료 비율 확인 시 =주문 완료 페이지 PV / 위시리스트 PV
: 페이지간 접속률 비율일 뿐 특별한 가설이 안된다.
2) 위시리스트를 통해서 주문 완료된 건수 비율
=위시리스트를 통해서 일어난 주문 완료 건수/위시리스트 PV
: 이런 케이스도 목적에 따라 데이터가 또 달라질 수 있다. 주문에 영향력을 보고 싶다면 주문 후 취소 건수는 제외해야 할 지도 결정해야 한다. 반면 이 케이스에 대한 주문서 UX에 대한 적합도 판단을 하려면 위시리스트 PV대신에 위시리스트에서 '주문하기'버튼을 클릭한 클릭수를 분모로 삼고 분자에는 취소된 주문건수까지도 모두 포함해야 한다.
이렇게 깊게 고민해본다면 데이터를 뽑는 시기도 고민의 대상이 되어야 한다. 값싼 생활용품이 많이 팔리는 7~8월과 여기저기 선물을 줘야 하는 5월, 사랑하는 사람을 위해 심사숙고해서 선물을 사는 12월은 너무나 다르다. 게다가 명절이나 연휴 같은 변수는 당연히 사용자의 Context를 다르게 하고 데이터에 대한 가설도 달라져야 한다.
가설이 없는 데이터에는 맹점이 있다
아무 조건 없이 그냥 남이 만들어놓은 데이터를 무조건 믿는다면 어이없는 결과를 만들어 낼 수도 있다.
인턴이 말한 것처럼 BI에서 관리되는 '구매전환율'이 있긴 있었다. 하지만 이건 회원당 구매로의 전환율을 보기 위한 거시적 목적의 데이터로 UV 기준으로 한 달 동안 평가된 것이었다. 그러니까 한 달을 기준으로 100번을 와서 1번 구매한 사용자와 우연히 1번와서 1번 온 사람이 동질로 여겨지는 데이터였다.
인턴처럼 단순 페이지를 보려는 사람이 이 데이터를 기준으로 삼아서 데이터를 비교했다면 어떤 결론이 내려질까? 어떤 결론을 내린다고 해도 데이터의 전제조건이 맞기 않기에 겉보기만 그럴듯한 데이터의 맹점에 빠질 수 있었다
인턴을 위해 새로 수집 요청한 데이터는 겨우겨우 인턴이 퇴사하기 직전에 배포가 되었다. 그 친구가 나갈 때까지 겨우 몇일치에 준하는 데이터만 수집되었다. 며칠 되지도 않고 비교대상도 마땅치 않은 이 데이터가 분석의 가치가 있다고 봐야 할까?
데이터를 생각하는 기획자
언제 보아도 빵빵한 데이터가 있는 서비스가 되려면 어떻게 해야 할까?
지금까지 주로 분석을 위한 데이터에 대해서만 이야기했지만 데이터에는 2가지가 있다.
첫째, 기능이 작동되기 위해 필수적인 데이터
둘째, 분석을 하기 위해 별도로 쌓은 데이터
기능을 위한 데이터는 이를 테면 '기획의 확장성'을 이해하는 데이터다. 보통 기획자가 형태에 대해 단독으로 결정할 문제는 아니지만 기획자가 나중에 활용도까지 생각해서 개발 담당자들에게 제안할 수는 있다.
예를 들어, '이미 봤던 상품'의 데이터를 보여주는 영역이 있다고 해보자. 단순히 화면 기획만 넘긴다면 개발자가 이 데이터를 쿠키로 쌓든 DB에 쌓든 데이터를 쌓는 위치도 기획자는 모르고, 상품코드로 쌓든 아니면 상품명 자체를 복사해서 저장하든 오로지 개발 효율과 시스템 여건을 고려한 선택이 된다.
하지만 애초에 이 데이터를 기준으로 다른 개인화 페이지를 확장한다든가 아니면 모든 디바이스에서 동일하게 보여야 한다는 기준을 제시한다면 어떨까? 개발자도 최대한 그 목적과 의도에 맞게 코드화 시켜주고 데이터의 저장 방식도 고려 해줄 것이다.
즉, 기획자는 화면만 기획하는 것이 아니라 '데이터의 확장성'까지 고민해서 기획한다면 함께 일하는 개발에서 데이터를 다루는 청사진을 그리면서 설계할 수 있도록 협의할 수 있다.
분석용 데이터를 위해서도 서비스의 기획 과정부터 고민 해야 한다.
2015년에 모바일 리뉴얼 프로젝트를 진행하면서 가장 크게 생각했던 고민은 바로 이것이었다. 분석해서 내밀 데이터가 없던 우리 팀장님과 기획자들은 모든 모바일 화면 구석구석에 분석할만한 데이터를 심어보자고 작정했다. 각 항목의 클릭수는 물론이고 화면 URL 이동 없는 탭 변경이나 스와이프까지도 어떻게든 수집해보려고 했다. 그리고 이 작업을 위해 페이지별로 가설을 세웠다.
제일 기억에 남는 페이지는 '딜 매장'의 측정용 데이터였다. 주욱 상품이 늘어놔 있을 때 상품의 순번 별 클릭수를 기록했고 스크롤할 때 추가로 더 호출해올 때마다 도 수가 쌓이도록 했다. 이렇게 상품이 주욱 늘어져있을 때 어디까지 의미 있는 상품인지를 파악하고 고객의 눈높이 내에서 효율성 있는 UI를 고민하기 위해 구상했던 데이터였다. 이 덕분에 무절제하게 상품수를 늘리는 것을 막을 수 있었던 좋은 경험이 있다.
쓸만한 데이터는 만들어야 한다
쓸만한 데이터는 갑자기 맨땅에서 나오는 것이 아니다. 데이터 사이언티스트이든 기획자이든 개발자이든 누가 시작을 제안 하는 것은 중요하진 않다. 그저 화면을 만드는 시점부터 보이는 영역뿐 아니라 데이터에 대해서도 가설을 세우고 고민한다면 필요한 시점에 적절한 데이터를 얻을 수 있다.
나에게 데이터 폭탄을 안겨준 그 친구가 인턴이 아니라 신입이었다면 스스로 원하는 데이터를 만들어내는 것부터 그 데이터를 분석해서 개선하는 것까지 해볼 수 있었을 텐데, 그걸 못 가르쳐준 것이 못내 아쉽다.
