본문 바로가기
마케팅 정보방/비밀 공부방

MODE 사이트에서 데이터분석 혼자 공부하기

by 그로스마케터 제시 2022. 3. 12.
반응형

SQL 코드도 다 배웠는데... 이론은 이제 알겠고, 근데 이게 어떻게 쓰인다는 건가.
Join 함수를 통해 각종 자료들을 정리해서 원하는 정보를 볼 수 있겠다는 건 알겠다. 
하지만 데이터 분석가에게 SQL이 엄청 중요하다던데,
데이터 분석가는 어떻게 SQL을 사용하는지가 궁금했다.
 
 
그래서 알게 된 사이트가 mode! 

이론 뿐만이 아니라, 3개의 실제 analytics 예제가 있어서 이 예제만 보기로 했다.
영어 원서를 번역하면서 정리한 것이기 때문에 한글과 영어가 뒤죽박죽으로 섞여있고, 전체 내용을 정리한 것이 아닌 나에게 필요한 부분들만 정리했기에,
문제별로 맨 밑에 있는 Insight 부분만 볼 것을 추천한다. 
 
 

<Investigating a drop in user engagement>

engagement: 제품과 상호작용하여 일종의 서버 호출을 수행하는 것 (ex.버튼 클릭, 로그인 등등)
retention: 고객이 유지되는비율

cohat analysis: 전체 유저를 어떤 특징을 기준으로 작은 그룹으로 나누어 하는 분석 (주로 유저의 가입시기)
 

Problem:
왜 마지막에 dip이 발생하였나 (=활성 사용자가 줄고 있다)
 
 
Anaysis order:
1. possible causes를 리스트업 한다.
2. 체크할 순으로 순서를 부여한다. (think carefully about the criteria)
3. 각각의 가설을 테스트해야 한다는 것을 기억하자 (가설을 잘 설정해야 시간을 많이 줄일 수 있다)
4. 저 차트가 뭘 보여주고 뭘 보여주지 않는지 확인
 
 
Possible hypothesis:
1. Holiday: Yammer같은 work app을 쓰는 사람들이 holiday에는 lower rate 이라서. 특히, 특정나라에서 engagement가 낮아져서 영향을 받았을 수 있다. 
2. Broken feature: 어디 한 군데 고장났다. (ex. 회원가입 고장나면 growth도 낮아졌을 것이고,앱이 고장나면 해당 device type만 낮아졌을 것이기에 확인할 필요 있음)
3. Broken tracking code: 코드 고장 (결과값이 완전히 0을 기록한 부분이 있는지 확인)
4. Traffic anomalies from bots: 제품/인프라를 변경하여 bot들이 interact 하기 어려워졌다. (bot-like-behavior 알아내야 함)
5. Traffic shutdown to your site: 인터넷 공급자가 내 사이트를 차단했다. 
6. Marketing event: one-time marketing blitzes 로 들어온 사람들은 지인 소개보다 retention rate이 낮은 경향이 있다. 차트가 7일분씩 보여주고 있으니, 첫 주는 잘 됐는데 그 다음주는 효과가 감소했을 수 있다. (마케팅팀에 물어보는게 빠름)
7. Bad data: 알고보니 첫 주에 높게 나온건 QA data였다. (근데 이건 매우 소수의 additional data로 나타날 것이기에 여기서는 해당 x)
8. search crawler changes: 트래픽 많은사이트에서 검색엔진이 index 하는 방식 바뀌어 큰 변동이 생길 수 있음
 
 
Sorting hypothesis:
1. experience: 몇번 같은 상황이 반복되면 보인다.
2. communication: 마케팅팀에 물어본다. (이 예시는 관련 x)
3. speed: data가 cleaner&easier 한 것부터 접근
4. dependency: 이해하기 쉬운 시나리오부터 접근
 
 
Digging in:
tbl1 = users,
tbl2 = events (action that a user has taken),
tbl3 = email events (specific event),
tbl4 = rollup periods (lookup tbl)
 
분석 결과, signed up more than 10 weeks의 사용자의 WAU가 낮아졌다는 것을 확인했다. 
 
 
Make a recommendation:
생각해야 할 것들
- original 가설에서 further question 이끄는 answer 있는가
- 그것들이 뭐고, 어떻게 테스트할 것인가
- data로만 답변되지 않는 경우, 어떻게 할 것인가?
- 그래서 engagement dip의 원인이 뭔가
-회사는 뭘 해야 하나
 
 
Insight:
해당 내용은 AU rate 감소의 원인을 파악하는 문제였다. 문제가 있고, 해결 방안을 제시해야 할 때 특히 원인에 대한 가설 설정이 중요하다. 마케팅 문제, 기술적인 문제, 외부 요인 등 모든 곳에서 일어날 수 있는 문제를 전체적인 시각으로 파악하고 여러 가설을 세워야 한다. 그래야 어떤 테이블들을 연결해서 어떻게 볼지 판단할 수 있고, 빠르게 일을 진행할 수 있다. 기획 부서에서 이슈사항을 명확히 파악하고, 마케팅 부서와도 컨택해야 하기 때문에 퀄리티 있는 커뮤니케이션 스킬이 필요하다는점도 알 수 있었다. 중요한 것은 그래서 회사는 뭘 해야 하나? 까지의 결론을 이끌어내야 한다는 것.
 
 

<Understanding search functionality>

problem:
사이트의 검색 기능 강화하기
경로: search box -> search 기능 -> typing 하면 dropdown list 뜸 (관련도 순) -> see all results를 누르면, result page로 넘어감. (카테고리가 나뉘어져 있고, 관련도/연대기 순 정렬)
조건: 새로운 feature가 추가되면, 반영이 되어야한다.
참고: 기획팀에서 검색 작업을 별도로 수행해야 할지, 그렇다면 어떻게 수정하면 좋을지 의견을 제시해줘야 한다. 
 
분석 사항: 유저들이 검색 목적에 만족한건 어떻게 알 거고, 유저가 검색할 때 퀄리티 있게 기능이 작동하는지
 
 
What to check:
1. search use: 다들 검색 기능 사용하는가
2. search frequency: 유저가 검색 많이 할수록 가치 있는 자료를 얻을 것이고, 검색을 자주 했다면 원하는 결과가 없었다는 것이다.
3. repeated terms: 검색 용어의 비슷함 비교. (이 예제에서는 이것보다 유저가 짧은 시간에 검색을 얼마나 반복했는지 세는게 더 빠르다)
4. clickthroughs: search lanking defining에 좋다. 유저가 하단에 있는 결과를 누르거나, see all results를 누를 경우 확인
5. autocomplete clickthroughs: 자동완성기능 성공을 특정한다
 
 
How to check:
1. search_autocomplete: 유저가 자동완성 기능을 눌렀을 때 count
2. search_run: search result page를 눌렀을 때 count
3. search_click_X : 유저가 result를 눌렀을 때 몇번째 result를 눌렀나
 
 
Digging in:
1. 자동완성과 수기입력 중에 사용 비중
2. 자동완성이 보통 1-2회 쓰였고, 하나의 세션에서 여러번 검색함
*세션: 10분 내의 시간 동안 사용자가 search한 event 
3. 세션마다 적어도 한번은 클릭한 횟수 확인, 세션마다 평균 클릭 수 확인, result 클릭 수 확인
4. 수기 입력한 사람은 재방문을 거의 하지 않은 반면, 자동완성 기능을 사용한 사람들은 재방문율 높음
 
 
Make a recommendation:
확인해야 할 사항:
- search experience가 generally good? or bad?
- function들이 worth working 하는가?
- 뭐가 improve 되어야 하나?
 
결과: 자동완성 기능은 잘 작동하는데, search runs(검색 결과의 관련도 정렬) 은 아니었다. ordering에 집중해야 한다. = search ranking 알고리즘을 바꿔볼 수 있겠다. 그외에 여러가지 개선 사항이 있겠지만 improving full search results 개선에 초점을 맞춰야 한다. 
 
 
Insight:
해당 문제는 위와 달리, 서비스 개선 사항을 알아내는 문제다. '소비자 만족도 개선'의 목적만 있고 원인이 있는 문제가 아니기에, 스스로 만족도가 낮은 부분과 높은 부분을 찾아내는 것이 우선적이다. 만족도를 어떻게 수치로 나타낼 것인지 고민해야 한다. (여기서는 클릭 수 활용) 기술적인 해결 방안을 제시할 수 있으면 더욱 좋다. 
 
 

<Validating A/B test results>

Problem:
Publisher(포스팅) 기능 강화를 위한 A/B 테스트를 분석해 뭐가 더 좋은지 알아내자
old version(control group)과 new version(treatment group) 으로 나뉘어 test 하였고, treatment 그룹에서 포스팅 수가50% 증가하였다. new version이 진짜 좋아서 이런 결과가 나온 건지, too good to be true 인지 검증해야 한다.

(average 비교에는 t-test가 통상적으로 사용된다)
 
 

What to check:
1. 테스트가 잘 작동했는지 확인
2. 더 나은 분석 메트릭은 없는지 여러개 확인
3. data 신뢰도 확인
4. 결론 내야함. 발행해야 하나? 아니면 re-test? 그렇다면 뭘 다르게 해야 할지
 
-feature이 어떻게, 왜 user behavior 바꿨는지 확인하는 가설 설정이 중요
-데이터 보기 전에, 분석 결과를 설명해주는 가설을 여러개 디벨롭 해야 함
 
 
Hypothesis:
1. this metric is incorrect/irrelevant: posting rate이 best 지표 아닐 수 있다. ex. 포스팅 버튼을 엄청 크게 만들면, rate은 증가하겠지만 좋은 feature은 아니다. 
2. the test was caculated incorrectly: a/b test는 사람이 하는 통계 테스트므로 계산이 틀릴 가능성도 있다. 
3. the users were treated incorrectly: 한쪽에서 버그가 났을 수도 있다
4. there is confounding factor/interaction effect: 다른 외부 요인들에서 영향 받았을 수도 있다. (ex. new version에서 다른 feature들이 모바일/컴퓨터와 어울리지 않거나, 유저 행동이 예상 불가능해지거나)
 
 
Digging in:
1. 다른 메트릭 확인 (야머에서 가치를 얻고 있나) 로그인 평균이나, 들어오는 날들 평균 (ex. 들어오는 날들 둘다 같은데, 로그인 평균만 높으면 로그인 버그 때문에 여러번 로그인 했을 수도 있다.)
2. 다른 mathematical method 이용
3. 새로운 유저가 모두 treatment group으로 분류되었다. (new user 제외해봐야 함)
4. new vs 기존, usage by device, usage by user type 체크해보자
 
결과: test result는 still strong하지만, new user 처리하는 로깅 오류를 수정할 필요가 있다. 
 
 
Insight:
이 문제는 a/b test의 결과의 신뢰성을 파악하는 문제였다. 이 문제는 발생할 수 있는 변동 요인들을 찾아내는 것이 핵심이다. 가령 들어오는 날은 똑같은데 로그인 평균이 높으면 로그인 버그가 있었다는 것을 알 수 있는 것처럼, 데이터들을 여러 방법으로 sorting해보고, 함정을 찾아내는 것이 중요하다. 신뢰도가 완벽한지를 증명해내는 것을 목적으로 잡아야한다. 만약 결함을 발견했으면, 그것이 내 선에서 additional로 처리하고 분석 가능한 것인지, 아니면 re-test가 필요한 것인지도 판단할 수 있어야 한다. (re-test에는 그만큼의 시간과 비용이 더 든다는 것이기 때문에...)
 
 
 
 
결론적으로, 데이터 분석가가 실무에서 어떤 일들을 수행하고, 어떻게 일해야 하는지 그 flow를 알 수 있었다. 데이터 분석가에게 코드 작성은 20% 라고 했다. 코드 작성은 일처리를 돕는 기본 베이스일 뿐이고, 가장 중요한 것은 데이터를 어떻게 분석해서 어떤 결과를 도출하는가 이다. 전반적으로 숲을 보는 능력과, 제시되는 문제별로 어떻게 접근해야 할지를 결정하는 능력이 요구된다는 것을 알았다. 신뢰도 검증 문제에서는 각종 변동 요인들을 생각해야 하고, 기능 강화 문제에서는 만족도를 어떻게 수치로 증명할 것인지 생각해야 된다. 가장 중요한 것은 효율적으로 일하기 위해선 퀄리티 높은 가설을 설정해야 한다!! 본인만의 자의적인 해석과 판단이 들어가면서도, 이를 데이터로 검증하고 어떤 결과를 낸다는게 정말 매력적인 직업인 것 같다.
 
앞으로 SQL 공부를 할 때, 어떤 데이터를 어떤식으로 엮어서 어떤 문제를 해결할 수 있을지를 생각하면서 접근할 것이고, 자의적인 판단의 신뢰성을 높이기 위해서 통계적인 지식을 쌓을 것이다. (그리고 이 통계 지식을 SQL에 응용하는 것도 중요!) 

반응형

댓글