서비스를 운영하다 보면 어느 순간 "분석 도구를 하나 붙여 볼까요"라는 이야기가 나옵니다.
도구는 많고 소개 자료는 다 좋아 보여서, 막상 고르려면 기준이 없어 막막하더라고요.
그래서 도입 전에 제가 확인하려고 하는 세 가지를 정리해 보았습니다.
특정 제품을 추천하는 글이 아니라, 어떤 도구를 만나도 쓸 수 있는 질문 목록이에요.
첫 번째, 이 도구로 어떤 질문에 답하려는가
도구부터 고르면 거의 실패했던 것 같습니다.
먼저 우리가 답을 얻고 싶은 질문을 적어 보는 것이 순서예요.
예를 들어 "가입 화면에서 사람들이 어디서 나가는가"가 질문이라면, 단계별 이탈을 볼 수 있는 기능이 필요합니다.
"어떤 버튼이 눌리지 않는가"가 질문이라면 클릭 위치를 보여 주는 기능이 필요하고요.
"어떤 사람들이 다시 오는가"가 질문이라면 사용자 단위로 행동을 쌓아 주는 기능이 필요합니다.
질문 서너 개를 적고 나면 필요한 기능이 자연스럽게 정리됩니다.
그러면 소개 자료의 수많은 기능 중 대부분이 지금은 필요 없다는 것도 알게 돼요.
기능이 많은 도구가 좋은 도구가 아니라, 우리 질문에 맞는 도구가 좋은 도구입니다.
질문이 정해지지 않았다면 도구 도입을 조금 미루는 것도 방법이에요.
질문 없이 쌓인 데이터는 대시보드만 늘리고 결정은 늘리지 못하는 경우가 많았습니다.
질문을 적을 때는 그 답을 얻으면 무엇이 달라지는지도 같이 적어 봅니다.
가상의 예로 "결제 화면에서 이탈하는 사람이 많은 구간을 알면, 입력 항목을 줄일지 안내 문구를 바꿀지 정할 수 있다"처럼요.
답을 얻어도 할 수 있는 행동이 없다면 그 질문은 지금 우선순위가 낮은 질문일 가능성이 큽니다.
이렇게 질문마다 이어질 행동을 붙여 두면 도구 도입의 이유를 팀에 설명하기도 훨씬 쉬워져요.
두 번째, 어떤 데이터를 어떻게 수집하고 보관하는가
분석 도구는 사용자의 행동을 수집합니다.
그래서 무엇을 어디에 얼마나 보관하는지 확인하는 일이 꼭 필요해요.
제가 확인하는 항목은 이렇습니다.
수집하는 정보에 개인을 식별할 수 있는 내용이 포함되는가.
입력창에 사용자가 적은 글자가 그대로 기록되지는 않는가.
데이터가 어느 지역의 서버에 보관되고, 보관 기간은 얼마나 되는가.
사용자가 수집을 거부하거나 삭제를 요청할 수 있는가.
예를 들어 가상의 도구가 화면 녹화 기능을 제공한다고 가정해 봅시다.
그 기능이 비밀번호나 주소 같은 입력값을 가리지 않고 기록한다면, 편리함보다 위험이 더 커질 수 있습니다.
이런 경우에는 특정 입력창을 수집에서 제외하는 설정이 있는지 꼭 봐야 해요.
개인정보와 관련된 법적 요건은 나라와 서비스마다 다릅니다.
이 부분은 제가 단정해서 말할 수 없고, 반드시 담당자나 전문가와 함께 확인해야 합니다.
기획자가 할 수 있는 일은 확인해야 할 질문을 먼저 꺼내 놓는 것이라고 생각해요.
이용 약관과 개인정보 처리 방침에 수집 사실을 알리는 문구가 필요한지도 같이 확인합니다.
세 번째, 우리 팀이 실제로 쓸 수 있는가
도구가 좋아도 팀이 쓰지 않으면 비용만 나갑니다.
저는 이 부분에서 세 가지를 물어요.
누가 설정하는가.
처음 설치하고 이벤트를 정의하는 일은 보통 개발자 도움이 필요합니다.
개발 일정에 이 작업이 들어갈 자리가 있는지 확인해야 해요.
누가 매주 보는가.
보는 사람이 정해져 있지 않으면 도구는 점점 잊힙니다.
주간 회의에서 한 번은 열어 보는 시간을 정해 두면 좋았습니다.
비개발자도 읽을 수 있는가.
화면이 복잡해서 분석가만 이해할 수 있다면 기획자나 디자이너가 쓰기 어렵습니다.
체험판이 있다면 실제 업무 질문 하나를 넣어 보고, 혼자서 답을 찾을 수 있는지 시험해 보세요.
비용도 함께 따져 봐야 합니다.
처음 가격만 보지 말고 사용자 수나 데이터 양이 늘면 요금이 어떻게 달라지는지 확인해요.
서비스가 커질수록 도구 비용도 같이 커지는 구조라면, 나중에 도구를 바꾸기 어려워질 수 있습니다.
그래서 수집한 데이터를 내려받아 다른 곳으로 옮길 수 있는지도 미리 물어 두면 좋아요.
계약이나 가격 조건은 도구마다 다르니, 담당자에게 직접 확인하는 것을 권합니다.
처음부터 모든 것을 측정하려고 하면 지칩니다.
저는 핵심 행동 서너 개만 정의해서 시작하는 것을 권하고 싶어요.
가령 가입 완료, 첫 구매, 핵심 기능 사용 정도만 먼저 정합니다.
이 세 가지가 안정적으로 쌓이는 것을 확인한 뒤에 하나씩 늘려 가요.
이렇게 하면 도구를 바꿔야 할 때도 옮겨야 할 양이 적어서 부담이 줄어듭니다.
이벤트 이름도 처음에 규칙을 정해 두면 좋습니다.
"가입_완료"와 "회원가입끝" 같은 이름이 섞이면 나중에 분석하는 사람이 같은 행동을 다른 것으로 오해하게 돼요.
이름을 정하는 규칙을 한 장짜리 문서로 남겨 두고, 새 이벤트를 추가할 때마다 그 문서를 먼저 고치는 습관을 들이면 데이터가 훨씬 깔끔하게 쌓입니다.
이 문서는 기획자가 맡기 좋은 일이라고 생각해요.
분석 도구 도입은 기술 선택이기 전에 팀이 무엇을 알고 싶은지 정하는 일이라고 생각해요.
질문, 데이터 관리, 팀의 사용 가능성 세 가지만 확인해도 시행착오가 많이 줄 것 같습니다.
아직 생각이 정리되지 않은 질문도 있습니다.
도구를 여러 개 쓰면 같은 지표가 도구마다 다르게 나오는 문제를 어떻게 다루면 좋을까요.
그리고 무료로 시작했다가 규모가 커지면서 유료로 넘어가는 시점을 어떻게 판단하면 좋을까요.
이 부분은 실제로 부딪혀 보면서 계속 기록해 둘 생각입니다.
'Planning · PM > 일하는 방법' 카테고리의 다른 글
| 리모트 협업 툴 비교 (Notion, Jira, Confluence) (0) | 2020.09.13 |
|---|---|
| 서비스 기획서 템플릿 - 내가 쓰는 방식 (0) | 2020.08.29 |
| 화면정의서(스토리보드) 작성 노하우 (0) | 2020.07.16 |
| 프로토타이핑 도구 고르는 기준 (0) | 2020.06.09 |
| 웹 서비스 기획 시행착오와 도구 정리 (1) (0) | 2020.06.09 |