Table Of Contents
✍🏻 이 글은 저자 블로그에서도 만나보실 수 있습니다.
본 포스팅은 저의 경험을 토대로 작성된 내용이며, 무엇이 맞고 틀리다를 이야기하고자 하는 글이 아닌 경험을 공유하고자 작성된 글이므로 재미 or 참고 차원에서 봐주시면 감사하겠습니다 🙂.
현업에서 데이터 분석가로 활동하면서 항상 데이터 분석가로서 뭘 느끼고 있고, 고민하고 있고, 탐구하고 있는지 생각하고 있는 것 같습니다.
이 시점의 저를 공유하고 나눠드리자면, 최근에 스타트업에 합류하게 되었고 3주째 정신을 못차리고 있습니다^.^ 스타트업 특성 상 업무가 빠르게 진행되야 하기 때문에 서비스 및 환경을 파악하고 적응하는데 발생하는 혼란은 어쩔 수 없던 것 같습니다.
오늘 포스팅은 혼돈의 카오스 그 잡채였던, 3주 간의 기간동안 2개의 스프린트 참여 경험과 그 과정에서 저질렀던(?) 실수를 공유하면서 누군가를 위로하고 같이 극복하고자 하기 위함입니다! ^^
혼란스러웠던 이유와 저의 상황을 공유드리면 다음과 같습니다!
- 초기 스타트업에 합류
- 1인 데이터 분석가 (+ 주니어)
- 스프린트 2개 참여
스프린트(=SPRINT)
입사 후, 바로 첫 스프린트에 참여하게 되었고 상황상 3일이라는 짧은 기간을 가져가게 되었습니다. (두번째 스프린트는 4일 ㄷㄷ.. !!)
스프린트(sprint) 는 “전속력으로 달리다.” 라는 뜻을 가진 단어로, ‘여러 직무의 전문가가 모인 팀이 하나의 프로토타입을 제작하기 위해 준비하는 짧은 기간’ 을 의미합니다. 이 프로세스는 구글의 수석 디자이너인 제이크 냅이 만들어낸 방법으로 ‘최소의 시간으로 최상의 결과를 얻도록 조정된 최적의 기획 실행 프로세스’라고 소개되고 있습니다(직접 집필하신 SPRINT 책이 있으니 관심이 있으신 분들은 읽어보세요!). 이미 많은 스타트업에서는 유행처럼 스프린트를 혁신적인 회의방식으로 도입하기도 할만큼 성공적인 ‘문제해결 프로세스’로 자리잡고 있습니다.
tmi 이지만, 이직을 준비하면서 기업의 규모 상관없이 직무에 집중하다보니 그로스 해킹, 린, 프로덕트 분석과 같이 스타트업의 실험 문화 사례를 접하게 되는 경우가 많았습니다. 일명 ‘판교 사투리’라는 스타트업 용어를 실시간으로 들으며 첫 회의에 참여했을 때는 대략 80%는 못알아들은 것 같네용 .. (문맥 상 파악함..)1, 2번째 스프린트 과정
전반적으로 모든 스프린트는 어떤 기능을 개선하고 개발할지 이해관계자의 결정으로 인해 시작되었습니다. “이번에는 00를 고객이 좋아하는지 실험해보자!” 라는 의견과 함께 PO님의 스토리보드가 탄생하였고, 디자이너를 통해 만들어진 웹 디자인으로 프론트, 백엔드 개발이 진행됐습니다. 그 과정에서 제가 해야할 일은 이 실험을 통해 봐야하는 지표 수립과 지표 추적을 위한 이벤트 설계 및 로깅이었습니다.
이벤트 설계 및 로깅(라고 하고 ‘GA와 다이다이’라고 읽는다.)
그동안 잘 적재된 데이터를 받아서 가공-분석의 업무를 수행했었기 때문에 엔지니어링의 영역은 문외한이었습니다. 하지만, 어떤 맥락으로 진행되는지 알고 있었기에 다음과 같이 큰 갈래로 나누어 이벤트를 설계하고 개발자와 원활한 소통 및 협업을 위해 이벤트 택소노미를 작성하여 로깅을 진행했습니다.
이벤트를 설계하기 앞서 생각의 로직은 다음과 같습니다.
- 이 스프린트의 목적 이 무엇인지 파악한다.
- 이를 확인할 수 있는 지표 는 무엇인지 즉, 이 실험을 성공이라고 판단할 지표 는 무엇인지 수립한다.
- 지표를 확인하기 위해서 어디에 이벤트를 심어야 할지 설계한다.
- 설계를 끝냄과 동시에 프론트 개발자와 로깅 진행 및 디버깅 한다.
입사 전부터 회사에서 GA를 보고있었기 때문에 GTM을 사용했어야 했고, GA 경험이 전무한 상태에서 업무를 진행하려고 하니 감이 안잡혀 깨알 같은 문서와 강의를 활용했습니다(base 가 0인 상태에서는 공식문서도 도움이 안됨). 그래도 복잡한 툴이기 때문에 잘하고 있는 건지 불안한 마음이 컸던 것 같습니다.
사실 모르겠으면 그냥 우선 심고 보자.라는 마음에 이것저것 심어둔 것도 많습니다. 따라서, 이상하게, 쓸데없이, 누락되서 심어진 것들도 많았습니다(ㅋㅋㅋ). 어떻게 생각해보면 ‘손놓고 있는 것보단 낫고 우선 심어보자!’ 라는 실행력 덕분에 스프린트를 끝내고 지표를 추적하려고 했을 때 어떤 부분에서 실수가 발생했는지 파악할 수 있었던 것 같습니다…
실수를 공유하면,
. .
시행착오
1. 자체 웹사이트와 saas툴 웹사이트를 GA4의 1개 속성이 묶었다.
- 스프린트에서 프로토타입 증명을 애자일하게 가져가야 했기 때문에, 웹개발 노코드 툴을 사용했습니다. 그 과정에서 GA4의 하나의 속성에 묶어놔 지표 집계를 위한 경로 트래킹에 어려움이 있었습니다. saas툴 웹사이트의 loot 경로와 자체 페이지의 loot 경로가 겹치는 문제가 있었으며, saas툴 웹사이트의 위계 경로가 다소 이상..(?)했습니다. → 속성을 2개만들어서 추적해야할 것으로 판단하고 있습니다.
2. 중복된 이벤트 파라미터(=이벤트 매개변수)를 다양하게 만들었다.
- Q : 추적하고자 하는 이벤트명은 다른데 파라미터명이 동일해도 될까?
- A : 네, 동일해도 됩니다. 이벤트 단위로 수집되기 때문에 파라미터명이 동일할지라도 독립적으로 수집되고 분류한다고 합니다.
좀 더 친절한 설명을 위해 근거를 찾아왔습니다.
3. 특정 기능을 사용한 유저 파라미터를 심지 못했다.
- 구매로 이어질 수 있는 버튼을 사용했으나 전환까지 이어지는 사람의 정보를 받아오지 못했습니다. 따라서, 왜 구매까지 이어지지 않았는지 유저 인터뷰를 진행할 수 있는 기회를 활용하지 못했죵. 저의 상황에서는 버튼 클릭수만 집계할 수 있었습니다.
4. 같은 기능을 가진 cta 버튼의 다양한 위치에 배치되어 있다.
- 특정 기능을 가진 버튼이 2개 이상인 경우 → 웹 디자인의 변경 및 더블 체킹의 부족으로 인해 같은 기능을 하는 2개 이상의 버튼의 이벤트를 제대로 설계하지 못했습니다.
5. 이벤트 로깅에 대한 선택과 집중이 아쉬웠다.
- 짧게 진행되는 스프린트였기 때문에 이벤트의 우선순위를 정하고 선택과 집중을 해야했습니다. 나름의 판단으로 진행됐지만, 성공지표를 파악하는데 필요하지 않은 이벤트가 설계된 것을 나중에 파악할 수 있었습니다.
회고
빠르게 진행됐던 스프린트를 통해 힘들었던 점도 있지만, 스타트업의 업무 속도/스타일에 대해서 조금 더 빠르게 이해할 수 있었던 것 같습니다. 또한, (기획자 + 디자이너 + 개발자 + 분석가)의 원팀 협업을 통해 애자일하게 실험을 진행하는 문화를 경험하였고, 프로덕트(또는 기능)이 탄생하는 과정을 생생하게 느낄 수 있었습니다. 데이터 엔지니어가 없는 조직에 속하여 이벤트 택소노미 설계부터 지표 수립 및 집계까지 진행해보았는데요! 다음 스프린트에서 좀 더 효율적인 업무를 진행하기 위해 생각했던 것들을 공유드리고자 합니다.
- 지표 수립은 데이터 분석가 혼자가 아닌 CEO, PO와 같은 이해관계자와 스프린트 목적에 대한 충분한 대화를 통해 정하자. 각자 보고자 하는 지표와 목적이 다를 수 있으니, 이를 파악하고 최종적으로 지표를 수립하자.
- 지표 수립 단계는 PO의 스토리보드가 끝난 후, 개발이 진행되기 전에 끝내보자. 프론트엔드 개발자가 웹개발을 하는 단계에서 이벤트를 동시에 심을 수 있도록, 개발 전에 지표 수립을 하고 이벤트를 설계하여 공유한다면 더 효율적으로 진행될 수 있지 않을까.
- 데이터 분석가로서 지속적으로 벤치마킹 지표를 탐색하고 우리만의 지표를 찾아보자. 사례 조사를 통해 서비스 성장 단계에 따른 지표를 정의하는 로직을 이해하고, 우리만의 지표를 탐색하자.
마무리
적응기에 여러 경험을 접했을 때는 막막함도 있었고, 잘하고 있는지에 대한 의구심이 스스로를 불안하게 만들었는데 이렇게 글로 정리해보니 쓸모없는 경험은 없다는 말이 와닿는 것 같습니다. 앞으로도 여러 시행착오가 있겠지만, 할 수 있는 것에 최선을 다하는 태도가 중요하지 않을까 싶네요! 쉽게 얻어지는 것은 없다~~