분석 리포트 까지의 단계는 다음과 같다.
[0] 문제 정의 → [1] 실험 기획 → [2] 개발(+QA) → [3] 분석 및 공유
[0] 문제 정의
문제 발견 → 문제 정의 → 문제 크기 판단 → 가설 수립 으로 세부적으로 나눠볼 수 있다.
•
문제 발견
•
문제 정의 : 문제로 보이는 현상에 대한 원인을 정의
•
문제의 크기 판단 : 해당 문제로 인해 불편함을 겪는 사람이 얼마나 많은지 파악해 액션의 임팩트 크기를 확인한다. 실행 배경이지만 정성적 정보 + 정량적 정보가 함께 결합되어야 한다.
•
가설 수립 : 원인을 해소할 수 있는 방법과 그에 따른 기대 효과를 문장으로 정의
문제 정의 및 우선 순위 판단
왼 - 29cm에서 제공하는 사이즈 고민에 대한 현솔루션, 오- 고민이 해결되지 않는 원인에 따른 문제 정의
출처 : https://medium.com/29cm/목적-조직에서의-da가-하는-일-bc4cf2535a89
→ 문제 원인에 대해 추정했다면, 그 원인을 추적할 수 있는 지표를 확인해나가기
❗️ 주의해야 할 점 
원인 A를 보여줄 수 있는 지표가 다른 이유로 인해 영향을 받을 수 있다는 가능성을 확인해봐야 함
[0] 실험 기획
문제 해결을 위한 UX 디자인이 완료된 후, 이제 정의한 문제가 실험군의 변경사항(treatment)으로 인해 해결되었음을 증명할 수 있는 실험을 설계해야 한다.
1. 지표 설정
성과 측정을 위해 적절한 지표를 선정해야 한다.
•
primary metric : 문제가 해결되면 변화할 것으로 예상되는 지표
•
secondary metric : primary metric 을 더 잘 이해할 수 있는 보조 지표
•
guardrail metric : 해당 실험으로 인해 부정적인 영향을 받을 수 있는 지표. 또는 궁긍적으로 부정적인 영향을 받아서는 안되는 사용자 경험 지표
좋은 성과 지표란?단기간이 측정 가능하고 민감하게 반응하며 장기 목표에 영향을 미치는 특성을 갖춘 것이 좋다.
2. 롤아웃 시나리오 작성
지표의 변화에 따른 의사결정(롤아웃, 롤백)을 어떻게 할 것인지에 대한 시나리오를 작성한다.
장점은 1) 적절한 지표를 설정했는지에 대한 재점검과 2) 의사결정의 일관성 확보라는 2가지가 있다.
즉, primary metric 과 secondary metric 의 변화에 따라 행동을 해석해서 적어보면, 설정한 지표에 대한 재점검이 가능하다. 해당 지표가 맞는지, 또는 단일 지표로는 확인이 불가능한 경우 보완 지표가 필요한지 등의 여부를 알 수 있다. 더 나아가 추가로 관찰해야 하는 지표가 있는지도 미리 고려해볼 수 있다.
더 나아가, 해당 과정을 통해 롤백을 할 것인지 혹은 어떤 부분을 개선해서 재실험을 진행할 것인지에 대해 PO와 싱크를 맞춰봄으로써 의사결정에 대한 일관성을 확보할 수 있다.
[2] 개발 및 QA
이벤트 설계 및 데이터 QA
개발 과정에서 분석가의 역할은 실험기획에서 설정한 지표를 측정하기 위해 새로 측정할 필요가 있는 이벤트가 있다면, 이벤트를 설계하여 프론트엔드 개발자분들께 적재요청을 할 수 있다.
개발이 완료된 후, 실험 세팅을 점검하면서 각 직군마다 QA를 진행하는데 분석가는 새로 반영된 이벤트들이 의도한 트리거에 맞게 주요 파라미터들이 저장되고 있는지 확인한다.
29 cm -이벤트 설계
출처 : https://medium.com/29cm/목적-조직에서의-da가-하는-일-bc4cf2535a89
위에서 문제는 뭘까? 바로, item_like_count 와 cnt_result 의 이벤트 파라미터의 의미가 혼용되고 있고(count , cnt) 위치 또한 다른 곳에 있다는 문제다.
왜 이런 문제가 발생할까?
연관된 이벤트들과의 통일성을 지키기 위해(컨벤션) 생긴 현상이다.
이런 문제들은 여러 사람이 각기 다른 시기에 적재를 하면서 생기는 차이로 인해 발생한다. 스쿼드 차원 문제가 아닌 전사 데이터 거버넌스 차원에서 해결해야 될 문제이기 때문에 동료들과 흩어져 있는 이벤트 문서를 모아 관리할 수 있는 체계가 구축되는 것이 필요하다.
이런 솔루션으로 29cm 는 이벤트 설계 이슈 아카이빙 을 한다고 한다.
29cm - 이벤트 설계 : 트리거와 QA , 출처 : https://medium.com/29cm/목적-조직에서의-da가-하는-일-bc4cf2535a89
이벤트는 추후 활용 의도에 맞게 적절할 때 찍혀야 한다. 예를 들어 ‘클릭’ 이라는 행동은 명확하지만, ‘노출’ 과 같은 이벤트에서는 다양한 기준점(노출의 기준, 여러 번 노출됐을 경우 중복 적재를 할 것인지 등)에 대해서도 미리 고려되어야 한다.
[3] 분석 및 공유
데이터 확인
29cm 는 Amplitude Experiment를 사용하여 실험을 진행하고 있다고 한다. 실험 환경을 설정한 후에는 모니터링 기능으로 실험이 정상적으로 진행되고 있는지 확인하고, 실험 내에 가드레일 지표가 있다면, 실험 중간에 롤백을 해야하는 상황이 발생할 수 있으므로 매일 확인한다고 합니다.
Amplitude Experiment 내에서 단순한 지표는 대부분 구현 가능하기 때문에 실험의 유의성을 바로 확인할 수 있어 편리합니다. Amplitude로 구현할 수 없는 경우, 직접 쿼리를 작성하여 지표를 구현하고 비교한다고 합니다.
왼 - 앰플리튜드 모니터링 기능, 오 - 하루 일과 중 가드레일 지표 확인 업무, 출처 : https://medium.com/29cm/목적-조직에서의-da가-하는-일-bc4cf2535a89
분석리포트 작성
데이터를 확인한 후 결과를 요약하고 결론을 정리합니다. 결과와 결론은 다른데, 데이터 분석의 최종은 결과만 있는
것이 아니라 결론이 있어야 한다.
•
결과 : 데이터 그 자체로 실제 수치가 어떻게 나타났는지를 의미
•
결론 : 결과를 평가해서 구체적인 행동과 판단이 들어간 내용
→ 프로젝트 문서에서는 전달받은 사람들이 먼저 알고 싶고 알아야만 하는 내용을 전달하기 위해 결과와 결론을 축약한 버전을 사용
→ 분석 리포트에서는 어떤 데이터들을 확인하였는지 어디까지 확인했었는지 모든 내용이 들어가있지만 이 역시 읽는 사람이 궁금하고 필요한 순으로 (레슨런-결론-결과-데이터 확인) 내용을 배치해야 한다.
왼 - 프로젝트 결과 요약본, 오 - 실제 분석 리포트의 목차, 출처 : https://medium.com/29cm/목적-조직에서의-da가-하는-일-bc4cf2535a89