목적조직에서 Data Analyst로 일하기🧑🏻💻(1) : Data Analyst의 R&R, 가설 검증, 실험 설계
Contents
- 프로덕트 분석, 잘 할 수 있을까? 🤔
- 가설을 세우기 위한 인사이트 제공 📊📈
- 가설 검증과 A/B 테스트를 위한 실험 설계🧑🏻🔬
3–1. 타겟 지표 설정 🎯
3–2. 통계적 가설로 번역하기
3–3. 실험 및 Event 설계 - 실험 결과 분석 및 리포팅
- 글을 마치며 📝
프로덕트 분석, 잘 할 수 있을까? 🤔
“회사에서 TF 조직을 만들거에요! TF 조직(2개팀)에 지원할 분들을 모집합니다.”
회사의 하반기 OMTM이 Retention으로 정해졌고, Neil(CEO)은 월간회의 때 멋있는 발표로 Retention 상승을 위한 목적조직을 만들 것을 발표했다.
본래 팀인 Business Intelligence팀에선 주로 회사에 필요한 비즈니스 문제를 분석하고, 업무 효율화를 위해 자동화 업무 등을 하였다.
TF팀이라는 치열한 업무 환경에서 성장하고 싶은 욕심이 컸지만 본래 팀에서 하던 역할과는 결이 좀 다르고, 프로덕트 분석은 물론 모바일 앱 서비스를 경험한지 얼마 안되었기 때문에 걱정이 더 앞서있었던 것 같다.
새로운 목적조직에서 내가 할 수 있는 역할이 무엇일까? 잘 할 수 있을까? 🤪
여러 고민을 했지만 이전에 해보지 않은 경험에 도전해보고 싶었다. 힘들겠지만 이 경험을 하면 많이 성장해있을거란 자신감이 있었다.
“Justin(나)! 깨지는 것에 두려움을 가지지 말고 자신감을 갖고 부딪혀 보세요 💪” Kenny(Team Lead)께서도 내 걱정이 눈에 보이셨는지 좋은 경험이 될 것이라며 응원해주셨다.
그렇게 목적조직(Retention TF팀)에서 데이터 분석가로서 업무가 시작되었다.
가설을 세우기 위한 인사이트 제공 📊📈
목적조직인 우리가 일하는 방식은 간단했다. 가설을 세우고 빠르게 실험하고 검증했다. 그리고 이 과정을 정말 빠르게 반복하였다.
첫번째로 데이터 분석가는 성과가 좋을 만한 가설을 우선순위에 두고, 가설을 유효하게 세울 수 있도록 Data와 Insight를 제공하는 역할을 하였다. 속도가 최우선으로 고려되었던 조직이라 팀원들이 궁금한 내용을 최대한 빠르게 피드백 하였다. 리포팅의 속도를 높이기 위해 Slack에 결과를 정리해서 올렸다.
분석 내용은 주로 User Problem이 무엇인지 정량적인 수치로 제공을 하였다. 또한 팀의 목표 지표가 D7 Retention이었기 때문에 스푼의 Key Action들과 Retention과의 관계가 어떤지, 실험을 통해서 연관지표를 얼만큼 올리면 Retention이 얼마나 오를지 같은 Impact를 사전에 알 수 있는 분석을 자주 하였다.
데이터와 인사이트를 제공하는 과정에서 목적 조직의 장점을 느낄 수 있었는데, Ideation 과정부터 데이터 분석가가 참여하니 팀이 Data-driven 의사결정을 하도록 즉각적으로 유도할 수 있었다. Ideation부터 Release까지 모든 과정에 데이터 분석가가 직접 참여하였고, 나는 단순히 내 역할에 충실했던 것 같은데 조직이 자연스럽게 Data-driven하게 변한 것을 느낄 수 있었다.
어떤 문제로 어떤 실험을 할지 미팅이 자주 있었고, 분석가는 미팅 시작에 참고할 만한 분석 내용을 발표했다. 하루는 iOS 개발자인 Ernie가 발표 내용을 듣곤 Insightful 하다는 리액션(?)을 했는데, 그 때 참 쾌감이 있고 자신감도 붙었던 것 같아 아직까지 기억에 남는다. 🙃
가설 검증과 A/B 테스트를 위한 실험 설계🧑🏻🔬
다시 한 번 말하지만 우리는 가설을 세우고 빠르게 실험하고 검증했다. 이때 팀에서 정말 잘했던 Point가 하나 있는데 우리가 유저를 잘 안다는 착각을 버린 것이었다.
TF Leader이시며 스푼에서 오랫동안 근무하신 Nigel(Product Manager)부터 항상 그러한 마인드를 가져주셨고, 팀원들은 자연스럽게 그것을 따랐다. 명확하게 증명되지 않은 가설은 오래 고민하지 않았다. 빠르게 실험하였다. 검증하고 싶은 가설을 최대한 작은 단위의 개발로 풀어냈다. 빠르게 가설을 검증할 수 있는 환경은 데이터 분석가에게 축복이었다.
실험은 최대한 A/B 테스트를 하였다. 이때 데이터 분석가인 나는 크게 3가지 역할을 하였다.
타겟 지표 설정 🎯
실험을 할 때 가장 중요한 부분이다. 기능을 개선하고 배포하면 그 기능에 의해 변하는 지표가 무엇일지를 고민하고 타겟 지표로 삼았다.
A/B 테스트를 하다보면 여러 지표를 보고 판단하는 상황이 생기는데 그때 최우선적으로 판단해야할 지표이다. 타겟 지표를 정교하게 세우지 않으면 실험 결과를 분석할 때 여러 지표를 보고 혼란에 빠지게 된다.
팀의 North Star는 Retention이기에 주로 Retention과 연관되는 Key Action들을 타겟지표로 삼게되었다. 그리고 최우선 타겟은 아니지만 변화가 있을 수 있는 지표와 참고할만한 지표들은 2차 지표들로 삼았다.
간혹 정말 작은 단위의 실험(e.g. 회원가입 창에서 Skip 버튼 유무)도 이루어졌는데 그런 실험에서는 High-level 지표인 Retention과는 거리가 멀어 Retention에 변화가 있을 일이 만무하다. 이때는 하위 지표들을 타겟삼아 하위 지표가 오르면 Retention이 오른다는 가정을 하였다.
또한 실험이 가질 수 있는 Risk를 생각하고 특정 지표가 서비스에 악영향을 끼치지 않는지 체크했다. 흔히 가드레일 지표라고 불리운다. 예를 들어 스푼의 경우에는 메인화면에 어떤 기능을 추가할 때 컨텐츠가 보이는 수가 적어져서 청취전환율이 떨어지지 않는지 보는 것이다.
이 모든 과정은 PM 그리고 Marketer들과 치열하게 의논하면서 이루어졌다. 자리도 무척이나 가까워서 Discussion이 끊이지 않았었다. 😂
통계적 가설로 번역하기
Ideation을 하다보면 “저의 가설은 무엇무엇 이에요.” 라는 말을 자주 듣곤한다. 많은 분들이 증명되지 않은 의견을 말할 때 쓰는 방식이고, 나 또한 그렇게 자주 사용한다. 그런데 여기에서 말하는 가설은 통계학에선 “명제”에 가깝다. 분석가는 이를 실험을 위한 통계적 가설로 번역해줄 필요가 있다.
가설은 쉽게 설명하면 명제를 측정가능한 지표로 검증 가능하게 만들면 된다. 특히 우리 팀은 A/B 테스트를 주로 했기 때문에 대부분은 실험하는 그룹 간 지표가 통계적으로 유의미하게 차이가 있는지를 보게된다.
하나의 예를 들면 스푼에는 내가 좋아하는 캐스트들을 모아서 들을 수 있는 기능이 있다. “캐스트 보관함” 이라는 네이밍으로 서비스가 제공되고 있는데, 이를 나의 “플레이리스트”라는 이름으로 네이밍을 바꾸면 캐스트들을 한 군데 모아서 재생할 수 있는 느낌이 더 강하기 때문에 캐스트를 더 많이 저장할 것이라는 가설(명제)이 있었다. 분석가는 이를 통계적 가설로 번역하게 된다.
가설 = 명제 + 측정가능한 Metric
- H0: 캐스트 보관함(A, Original)과 플레이리스트(B, Variant)의 캐스트 저장율은 차이가 없다
- H1: 캐스트 보관함(A, Original)과 플레이리스트(B, Variant)의 캐스트 저장율은 차이가 있다
- 통계적 가설은 귀무가설(Null hypothesis, H0, 영가설)과 이와 반대에 있는 대립가설(Alternative hypothesis, H1)로 나타냄, H0을 기각하지 못할 경우 A(Original) Win. 기각할 경우 B(Alternative Hypothesis) Win.
하루는 통계적으로 명제와 가설이 어떻게 다른지 팀원들에게 설명할 수 있는 기회가 주어졌었는데, Marketer인 Tae가 너무 좋은 세션이 었다며 피드백도 해주고 문서로 까지 정리를 따로 해주었었다. 여운이 많이 남고 진심으로 감사한 마음을 가졌었던 것 같다. 😆
아 참! 위에 예시로 들었던 실험 결과가 어떻게 되었는지는 스푼 앱을 설치하고 보석같은 캐스트들을 들어보시면서 알아보셨으면 한다. 😂
실험 및 Event 설계
업무 효율적인 측면에서 실험을 할 때 분석가가 목적조직에서 같이 일하면서 가장 시너지가 나는 부분은 실험과 보고자하는 Event를 설계하는 부분이 아닐까 싶다.
데이터 분석가인 나는 여러 A/B테스트를 운영하며 실험 간에 오버랩이 발생하여 잘못된 실험을 하게되는 건 아닌지, 해석이 어려워져 분석 비용이 높아지지 않는지를 체크하며 주도적으로 개발자와 소통하여 문제를 사전에 방지하였다. 실험군이 어떤 Trigger Point로 A 혹은 B가 되는지 체크하고 데이터 오염이 있을 만한 부분을 최소화 하였다. 냉혹한 현실세계에서는 비싼 A/B 테스팅 툴을 쓴다하더라도 데이터 오염이 왕왕 발생하곤 했다.
또한 필요한 Event Data를 즉각적으로 요청할 수 있었다. Event Data를 추가하고 수정하고 지우는게 개발자 입장에서는 번거로울 수 있는 일인데 어떤 목적으로 실험을 하는지 공감대가 형성되어 있어서 비교적 쉽게 요청할 수 있었다. 분석가가 필요한 데이터를 개발자가 먼저 의견 제시해서 추가하자고도 하였다. 참 감사한 일이다.
만약 이때 주도적으로 개발자와 소통하는 과정이 없었다면 끔찍했을 것이다.
분석 시간이 2–3배로 들었을 것으며 다시 실험을 돌려야 하는 상황도 발생했을 것이다. 😫
실험 결과 분석 및 리포팅
실험 설계를 잘 하고 나면 분석에 쓰는 시간은 매우 축소된다. 이미 어떤 목적으로 분석하고 뭘 보면 될지 알고있다. 데이터를 볼 때는 그룹간 모수 차이가 없는지 확인하고 타겟지표 등을 차례로 확인한다.
국가별, 전체유저 및 신규유저에 따라 분석을 세분화해서 보기도 한다.
당연하고 분명한 결과가 나오면 빠르게 정리를 했지만, 애매하거나 해석이 많이 필요할 때는 나만의 생각에 빠지지 않기 위해 꼭 PM 및 Marketer와 함께 의논했다.
데이터 오염이 발생해 골머리를 앓았는데, 방도가 없었다. 실험을 반복하고 경험을 쌓으며 이를 최소화해 나갔다.
속도가 중요한 조직이기에 누구나 볼 수 있게 Dashboard를 만들고 Slack으로 결과를 리포팅했다. 그 결과는 여러곳에서 필요할 때 복붙이 되곤하였다.
실험 결과가 좋으면 기쁜 마음으로 정리를 하고, 좋지 않으면 슬픈 마음으로 결과를 정리하곤 했다. 우리가 노력한 시간이 헛되이 쓰이지 않기 위해 데이터 분석가로서 결과를 객관적으로 분석하고 방향을 제시하였다.
결과가 좋지 않더라도 분명한 건 해보지 않으면 몰랐던 가설들이었다. Nigel(PM)이 항상 하시는 말씀이었고, 전부 기록에 남아 다음번 실험에서는 똑같은 실패를 반복하지 않게끔 하면 되는 것이었다.
글을 마치며 📝
목적조직에서 데이터 분석가로서 빠르게 실험하고 지표를 개선하는데 많은 기여를 할 수 있어서 성취감이 높았다. 다양한 직군과 같이 일하다 보니 좋은 환경에서 가설을 세우고 실험을 설계하고 데이터를 분석할 수 있어서 정말 감사했다. 🙏 직군간 경계를 허물고 훌륭한 동료들을 알게되어서 감사했다.
이 모든걸 처음했지만, 많은 분들께 배우며 해나갔다. 회사에서 데이터 분석가가 목적조직에 포함되었던 것이 처음 있었던 터라 목적조직에서 데이터 분석가가 해야할 일을 하나하나 정의해나가고 있는 느낌이 든다.
다양한 직군이 모인 조직이다 보니 처음에는 실험 설계(A/B 테스트)의 필요성에 의문이 있는 분들이 많았는데, 시간이 지날수록 조직이 많이 변하고 있음을 느낄 수 있었다.
약 7개월 동안 전력질주를 하며 시간을 보냈던 터라 글을 쓰며 Retention TF팀에 처음 들어왔을 때 마음가짐과 그동안 나의 변화와 성장을 이제서야 조금은 체감하는 것 같다. 맨 처음으로 돌아가서 두려움에 TF팀에 지원하지 않았더라면 얼마나 후회했을까 싶다. 이렇게 또 한 번 도전의 가치를 느낀다 😎
다음 글에서는 목적조직에서 데이터 분석가가 팀의 KPI와 목표 설정을 한 경험을 공유하고자 한다 🙂
