자유님 안녕하세요! 과제하느라 고생하셨습니다. 쿼리에서 1, 4번은 기존 쿼리에서 살짝만 바꾸면 되는거라 해석을 좀 더 깊게 해보길 바라는 문제였고, 2번은 좀 더 복잡한 쿼리를 작성하는 문제, 3번은 실제로 분석까지 하길 희망하는 과제였어요. 1/4번 쿼리는 잘 작성하셨고 2번 쿼리에 대해 리뷰를 드려볼게요 2번 문제 쿼리 전체적으로 쿼리 잘 작성해주셨어요. 제가 생각하는 흐름과 비슷하게 잘 작성하셨네요 다만 컬럼 중 kst가 있는데, 이 컬럼이 이후에 쓰이진 않네요. 이 쿼리를 풀 때는 event_timestamp 개념을 쓰지 않고 event_date만 쓰고 사용해도 충분합니다. 그래서 base에서 바로 daily_event로 만들어서 쓰셔도 될 것 같아요 8월 한정해서가 아니라 데이터를 더 늘려서 확인해보셔도 좋을 것 같고, Weekly 기준으로도 계산해보세요! Daily보단 Weekly로 계산해보셔요! 지금 하신 것에서 크게 변하진 않을 것 같아요. LAG 계산하는 부분이 2번 있네요. 한번만 하셔도 될 것 같아요. 아래 쿼리의 LAG 대신 before_last_event 컬럼을 쓰면 되어요. CASE WHEN first_event = event_date THEN "new" WHEN DATETIME_DIFF(event_date, LAG(event_date) OVER (PARTITION BY user_pseudo_id ORDER BY event_date ASC), DAY) 14 THEN "resurrected" ELSE NULL END AS user_type first_event, last_event 이 컬럼을 계속 가지고 다니는데 실제로 쓰고 있진 않네요. DATETIME_DIFF를 사용하셨는데 쿼리를 확인하면 DATE_DIFF를 쓰시면 더 명확할 것 같아요(동작은 하지만 DATETIME_DIFF은 TIME에 대한 작업을 할 때 주로 쓰곤 해요) 그리고 각 문제를 해석한 것에 대해 의견을 드려볼게요 1번 문제 그래프 자체는 잘 해석해주셨고(강의에서 다룬 내용) 그 이후에 한단계를 더 나아가면 좋습니다 —> 1) 을 개선하는 것이 더 우선적일 것으로 생각됨 1주차 리텐션을 끌어올리면, 1주차 남는 유저 파이가 증가하여 2주차 이후 리텐션이 비슷하게 유지될 것을 고려하더라도 N주차 이상에도 남는 유저가 증가하여 서비스 수익성을 좀 더 확장하기 용이해짐 단, 어느정도 수익성이 안정화되면, 2)에 대한 개선을 진행하여, 남는 유저의 수가 계속 쌓이는 구조가 되도록 해야 장기 서비스의 기반이 될 수 있을 것으로 생각됨 위처럼 작성해주셨는데, Action Item은 좀 더 구체적으로 들어가면 좋습니다. 좀 더 구체적으로 분석을 하는 것인데, 예를 들어 1주차에 남은 사람들은 보통 어떤 이벤트를 많이 하는지 살펴보고 그 후 "가설"을 떠올린 후, 가설이 맞는지 확인할 수 있는 데이터를 확인합니다. 어느정도 데이터가 맞는 것이 있다면 구체적인 Action Item을 제시할 수 있습니다 2번 8월 전반적으로 신규유저(New)는 매일 들어오고, 8월 하순으로 갈수록 우상향하는 추세 다만, 1일만 접속하고 들어오지 않는 유저가 95% 이상으로 리텐션이 무너져 있는 상황으로 복귀유저(resurrected) 상당히 낮음 - dormant 유저 정의: 접속일 이후 14일 동안 접속하지 않는 유저로 8/1 - 8/16, 8/2-8/17 이런식으로 대조해보면 잔존유저가 거의 없음 - current 유저 정의: 접속일 이후 14일 이내에 다시 접속한 유저로 New 유저 유입대비 너무 극소수 - resurrected 유저 정의: dormant 유저 기반에서 재접속한 유저로 굉장히 소수인 상황 → 일평균 95%가 넘는 이탈율을 개선하는 작업이 최우선 위와 같이 남겨주셨는데, 현재 데이터 관찰은 잘 하셨고, 이걸 Weekly 기준으로 한번 그려보세요. Resurrected가 움직일 거예요. 데이터가 오르락 내리락이 된다면 '어? 이건 왜 그렇지?"라는 생각을 한 후(가설 떠올리기) 진짜 그런지 데이터를 살펴봐야 합니다. 그런 과정까지 추가해보시면 더 좋을 것 같아요 쿼리도 한번 점검해보시고 다시 시각화를 해보셔요 3번. 3번의 경우 간단하게 SELECT 한번으로 끝나는 문제는 아니고, 위에서 말씀드린 것처럼 데이터 보고 -> 가설 만들고 -> 살펴보고 해야 합니다. 그 과정에서 이벤트를 1번만 한 사람만 생각하는게 아니라, 여러 이벤트의 조합(검색을 했는데 결제는 안한 사람 등)으로 유저를 나눠보고 그 후에 리텐션 차이를 보는 과정이 필요합니다. 이 문제에 대해서는 조금 더 고민을 해보시는 것을 추천드려요 4번. 4번의 피드백은 1번과 동일합니다. 구체적으로 더 살펴보시고, 이게 왜 이렇게 나왔을까?를 살펴보시면 좋겠습니다! 문제 푸시느라 고생하셨습니다! 계속 고민해보셔요
..님 안녕하세요! 실제 데이터 없이 이벤트 설계를 해보는 것은 100% 정확한 경험은 아니라서, 인프런 AI 인턴이 말한 것처럼 해보시는 것을 추천해요 데모 계정은 GA4를 체험하는거라 로그 설계를 하긴 어렵고, 간단한 웹페이지를 AI를 사용해서 개발해보시면 어떨까요? Claude Code나 Codex 등을 사용해 웹페이지를 만들고 거기서 로그 설계를 해서 실시간으로 테스트하며 보고 싶다고 하면 가이드를 줄 것 같아요. 그 과정에서 GA 로그 설계를 기획하고 직접 데이터가 남도록 볼 수 있을 것 같아요! AI 사용이 익숙하지 않으면 제가 만들어 둔 영상 보시면 감을 잡으실 수 있을 것 같아요! (구글 제품을 사용해요) https://youtu.be/yl0zuUg2vDQ?si=PWyYg8t3aKoOF4q2
Kay님 안녕하세요! 과제 고생하셨습니다 우선.. 1. 혼자 스스로 다 하신 과제일까요? 내용을 보니 AI가 느껴지네요(문장/표현에서) AI를 쓰지 않고 수행해야 자신의 경험이 될 수 있으니 혹시 AI를 쓰셨다면 아래 피드백을 고려해서 시도해보셔요. AI를 쓴 것은 자신의 경험이라 하기엔 애매해서 생각하는 과정을 키우기 어렵습니다(면접에서 이런 사고 과정을 결국 다 물어봅니다) 현재 분석은 퍼널 데이터와 전체적인 시계열 패턴, 2가지를 사용합니다. 그런데 결과를 보면 인사이트라고 할만한 내용이 없습니다. 잘 정리된 것 같지만 알맹이가 없습니다. 왜 그러냐면, 데이터 분석은 간단하게 집계하고 끝나는 일이 아닙니다. 계속 왜 그렇지?라는 생각을 해야 합니다. 이 과정을 논리적 사고라고 부를 수 있고 MECE, Why So/So What? 등으로 전개가 됩니다. 이 부분은 데이터 리터러시 강의에 상세히 나와있습니다. 아마 데이터 리터러시 강의를 수강하지 않으신 것 같은데 데이터 리터러시 강의에서 논리적 사고와 왜 그런가?라는 관점을 익히시면 더 분석을 잘하실 수 있게 될 겁니다. 정적 분석에서 홈 -> 음식 카테고리에서 55.24%가 이탈한다면, 이탈하네?가 끝이 아니라 "어 왜 이탈을 하는걸까?" 라고 생각하며 추가적인 가설을 떠올리고 데이터를 봐야 합니다. 이렇게 추가 가설을 떠올리고 데이터를 더 깊게 보는 것이 분석 과정입니다. 단순히 집계 값만 일차원적으로 보는 것은 분석의 레벨에서 매우 얕습니다. 단순히 초기 탐색 피로도가 높다고 하는 것이 아니라, 진짜 그럴까? 왜 그럴까?를 고민해보세요 동적 패턴이라고 한 부분도 일자별로만 뿌렸는데, 주차별로도 볼 수도 있고 월별로도 볼 수 있습니다. 그리고 평일과 주말 패턴으로도 쪼개서 볼 수 있고 주말에 좀 더 많이 주문하더라 등, 시간대에 따라 주문하는 패턴이 다르다 등 다양하게 볼 수 있습니다. 이렇게 다양한 관점을 하나씩 다 봐야 자세한 분석이라고 볼 수 있습니다. 전략에서 나온 내용은 구체적인 내용이 없습니다. 일차원적으로 이 지표가 부족하니 여기 올려야 한다!만 하는데, 구체적인 방법이 없습니다. 그렇기 때문에 인사이트라고 할만한 내용이 없는 분석 레포트가 되는 것이지요. 명절에 결제 스파이크 패턴을 분석하여 타겟 쿠폰 및 프로모션을 정례화한다고 했는데, 이걸 보더라도 스파이크 패턴을 더 추가적으로 해서 Action Item을 구체적으로 제시해야 합니다. 이런 구체적인 내용이 있어야 좋은 분석입니다. 정리하면 좋은 데이터 분석이라고 하면 현상을 본 후, 가설을 떠올려서 근거를 찾아 그 가설이 맞다, 아니다를 보여줘야 합니다. 단순한 데이터 해석을 넘어서서 더 자세한 분석을 해보시는 것을 추천합니다
Kay님 안녕하세요! 문제 푸느라 고생하셨습니다 1번은 강의에 이미 답이 있으니 넘어가도 될 것 같고, 2번 쿼리도 큰 구조는 잘 작성하셨어요. 다만 ORDER BY에 CASE WHEN을 쓰는 것보단, SELECT에 컬럼을 만들어서 정렬을 하거나 ORDER BY가 없어도 괜찮을 것 같아요. 스프레드시트나 다른 BI에서 어차피 정렬을 하게 됩니다.(이 CASE WHEN에 Dormant가 빠져있기도 해요) 2번 쿼리에서 WHERE (next_week IS NULL) OR ... 때문에 마지막 주차에 활동한 유저는 모두 next_week이 NULL이 될 거예요. 이탈해서가 아니라 다음 주 데이터가 아직 없는건데 이탈로 정의를 한 것이지요. 그리고 2번을 시각화까지 한 후엔 간단하게라도 해석하는 연습을 하는 것이 좋습니다. 분석가는 단순히 쿼리를 작성하는 사람이 아니라 데이터를 해석하는 사람이라서요 3번 관련해서는 음식 추천 기능이 재방문을 유도하는 미끼 역할로 적합하지 않다고 한 근거는 무엇인가요? 코호트 리텐션 하나만 보고 그렇다고 판단하는 것은 섣부른 판단 같아요. 추천 시스템을 쓴 집단과 아닌 집단이 여러 이벤트의 차이가 있는지도 살펴봐야 하고, 그들의 로그를 하나씩 보면서 어떤 생각으로 움직였을지 가설을 만들고 데이터를 기반으로 납득이 되는지 봐야 합니다. 지금은 코호트 하나만 보고 아니라고 한거라 적절한 답변이라 생각이 되진 않아요.(생존자 편향과 별개로 결론내리게 근거가 부족하다는 의미) 4번도 해석을 한번 해보시면 좋을 것 같아요!
안녕하세요. 질문이 잘 이해가 안되네요. Q. 제가 최초에 trainer_id 컬럼을 기준 삼았다고 가정할 때, trainer_id = player_id 이 불편함을 깨닫고 player_id = trainer_id 으로 관점을 바꾸면 좋겠다고 생각할 근거가 있다면 무엇일지 궁금합니다..! 여기에 있는 trainer_id = player_id는 사실 바꾸더라도 의미상 똑같은데요. JOIN에서 어떤 테이블을 왼쪽에 두어야 하는지에 대한 관점인가요? 3분 57분 경에 있는 쿼리는 SELECT * FROM 'basic. battle' WHERE (player1_id = 7) OR (player2_id = 7) 이런 모습인데 갑자기 JOIN 이야기가 나와서 어떤 맥락인지 헷갈리네요. 6-5 문제에서는 트레이너에 대한 분석이 아니라 "배틀에 대한 분석"을 해달라고 했으므로 배틀이 핵심적인 테이블이에요.
