노션 링크를 첨부합니다.https://reinvented-friday-e96.notion.site/BigQuery-3-13dbfe02e9e7801d94b7dd06eb5bb1cc?pvs=4

노션에서 진행했습니다.https://torch-cart-08d.notion.site/140701964d8c8087871bfdc7e3081241

안녕하세요 선생님, 집계연산자 다가 궁금한게 생겨서 질문드려요. 이 쿼리를 쓸때 여러 수식을 중복해서 쓰는데 and 를 쓰면 왜 오류가 나나요? 여러함수를 같이 쓴다 = and를 써서 이어줘야 한다 라고 이해하고 있는데 제가 잘못 이해한 부분이 있는 것 같아서요. 피드백 부탁드립니다!

안녕하세요 ㅠㅠ 제가 알기론 궁극적으로 목표한 테이블이 연결되면 어떤 방식으로 조인을 하든 상관없는걸로 알고있는데 이렇게하니까 하나의 행도 반환되지 않더라고요.... 혹시 무슨 문제가 있는건지 알 수 있을까요?? 조인 기준 컬럼이 중복되면 안되는걸까요? 조인 문제를 풀 때 조인을 먼저하려고 SELECT절은 *로 먼저 두고 시작을 하는데 그때는 오류코드로Error Code: 1060. Duplicate column name 'category_id'다음과 같이 나오더라고요 ㅠㅠ 

Weekly Retention 구하기# Weekly Retention을 구하는 쿼리 WITH base AS ( SELECT DISTINCT user_id, user_pseudo_id, event_name, DATE(DATETIME(TIMESTAMP_MICROS(event_timestamp), 'Asia/Seoul')) AS event_date, DATETIME(TIMESTAMP_MICROS(event_timestamp), 'Asia/Seoul') AS event_datetime FROM advanced.app_logs WHERE event_date BETWEEN "2022-08-01" AND "2022-11-03" # 유저의 event_week, firts_week, diff_week 구하기 ), first_week_and_diff AS ( SELECT *, -- DATE_DIFF(event_date, first_date, DAY) AS diff_of_day DATE_DIFF(event_week, first_week, WEEK) AS diff_of_week FROM ( SELECT # 일자별로 중복 제거 DISTINCT user_pseudo_id, -- DATE_TRUNC DATE_TRUNC(MIN(event_date) OVER(PARTITION BY user_pseudo_id), WEEK(MONDAY)) AS first_week, DATE_TRUNC(event_date, WEEK(MONDAY)) AS event_week FROM base ) # 유저별 event_week, first_week, diff_week 수 ), user_counts AS ( SELECT diff_of_week, COUNT(DISTINCT user_pseudo_id) AS user_cnt FROM first_week_and_diff GROUP BY diff_of_week ) # Weekly retention의 수와 비율 SELECT *, ROUND(SAFE_DIVIDE(user_cnt, first_week_user_cnt), 2) AS retention_rate FROM ( SELECT diff_of_week, user_cnt, FIRST_VALUE(user_cnt) OVER(ORDER BY diff_of_week ASC) AS first_week_user_cnt FROM user_counts )  2. Retention User를 New +Current +Resurrected + Dormant User로 나누는 쿼리를 작성하기WITH base AS ( SELECT DISTINCT user_id, user_pseudo_id, event_name, DATETIME(TIMESTAMP_MICROS(event_timestamp),'Asia/Seoul') AS event_datetime, DATE(DATETIME(TIMESTAMP_MICROS(event_timestamp),'Asia/Seoul')) AS event_date, FROM advanced.app_logs) , weekly_user_active AS ( SELECT user_pseudo_id, DATE_TRUNC(event_date, WEEK) AS event_week, MIN(DATE_TRUNC(event_date, WEEK)) OVER (PARTITION BY user_pseudo_id) AS first_active_week, LAG(DATE_TRUNC(event_date, WEEK)) OVER (PARTITION BY user_pseudo_id ORDER BY DATE_TRUNC(event_date, WEEK)) AS pre_active_week FROM base ) , user_group AS ( SELECT user_pseudo_id, event_week, DATE_DIFF(event_week, pre_active_week, WEEK(MONDAY)) AS diff_prior_week, DATE_DIFF(event_week, first_active_week, WEEK(MONDAY)) AS diff_first_week, CASE WHEN event_week = first_active_week THEN 'NEW' # 처음 사용한 유저 WHEN DATE_DIFF(event_week, pre_active_week, WEEK) = 1 THEN 'Current' # 1주 안에 사용한 유저 WHEN DATE_DIFF(event_week, pre_active_week, WEEK) > 1 THEN 'Resurrected' # ELSE 'Dormant ' END AS user_seg # 유저분류값 FROM weekly_user_active ) SELECT event_week, user_seg, COUNT(DISTINCT user_pseudo_id) AS user_cnt, FROM user_group GROUP BY ALL ORDER BY 1 ;  어떤 사람들이 리텐션이 높은지 찾아보기 NEW(신규유저) : 신규 유저 10월 이후 하락Current (활성화 유저) : 12월까지 상승세를 보이다가 1월에 다시 하락Resurrected (복귀 유저) : 지속 상승Dormant User (휴면 유저) : 지속 상승???: 왜 휴면유저와 복귀유저의 사용 비율이 비슷하게 나오는걸까..? 그래도 그나마 복귀유저가 리텐션이 더 높음 Core Event를 "click_payment"라고 설정하고 Weekly Retention을 구하기WITH base AS ( SELECT DISTINCT user_id, user_pseudo_id, event_name, DATE(DATETIME(TIMESTAMP_MICROS(event_timestamp), 'Asia/Seoul')) AS event_date, DATETIME(TIMESTAMP_MICROS(event_timestamp), 'Asia/Seoul') AS event_datetime FROM advanced.app_logs WHERE event_date BETWEEN "2022-08-01" AND "2022-11-03" AND event_name = 'click_payment' -- Core Event 필터링 ), first_week_and_diff AS ( SELECT *, DATE_DIFF(event_week, first_week, WEEK) AS diff_of_week FROM ( SELECT DISTINCT user_pseudo_id, DATE_TRUNC(MIN(event_date) OVER(PARTITION BY user_pseudo_id), WEEK(MONDAY)) AS first_week, DATE_TRUNC(event_date, WEEK(MONDAY)) AS event_week FROM base ) ), user_counts AS ( SELECT diff_of_week, COUNT(DISTINCT user_pseudo_id) AS user_cnt FROM first_week_and_diff GROUP BY diff_of_week ) SELECT diff_of_week AS week, user_cnt, FIRST_VALUE(user_cnt) OVER(ORDER BY diff_of_week ASC) AS first_week_user_cnt, ROUND(SAFE_DIVIDE(user_cnt, FIRST_VALUE(user_cnt) OVER(ORDER BY diff_of_week ASC)) * 100, 2) AS retention_rate FROM user_counts ORDER BY diff_of_week 

노션에 작성하였습니다.https://apple-baroness-590.notion.site/5-140acf7d68f68092ade2ce06dd76c781

노션링크: https://polite-vinyl-a61.notion.site/4-Foodie-Express-1404994b207d80e5ab10f2e96cc0e82e?pvs=74

내용이 많아 notion에 대신 작성했습니다.[Foodie Express 분석 보고서](https://www.notion.so/claire1125/Foodie-Express-14110fb577ad8074b8d5ce0c58609bc2?pvs=4)

제품 자체는 앱의 기본 flow만 갖춰진 상태다.앱 스플래시 - 로그인 - 홈 진입 후검색 / 즐겨찾기 / 주문내역 / 카테고리 페이지를 볼 수 있고restaurant -> food_detail -> cart -> payment -> order_success로 이어지는 funnel을 갖고있다. WITH login_data AS ( SELECT DISTINCT user_pseudo_id, FORMAT_DATE('%Y-%m-01', event_date) AS login_month FROM advanced.app_logs WHERE event_date BETWEEN '2022-03-01' AND '2023-01-31' ) SELECT login_month, COUNT(DISTINCT user_pseudo_id) FROM login_data GROUP BY login_month ORDER BY login_month  MAU를 계산해보면,7,500에서 시작하여 23,373까지 성장했다.23년 1월 데이터는 절반 정도까지만 있으므로, 지속적인 성장세를 보여주고 있다고 판단할 수는 있겠다.하지만 런칭 후 +2달 이후로는 계속 진전 없는 모습을 보여준다. 배달 앱이기 때문에, 평일-주말에는 다른 접속률을 보여줄 것이다. 그러므로 weekly retention 지표를 활용한다.WITH base AS( SELECT DISTINCT user_id, event_name, DATETIME(TIMESTAMP_MICROS(event_timestamp), 'Asia/Seoul') AS event_datetime, DATE(TIMESTAMP_MICROS(event_timestamp), 'Asia/Seoul') AS event_date, user_pseudo_id FROM advanced.app_logs WHERE event_date BETWEEN '2022-08-01' AND '2022-11-03' AND event_name = 'click_payment' ) , dates AS( SELECT DISTINCT user_pseudo_id, DATE_TRUNC(MIN(event_date) OVER (PARTITION BY user_pseudo_id), WEEK(MONDAY)) AS first_week, DATE_TRUNC(event_date, WEEK(MONDAY)) AS event_week FROM base ) , first_week_and_diff AS ( SELECT *, DATE_DIFF(event_week, first_week, week) AS diff_of_week FROM dates ) , user_counts AS ( SELECT diff_of_week, COUNT(DISTINCT user_pseudo_id) AS user_cnt FROM first_week_and_diff GROUP BY diff_of_week ORDER BY diff_of_week ) , first_week_user_count AS ( SELECT diff_of_week, user_cnt, FIRST_VALUE(user_cnt) OVER(ORDER BY diff_of_week) AS first_week_user_cnt FROM user_counts ) SELECT *, SAFE_DIVIDE(user_cnt, first_week_user_cnt) AS retain_rate FROM first_week_user_count  weekly retention으로 살펴보면, 첫 주에 1%의 고객이 남고 그 후로는 어느정도 플래튜가 형성되는 모습이다. 따라서 아직은 PMF를 찾지 못했다고 할 수 있다.그렇다면 재접속을 하는 유저는 그렇지 않은 유저와 어떻게 다를까?  총 기간동안의 퍼널 이벤트 수는 아래와 같다.WITH base AS ( SELECT event_date , event_timestamp , event_name , user_id , user_pseudo_id , platform , MAX(IF(event_param.key = 'firebase_screen', event_param.value.string_value, NULL)) AS firebase_screen , MAX(IF(event_param.key = 'session_id', event_param.value.string_value, NULL)) AS session_id FROM `advanced.app_logs` CROSS JOIN UNNEST(event_params) AS event_param WHERE event_date BETWEEN '2022-08-01' AND '2023-01-31' GROUP BY ALL ) , filter_event_and_concat_event_and_screen AS ( SELECT * EXCEPT(event_name, firebase_screen, event_timestamp) , DATETIME(TIMESTAMP_MICROS(event_timestamp), 'Asia/Seoul') AS event_datetime , CONCAT(event_name, '-', firebase_screen) AS event_name_with_screen FROM base WHERE event_name IN ('screen_view', 'click_payment') ) SELECT event_name_with_screen , CASE WHEN event_name_with_screen = 'screen_view-welcome' THEN 1 WHEN event_name_with_screen = 'screen_view-home' THEN 2 WHEN event_name_with_screen = 'screen_view-food_category' THEN 3 WHEN event_name_with_screen = 'screen_view-restaurant' THEN 4 WHEN event_name_with_screen = 'screen_view-cart' THEN 5 WHEN event_name_with_screen = 'click_payment-cart' THEN 6 ELSE NULL END AS STEP_NUMBER , COUNT(DISTINCT user_pseudo_id) AS cnt FROM filter_event_and_concat_event_and_screen GROUP BY ALL HAVING step_number IS NOT NULL ORDER BY step_number 홈에서 food category를 선택하는 유저의 비율은 65%카테고리에서 식당을 고르는 유저의 비율은 91%식당에서 장바구니에 담는 유저의 비율은 58%장바구니로부터 결제하는 유저의 비율은 67% 정도이다.일단 탐색을 시작하면 카테고리, 식당에 대해 잘 찾아보는 편이고,장바구니에 담아 결제까지 하는 것에 대해서는 event 수가 급감한다. 재접속을 하는 유저들의 퍼널을 페이지 기준으로 나눠보았다.WITH base AS( SELECT DISTINCT user_id, event_name, DATETIME(TIMESTAMP_MICROS(event_timestamp), 'Asia/Seoul') AS event_datetime, DATE(TIMESTAMP_MICROS(event_timestamp), 'Asia/Seoul') AS event_date, user_pseudo_id FROM advanced.app_logs WHERE event_date BETWEEN '2022-08-01' AND '2023-01-31' ) , dates AS( SELECT DISTINCT user_pseudo_id, DATE_TRUNC(MIN(event_date) OVER (PARTITION BY user_pseudo_id), WEEK(MONDAY)) AS first_week, DATE_TRUNC(event_date, WEEK(MONDAY)) AS event_week FROM base ) , first_week_and_diff AS ( SELECT *, DATE_DIFF(event_week, first_week, week) AS diff_of_week FROM dates ) , retain_user AS ( SELECT DISTINCT user_pseudo_id FROM first_week_and_diff WHERE diff_of_week >= 1 ) , base2 AS ( SELECT event_date , event_timestamp , event_name , user_id , user_pseudo_id , platform , MAX(IF(event_param.key = 'firebase_screen', event_param.value.string_value, NULL)) AS firebase_screen , MAX(IF(event_param.key = 'session_id', event_param.value.string_value, NULL)) AS session_id FROM `advanced.app_logs` CROSS JOIN UNNEST(event_params) AS event_param WHERE event_date BETWEEN '2022-08-01' AND '2023-01-31' AND user_pseudo_id IN ( SELECT user_pseudo_id FROM retain_user ) GROUP BY ALL ) , filter_event_and_concat_event_and_screen AS ( SELECT * EXCEPT(event_name, firebase_screen, event_timestamp) , DATETIME(TIMESTAMP_MICROS(event_timestamp), 'Asia/Seoul') AS event_datetime , CONCAT(event_name, '-', firebase_screen) AS event_name_with_screen FROM base2 WHERE event_name IN ('screen_view', 'click_payment') ) SELECT event_name_with_screen , CASE WHEN event_name_with_screen = 'screen_view-welcome' THEN 1 WHEN event_name_with_screen = 'screen_view-home' THEN 2 WHEN event_name_with_screen = 'screen_view-food_category' THEN 3 WHEN event_name_with_screen = 'screen_view-restaurant' THEN 4 WHEN event_name_with_screen = 'screen_view-cart' THEN 5 WHEN event_name_with_screen = 'click_payment-cart' THEN 6 ELSE NULL END AS STEP_NUMBER , COUNT(DISTINCT user_pseudo_id) AS cnt FROM filter_event_and_concat_event_and_screen GROUP BY ALL HAVING step_number IS NOT NULL ORDER BY STEP_NUMBER 한번이라도 재접속한 사람들은 웰컴 -> 홈을 넘어가는 비율이 거의 100%에 가깝다. 아무래도 login이란 허들때문일 것이다.그렇다면, login 허들을 좀 더 잘 넘기 위해 제품 온보딩을 잘 해줘야하지 않을까?확실히 프로덕트에 대한 차별점 설명이 부족하므로, 이 부분을 강화하여 '어떤 core value를 가진 배달앱'인지를 어필할 필요가 있겠다. 그리고 홈에서 카테고리로 넘어가는 비율이 73%,카테고리에서 식당 페이지로 92%,식당 페이지에서 장바구니로는 55%장바구니로부터 결제까지 이어지는 비율은 67%이다.재접속한 유저들은 홈에서 food category를 선택하는 데에 좀 더 높은 전환율을 보였다.그렇다면 이들이 다른 유저들 대비하여 추가적으로 느낀 이점은 무엇일지 고민할 필요가 있을 것이다. 재접속 기준만으로는 차이가 별로 없어서click payment 경험이 있고 재접속을 한 유저들의 퍼널을 구해봤다. 비교적 매우 높은 전환율을 보여준다.특히 카테고리를 굳이 선택하지 않고 바로 식당을 선택하는데,카테고리가 비교적 메리트있게 설계되지 않아서 그런 것인지? 라는 생각이 든다.이벤트 데이터가 더 있었다면, 식당으로 전환되는 페이지들의 비율을 살펴보면서 홈의 비중이 높지 않을까 하고 보겠지만, 지금은 그냥 그렇지 않을까 하고 추측해본다. 확실히 구매를 했고, 2번 이상 접속한 유저들의 퍼널 전환율은 매우 좋다.해당 제품이 직접 보기에는 배달 주문에 필수적인 기능들만 있지만,해당 1만 4천명 정도의 유저들이 느끼는 분명한 메리트가 있을 것이다. 그 메리트로부터 core value를 찾고, 고객들이 좋아하는 기능 중심으로 발전시켜 나가야할 것이다.      

과제 관련 노션 링크 첨부합니다!https://www.notion.so/4-6-1-1419f4b04d5380308bbdf4a19394e924?pvs=4

4주차 최종과제 노션 링크입니다:) https://salt-baron-5c5.notion.site/4-Foodie-Express-13ea734e64b8801595f8c8c3467d9bc5?pvs=4

Notion 링크로 대체합니다.https://colney4844.notion.site/4-13e59b98d5db80d6937fc8fbd6e207e6?pvs=4

강의자료 업로드 상태 확인 및 전달 부탁드립니다.커리큘럼 목차에서 강의자료 다운로드 한 이후 zip 안에 파일이 없는 것으로 나와 강의자료 확인할 수가 없습니다.

PDF교재에는 문제와 답+풀이가 한번에 나와있는데 문제만 나와있는버전은 없을까요?

선생님 강의에서는 아나콘다를 사용하셨는데, 저는 pipenv를 사용하고싶거든요..콘다 말고 다른 가상환경을 사용해도 괜찮을까요?

안녕하세요, 김정선 강사님.강의 잘 듣고 있습니다.다름이 아니라, 개인적인 사정으로 인해 강의를 기간 내에 모두 수강하지 못하였는데, 혹시 강의 연장이 가능한지 여쭙고자 합니다.부디 확인 부탁드리며, 답변 주시면 감사하겠습니다!!감사합니다.

안녕하세요 강사님. jooq 강의 잘 듣고 있습니다. 현재 update 부분 강의를 들으면서 실습해보고 있는데 Actor 에 setter 메소드들이 없어서 dao 를 통한 update를 하는데 다소 어려움이 생겼습니다. insert 의 경우는 생성자에 데이터를 넣어서 잘 넘어갔는데, update 에서는 setter 가 없으니까, insert 한 값을 Actor 객체로 반환 받아서 그 객체에 있는 setter 를 이용해 update 하는 방식이 불가능하다 보니 "setter 는 어디로 갔는가?" 생각이 들더라구요. 실습중인 jooq 버전은 3.19.5 이고, 아래는 Actor pojo 파일 구조 입니다.

강의 정말 도움 많이 되었습니다!!강의 내용 중에 동시성인지 병렬성인지 헷갈리는게 있어 질문드립니다..!7:35에 일반 def 함수 라우터로 작성한 ThreadPool(병렬) 방식은 매번 요청시 ThreadPool에서 유휴 Tread를 찾아 동작하고 i/o wait가 발생할때 context switch를 해가면서 작업하는 것으로 이해했는데...이게 맞다면..! 완벽한 병렬성이 아니라 동시에 작업하는 것 처럼 보이는 동시성으로 동작하는 건가요?

안녕하세요 SQLD 준비하고 있는 전진호 학생입니다. 강의 2:47에서  'PRIOR PK = FK' PK (부모)-> FK(자식) 순방향 전개'PRIOR FK = PK' FK (자식)-> PK(부모) 역방향 전개이렇게 나와야 하는 슬라이드에서  'PRIOR PK = FK' PK (부모)-> FK(자식) 순방향 전개'PRIOR FK = PK' FK (자식)-> FK(부모) 역방향 전개 FK -> PK가 FK -> FK로 바뀐 거 같습니다.  감사합니다. 전진호 드림.

1) Weekly Retention을 구하는 쿼리를 바닥부터 스스로 작성해보세요WITH base AS ( SELECT DISTINCT user_id, user_pseudo_id, event_name, DATETIME(TIMESTAMP_MICROS(event_timestamp), "Asia/Seoul") AS event_datetime, DATE(DATETIME(TIMESTAMP_MICROS(event_timestamp), "Asia/Seoul")) AS event_date FROM `advanced.app_logs` ), first_week_and_diff AS ( SELECT *, DATE_DIFF(event_week, first_week, WEEK) AS diff_of_week FROM ( SELECT DISTINCT user_pseudo_id, DATE_TRUNC(MIN(event_date) OVER(PARTITION BY user_pseudo_id), WEEK(MONDAY)) AS first_week, DATE_TRUNC(event_date, WEEK(MONDAY)) AS event_week FROM base ) ) SELECT diff_of_week, COUNT(DISTINCT user_pseudo_id) AS user_cnt, ROUND(SAFE_DIVIDE((COUNT(DISTINCT user_pseudo_id)), (FIRST_VALUE(COUNT(DISTINCT user_pseudo_id)) OVER(ORDER BY diff_of_week))), 3) AS retention FROM first_week_and_diff GROUP BY diff_of_week ORDER BY diff_of_week2) Retain User를 New+Current+Resurrected+DormantUser로 나누는 쿼리를 작성해보세요.유저 구분 기준은 제품이나 서비스에 따라 다르겠지만 applogs 데이터는 주단위로 했을때 총 24주치 데이터가 있었고, 유저별로 평균 구매 주기와 방문 횟수를 구해보았을 때 6주를 기준으로 유저를 구분하면 될 것이라 생각함. New : 첫 방문한 신규 유저  Current : 방문 횟수 2회 이상이면서 6주 이내 재 방문 이력 있는 유저Resurrected : 방문 횟수 2회 이상 & 직전 방문 경과 7주 이상이면서 6주 이내 재방문 이력 있는 유저Dormant : 직전 방문 경과 7주 이상이면서 6주 이내 재방문 없는 유저(사실 이렇게 나누는게 맞는지 모르겠지만, 나름의 논리적인 기준을 찾아보려고 노력하였음. 😫 과제 기한 연장에도 개인적인 사정으로 시간이 부족하여 깊이 탐구하지 못했고, 쿼리 작성을 완성하지 못했습니다 😩 추후에 완성하면 보완하도록 하겠습니다. )3) 주어진 데이터에서 어떤 사람들이 리텐션이 그나마 높을까요? 찾아보세요 미완성으로 추후에 완성하면 보완하겠습니다 ! 4) Core Event를 “click_payment” 라고 설정하고 Weekly Retention을 구해주세요WITH base AS ( SELECT DISTINCT user_id, user_pseudo_id, event_name, DATETIME(TIMESTAMP_MICROS(event_timestamp), "Asia/Seoul") AS event_datetime, DATE(DATETIME(TIMESTAMP_MICROS(event_timestamp), "Asia/Seoul")) AS event_date FROM `advanced.app_logs` ), first_week_and_diff AS ( SELECT *, DATE_DIFF(event_week, first_week, WEEK) AS diff_of_week FROM ( SELECT DISTINCT user_pseudo_id, DATE_TRUNC(MIN(event_date) OVER(PARTITION BY user_pseudo_id), WEEK(MONDAY)) AS first_week, DATE_TRUNC(event_date, WEEK(MONDAY)) AS event_week FROM base ) ) SELECT diff_of_week, COUNT(DISTINCT user_pseudo_id) AS user_cnt, ROUND(SAFE_DIVIDE((COUNT(DISTINCT user_pseudo_id)), (FIRST_VALUE(COUNT(DISTINCT user_pseudo_id)) OVER(ORDER BY diff_of_week))), 3) AS retention FROM first_week_and_diff GROUP BY diff_of_week ORDER BY diff_of_week