-- Weekly 리텐션 -- 핵심 : event_date => event_week으로 변경하면 됨 -- 2024-06-30(일) => 2024년 26주차. 2024-06-24(월)도 같은 26주차 -- 데이터를 전처리(가공)하기 위해서 WEEK 함수를 사용할 수도 있고, DATE_TRUNC(일자, 자를 기준) -- DATE_TRUNC : 2024-06-30 => 2024-06-24 -- WEEK : 26. 2024년 26주차! 주차 별 date를 직관적으로 알기 어렵다고 생각하는 편(개인 생각) -- (깨알 지식) WEEK vs ISO_WEEK -- 주 번호를 계산할 때 사용할 수 있는 함수 -- WEEK : 일요일이 주의 첫 날로 간주. 1월 1일이 속한 주가 1주차 -- ISO_WEEK : 월요일이 주의 첫 날로 간주. ISO 8601 국제 표준에 따라 정의. 목요일이 속한 주를 기준으로 주 번호를 지정 -- 목요일이 속하면 그 주의 4일 이상이 포함되기 때문 -- 연도의 첫 목요일이 있는 주부터 1주차 -- 2022년 1월 1일(토요일) WEEK : 2022년 1주차. ISO_WEEK 2021년 52주차. -- 첫 목요일은 2022-01-06. 2022-01-03~2022-01-09가 2022년 1주차 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" ), 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 ) ), 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 *, 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 ) -- 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 # Monthly 리텐션 쿼리 작성해보기! 지금 코드가 각 diff_week마다 남은 유저들을 전체 유저로 나눠서 아 몇주차쯤 되면 얼마나 남아있는지를 계산한 거 같은데 생각해보니까 예를들어 지금 기간이 11월 3일까진데 한 10월 중순에 들어온 유저 같은 경우엔 diff_week가 한 3 이상인 부분부턴 아예 데이터가 없는거 아닌가요? 데이터가 11월 3일까지 밖에 없으니까요 분모로 사용하는 diff_week=0인 지점에서의 값은 그런 경우들까지 전부 포함된거고 그걸 그대로 모든 retention week마다 분모로 사용하면 위 예시 같은 경우 10월 중순 user들은 한 3주차쯤엔 전부 이탈하는 것 처럼 집계되는거 아닌가요? 그 경우 diff_week가 커질수록 실제 리텐션 보다 과소평가 되는게 아닌가 하는 의문점이 들어 문의 남깁니다
[질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) [질문 내용] Array 연습 문제 5번을 제가 스스로 풀어보았을 때 이런 식으로 코드가 나왔고, 실행시켜봤을 때 답은 똑같이 나오는 것 같습니다. 다만 풀이와는 코드가 조금 다른 부분이 있는데 혹시 제가 풀어 본 코드도 맞는 코드인가요? 아니면 틀린 걸까요?
안녕하세요, 토비님. 강의 초반에 말씀해 주신 것처럼, 리팩토링 과정에서 “제가 했다면 어떻게 했을까”를 계속 생각해 보며 토비님의 의사결정 과정을 따라가고 있습니다. MemberService.register() 메소드에서 emailSender.send(...) 를 sendWelcomeEmail() 로 분리하시는 과정을 보며 두 가지 고민이 생겼습니다. 첫째, 환영 이메일의 내용이나 정책이 변경될 때마다 MemberService 의 코드가 함께 변경되어야 한다면, 이는 SRP 위반에 해당하지 않는지에 대한 고민입니다. 이 경우 환영 이메일 전송에 대한 책임을 EmailSender 인터페이스 쪽으로 옮기는 것이 더 적절한지 궁금해졌습니다. 둘째, 만약 EmailSender 인터페이스에 해당 메소드를 추가한다면, 구현체가 늘어날수록 인터페이스가 비대해지거나 향후 구현 복잡도가 증가할 수 있다고 느꼈습니다. 이런 경우 default method 로 제공하는 방식에 대해서는 어떻게 생각하시는지도 궁금합니다.
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 "2023-08-03" ), first_week_and_diff AS ( SELECT *, DATE_DIFF(event_week, first_week, WEEK) AS weeks_after_first_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 first_week, weeks_after_first_week, COUNT(DISTINCT user_pseudo_id) AS active_users FROM first_week_and_diff GROUP BY first_week, weeks_after_first_week ) SELECT *, ROUND(SAFE_DIVIDE(active_users, cohort_users), 2) AS retention_rate FROM ( SELECT first_week, weeks_after_first_week, active_users, FIRST_VALUE(active_users) OVER(PARTITION BY first_week ORDER BY weeks_after_first_week ASC) AS cohort_users FROM user_counts ) ORDER BY first_week, weeks_after_first_week 수업때 사용했던 코드인데 제가 처음엔 지금 하고 있는 코호트 분석은 first_week(가입주) 마다 각자 시간이 흐르면서(기준은 week) 리텐션이 어떻게 바뀌는지를 보는 것 이라고 이해했었습니다 그래서 예를들어 첫 달 부터 확 떨어지면 이거 온보딩에 문제가 있는거 아닌가? 라는 문제정의를 하는 식의 생각을 할 수있다... 라고 이해하고 있었는데 다시 보니까 지금처럼 base에 날짜 조건을 필터링 하고 시작하면 min(event_date)를 걸어도 그게 실제 첫 가입일이 아닐 수 있는거 아닌가요? 예를들어 필터링 조건 이전인 2022년 7월에 가입을 한 사람이 2022년 10월에 다시 돌아왔다고 치면 이 경우 2022년 10월 가입 user로 집계되는거지 않나요? 그럼 본래 보려던 거랑 결이 달라지는게 아닌가 싶어서요
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요. 1. 강의 내용과 관련된 질문을 남겨주세요. 2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요. (자주 하는 질문 링크: https://bit.ly/3fX6ygx) 3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요. (질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG) 질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요. ========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) [질문 내용] 여기에 질문 내용을 남겨주세요. 질문드립니다. 클래스에서 static 메서드엔 static 변수와 메서드만 사용할 수 있고 인스턴스 변수와 메서드를 사용하지 못하는 이유는 '인스턴스는 생성이 되어야 참조값이 생성되기에 아직 생성되지 않은 클래스 내에서는 인스턴스를 사용할 수 없다.'로 이해하고 있습니다. 그러면 해당 클래스의 인스턴스 메서드 에서는 아직 생성되지 않은 클래스인데 인스턴스 변수와 메서드를 사용할 수 있는 이유가 무엇일까요?
다른 분이 질문한 내용을 읽어보고 고민하고 생각해봤는데도 이해가 안되서 질문 합니다. str == ch 는 0 이되는건 알겠는데 그 옆 str+1로 다음 글자 인것도 알겠습니다 근데 그옆에 ch는 무슨뜻이죠?? ch는 그냥 무시하는 건가요? return( *str == ch)여기에서 0이 되는건 이해됩니다. 그런데 charFreq(str + 1, ch)에서 ch는 그냥 무시되어버리는 도저히 이해가 안됩니다 ㅠㅠ 도와주세요 charFreq(str + 1,ch) 여기 값에서는 무슨 짓을 해도 계속 0이 나오는건가요?
학습 관련 질문을 최대한 상세히 남겨주세요! 고민 과정도 같이 나열해주셔도 좋습니다. 먼저 유사한 질문이 있었는지 검색해보세요. 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요. 좋아요에 대한 정합성을 (article_id, user_id) 유니크 인덱스로 보장하는 것은 DB의 역할이라고 생각합니다. 그렇다면, 다수의 동시 요청이나 사용자의 반복 클릭(예: 좋아요 버튼을 연속으로 누르는 경우) 상황에서 불필요한 DB 부하와 예외 발생을 줄이기 위해 애플리케이션 단에서는 어떤 방식으로 이를 보완하고 처리하는 것이 적절한가요? 좋아요에 대한 정합성을 (article_id, user_id) 유니크 인덱스로 보장하는 것은 DB의 역할이라고 생각합니다. 다만, 다수의 동시 요청이나 사용자의 반복 클릭(예: 좋아요 버튼을 연속으로 누르는 경우) 상황에서는 애플리케이션 단의 단순한 선행 검증만으로는 이를 제어하기 어렵다고 느꼈습니다. 예를 들어, 아래와 같은 코드에서는 다음과 같은 경쟁 상태(race condition)가 발생할 수 있습니다. T1: exists → false T2: exists → false T1: insert T2: insert ❌ (유니크 제약 위반) if (!likeRepository.exists(postId, userId)) { likeRepository.save(...); } 이처럼 애플리케이션 레벨의 exists → insert 패턴이 동시성 문제를 해결하지 못하는 상황에서 DB 예외에만 의존하지 않고 불필요한 중복 요청과 예외 발생을 줄이기 위해 애플리케이션 단에서는 어떤 방식으로 이를 보완하는 것이 바람직하다고 보시는지 궁금합니다.
킬구형 ㅎㅇ 요즘에 배치 다시 학습하면서 좀 고민인 부분이 있음. 현재 회사에서 배치 Job이 좀 많이 늘어나면서 코드 관리가 너무 어렵더라고. Spring MVC에서는 Controller-Service-Repository 같은 레이어드 아키텍처나 클린 아키텍처처럼 널리 쓰이는 구조가 있는데, 배치 쪽은 이런 패키지 구조나 설계 방식에 대한 레퍼런스가 상대적으로 적은 것 같아서. 최근에 클린 아키텍처를 배우면서 배치에도 이런 구조를 적용할 수 있는지 궁금해졌거든. 지금 나는 대략 이런 식으로 구성하고 있어: batch/ ├── order/ │ ├── confirm/ │ │ ├── OrderConfirmJobConfig.java │ │ ├── OrderConfirmReader.java │ │ ├── OrderConfirmProcessor.java │ │ ├── OrderConfirmWriter.java │ │ └── OrderConfirmJobListener.java ├── payment/ │ ├── settle/ │ └── cancel/ ├── support/ ├── domain/ ├── application/ └── infrastructure/ 하나의 Job을 하나의 큰 애그리게이트처럼 보고 있어서, 관련 클래스를 패키지별로 분리하기보다 한 폴더 안에서 로우 레벨로 관리하는 게 더 편하더라고. 근데 Job이 계속 많아질수록 이게 맞는 건지, 더 나은 방법이 있는 건지 잘 모르겠어서. 혹시 형은 실무에서 Job이 많아졌을 때 패키지 구조나 코드 구성을 어떻게 가져가? 객체 간 위계나 import 의존성 방향 같은 것도 신경 써서 설계하는지도 궁금해. 물론 사람마다 차이가 있겠지만 시간 괜찮으면 경험 공유해주면 도움이 많이 될 것 같아!
학습 관련 질문을 남겨주세요. 구체적으로 적을수록 좋아요! 마크다운과 단축키를 활용하면 글을 더 편하게 작성할 수 있어요. 커뮤니티 질문 & 답변에 비슷한 내용이 있었는지 먼저 검색해보세요. 편하게 질문주세요:) 직접 답변 드리도록 하겠습니다~ 안녕하세요 ! 지금 막 코딩테스트 강의를 시작했는데, 혹시 코딩테스트 개론 << 이거 노션링크를 못찾겠어서 질문드립니다 이론이 글로 적혀있는 노션 공유가 가능할까요? 제가 현재 들어가 있는 노션인데, Part1.코딩테스트 개론 이부분이나 현재까지 강의 들은 알고리즘이나 시간복잡도 설명이 없는거 같아서 제가 못찾는건지.. 어디있나요??
아주 기본적인 질문이지만 내용을 확실히 하고자 질문 남겨봅니다. 현재 섹션2에서 6번째 강의를 들었는데요 21분에 정리해주신 내용을 보면 python은 print()함수 안에서 두번째 파라미터가 end=부분을 잘 살펴보자 라고 하셨는데, end= 뒤에 a,b,c,d가 큰따옴표 없이 end=a,b,c,d로 출력 될 경우 그리고 end="a,b,c,d" 이렇게 출력이 되는 경우 어떻게 출력이 되고 개행은 어떻게 이루어지는지 알고싶습니다.
비전공자이며, 노베이스에서 시나x로 2달간 필기 준비하면서 cbt자료 돌리고, 26년 1회차 필기 합격했습니다. 실기는 책으로 독학 하기에는 힘들다고 생각하여, 유튜브를 찾아보던 중 우연히 알게된 주말코딩쌤.... 수강후기에 누군가 얘기 하시길 이 강의를 보면 50점은 먹고 들어가는거라고 하는 말에 바로 강의 수강을 신청했습니다. 26년 1회차 1트에 합격 간절한 1인 입니다. 실기시험이 4월 중순에서 5월 6일 이전이니까 실기시험 까지 대략 2달~2달 반이 남았는데, 하루 최소 3시간~5시간 계획 중 입니다. 오전 6시~7시반 그리고 출근해서 점심시간에 30분, 퇴근해서 오후8시~10시 더 많이 할 수 있는 날도 있을거고 적게하는 날도 있을건데, 간절한 마음으로 강의 들으며 공부 해보겠습니다. 시험치고 합격 불합격 여부 후기 남기겠습니다. 공부라는게 정말 때가 있더라구요... 매일 공부하고싶은데, 짬내서 하고 많은 걸 포기해야 공부 할 수 있어서 학창시절에 공부 안했던 저를 꾸짖고 싶네요 ㅎㅎ 화이팅입니다!!!!!!
