티스토리 뷰
학생 때, DB / 데이터 마이닝 / CRM 등등 데이터 분석 관련한 공부를 하였다. 졸업하고 포털업체에서 기획 업무를 하다보니 데이터 분석쪽으로는 공부할 기회가(내가 기대했던 데이터 분석) 많지 않았다. 담당 서비스의 포지션 이유도 있었다. 전략안 작성을 위한 지표 분석 보고를 하지만, 지금 생각해 보면 "데이터 분석"이라는 말은 어색한 것 같다. 사회조사분석가를 공부하면서 다시 통계(데이터 분석)을 공부했다. 공부가 끝나고 나니, 다시 데이터 분석을 할 일이 없어졌다. "방법"에 대한 공부 일 뿐, 현업에 적용하고 시뮬레이션 해 볼 수 있는 "데이터"를 내 손에 쥘 수 없다는 아쉬움이 컸다. 그래서, 늘 필요성을 느끼지만 공부는 깊게 하지 못했다.
이번에 시작한 프로젝트에서 "통계" 라는, 이름이 붙여진 영역을 담당하면서 "내 손에 쥘 수 없었던 데이터"에 대해서 한번 더 생각하게 되었다. 나중에 "통계"라는 영역을 다시 담당하거나 "통계"가 중요한 서비스를 기획하게 될 때 시간을 아껴보고자 고민했던 것들을 정리하였다.
만들려는 서비스가 뭐야? Actor는 누구야?
가장 기본이 되는 것을 명확하게 정의 해야한다.
모든 서비스의 데이터를 분석하기는 어렵다. 서비스 분석 시 기준이 없으면, 데이터 분석의 범위가 너무 커질 수 있다. 그래서 서비스를 매우 간단하게 정의하고, 어떤 Actor들이 존재하는지 정의해야한다. 예로 블로그&SNS 서비스는 "콘텐츠 생산 서비스" 로 정의하고, Actor는 콘텐츠 생산 User와 콘텐츠 소비 User로 나눌 수 있다. 그리고 모든 서비스에는 Administrator가 있다. Actor의 중요도(User를 위한? Administrator를 위한?)까지 서비스 유형에 따라 정의해야 한다.
서비스에서 가장 유의미한 데이터는 무엇일까?
서비스에서 발생하는 데이터들을 분석했을 때, 가장 의미 있는 것은 무엇일까? SNS에서 발생하는 가장 의미 있는 데이터는, 콘텐츠 생산자와 소비자와의 상호작용에서 발생하는 데이터라고 생각하였다. 미디어형 서비스에서 의미 있는 데이터는, User가 소비하는 콘텐츠에 대한 정보일 것이다. 상호작용&콘텐츠 등은, 그 서비스가 가진 에지를 지속하게 만들고, 업데이트되는 요소들이다. 이러한 요소들을 이해하고, 분석한다면 서비스 생명주기가 길고 효과 높은 개선를 할 수 있을거라 생각한다.
내가 생각한 통계에 오류가 있다? 없다?
Actor의 Activity로 얻어지는 데이터는 객관적 데이터일까? Activity로 얻어지는 데이터는 항목에 따라 분류하면 객관적일수 있다. 하지만 분석하는 사람에 따라 다른 결과가 나올 수도 있기 때문에 주관적이라 말할수도 있다.
개인적으로는, 분석을 통해 나온 통계는 객관적인 데이터라 생각한다. 분석 시각이 사람마다 다르다하더라도, 분석을 시작한 RAW 데이터는 변화하지 않기 때문이다. RAW 데이터를 바탕으로 사람마다 다른 분석 결과를 내놓는 것은 자연스러운 일이며, 서로가 오류를 찾기 위한 의견을 나누어야 한다.
어떤 통계에 집중해야할까?
User가 스스로 오류를 찾고, 의견을 나누기란 어렵다. 그래서 서비스 제공자는 User가 200% 서비스를 활용할 수 있도록, "서비스 이용에 대한 방향"을 제시하는 통계 리포트 제공해에 집중해야 한다.(하고 싶다!!!) Administrator에게도 서비스의 전략과 방향성을 제시할 수 있는 통계 리포트가 제공되어야한다. 앞으로는, Actor에게 제언 할 수 있는 통계에 집중하려 한다.
통계 제공 목적이 뭐냐!
제공하려는 통계를 분류하고 정리할 때, 목적에 따라 분류한다. 목적별로 우선순위를 정하는 작업도 필요하다. 물론 프로젝트 전체에서 통계 기능의 우선순위를 고민하는 것도 중요하다. 프로젝트는 제한된 일정과 한정된 리소스 환경에서 진행되기 때문에 목적과 우선순위를 고려하여, 제공하려는 통계 기능의 타당성을 검증해야 한다.
서비스 생산성, 서비스 활성화, USER 활동성, 플랫폼 통계, 플랫폼 개선, 콘텐츠 운영 효율화, 플랫폼 성장성...등등
수집되는 데이터의 중복성을 제거하자!
통계 항목에 따라 수집되는 데이터를 정의하고 나열하면, 중복되는 요소가 보인다. 중복으로 수집되어, DB에 중복 저장되지 않도록 문서에 표기하는 것이 커뮤니케이션 하기 편리하다. 중복성 제거를 할 때, 데이터 요소가 쪼개지지 않을 때까지 원시화 하는 과정이 수반되어야 한다. 데이터 요소의 원시화를 하지 않으면, 데이터 A와 a가 다름에도 중복 수집으로 착각하게 된다. 중복 제거 후 원시화한 요소들을 나열하고, 수집하려는 데이터와의 엔터티를 표현하면 수집할 데이터가 명확하게 보인다. (데이터의 원시화 = 메타 데이터 정의)
중복 제거하고 보니, 수집대상이 줄었다!
기획자도 통계 시스템의 구조를 이해하자!
구글에서 "통계 시스템 구조"로 검색하면, 이미지 검색결과에 수 많은 통계 시스템 구조도가 나온다. 2페이지 정도만 보면, 구조도가 2~3개로 통일된다. 프로젝트에서 개발하는 통계 기능은 대부분 2~3개 방법으로 설계되는 것으로 생각해도 될 듯 하다.
OO 시스템, 수집, 분석, 리포팅, DB, DBMS, RAW 데이터 조회, SOAP, HDSF...이런 용어들을 많이 접하게 된다. 이를 물리적/논리적 용어로 구분하고, 용어간의 종속관계를 정의하다 보면 대부분의 통계 시스템 구조는 동일한 CYCLE를 가지고 있는 것을 알 수 있다.
시스템 구조에 FLOW를 넣었더니, 대부분 이렇더라!
자주 발생하는 오류들 (또는 해결하지 못할 것 같은 과제들)
①데이터 분석은 애자일하게 진행되는게 맞다. 그런데 통계 시스템은 완성된 그림을 그려놓고 진행하는게 맞는것인가? 통계 시스템 역시 애자일하게 디벨롭 되어야 한다. 처음부터 완벽한 통계시스템을 그려놓으면, 통계 기능때문에 서비스 오픈이 지연될 수 있다.
②통계 리포트 제공이 주요한 목적인 아닌 서비스인 경우에는, 개발 난이도를 고려할 수 밖에 없다. 또한 우선순위에서 밀려날수 밖에 없다. 하지만 오픈 후 가장 중요한 것은, 성과를 측정할 수 있는 리포트이기도 하다. 프로젝트 초기에 통계 기능의 우선순위를 결정해야 한다. 근데 어렵다. 다들 하고 싶은게 있을테니깐...적어도 주객전도는 하지 말자!
③히트맵, 레퍼러 체크, 클릭 이벤트 등 분석해도, UX 만족도 체크가 어려운 화면들이 있다. 이런 화면들은, 처음부터 복잡하게 기획 되었을 가능성이 높다.(대부분이 그랬다!) USER에게 너무 많은 액션을 요구하는 화면도 아닌듯...
기획 일을 하면서, 가이드나 신념처럼 가지고 있는 생각들이 있다. 그중 하나는 "내가 하는 생각이 틀렸을 수도 있다" 라는 생각이다. 최근 읽은 "데이터 인사이트" 라는 책에 같은 말이 있었다. 데이터 분석에 대해 고정관념처럼 가지고 있던 나의 생각들을 바꾸게 만든 책이다. "아하!" 할 만한 명언들도 많이 있으니 시간 여유가 된다면 출퇴근 길에 한번씩 읽어보길 권장합니다! (책 홍보 아님.헌터 휘트니랑 아는 사이일리가 없음) 책은 [데이터 인사이트, 헌터 휘트니 지음] 이다.
