Daily plan

🌞오전

- 데일리 스크럼
- 데이터 리터러시 강의 정리 끝내기
- 파이썬 라이브세션 2회차 (10:00~12:00)

🔥 오후

- 파이썬 개인 과제 
- 코드카타 SQL 3문제 + python 5문제
- 빅분기 3과목 

🌝 저녁

- 아직 못한 것들 마무리
- 데일리 스크럼 + TIL 제출

---

SQL 코드카타

Q67 - 주문량이 많은 아이스크림들 조회하기

select f.flavor
from first_half f 
    join (select shipment_id, flavor, sum(total_order) total_order
          from july 
          group by flavor) j
    on f.shipment_id = j.shipment_id
order by f.total_order + j.total_order desc
limit 3

정답이라고 하긴 하는데 뭔가 찝찝하다...

문제에서 "7월에는 아이스크림 주문량이 많아 같은 아이스크림에 대하여 서로 다른 두 공장에서 아이스크림 가게로 출하를 진행하는 경우가 있습니다. 이 경우 같은 맛의 아이스크림이라도 다른 출하 번호를 갖게 됩니다."라는 조건이 있다.
즉, july 테이블에서는 같은 flavor라도 다른 shipment_id를 가질 수 있다는 의미이다.

나는 서브쿼리에서 july 테이블을 flavor 기준으로 그룹화하고 맛별 total_order를 합한 새 컬럼을 생성한 후 first_half 테이블과 join하는 방식으로 문제를 풀었다.

july 테이블에 위와 같이 맛은 같지만 shipment_id는 다른 데이터가 존재했다.
내가 작성한 서브쿼리 내에서 그룹화되는 과정 중 앞 번호인 109가 shipment_id로 선택되었기 때문에 first_half테이블과 조인하는 데에서 아무 문제가 없었다. 하지만 만약 딸기맛의 다른 shipment_id가 209가 아니라 99였다면 원하는 대로 답이 나오지 않았을 것 같다.
따라서 내가 작성한 코드가 정답처리 되긴 했지만 좋은 코드는 아니었던 것 같다.

차라리 조인할 때 shipment_id가 아닌 flavor를 기준으로 조인을 하는 게 나으려나..?
(챗지피티도 shipment_id말고 flavor로 조인하는 게 맞다고 하네,,)

Q68 - 저자 별 카테고리 별 매출액 집계하기

SELECT A.AUTHOR_ID, A.AUTHOR_NAME, B.CATEGORY, SUM(BS.SALES*B.PRICE) TOTAL_SALES
FROM 
    (SELECT BOOK_ID, SUM(SALES) SALES
    FROM BOOK_SALES
    WHERE SALES_DATE LIKE "2022-01%"
    GROUP BY BOOK_ID) BS
    LEFT JOIN BOOK B ON BS.BOOK_ID = B.BOOK_ID
    JOIN AUTHOR A ON B.AUTHOR_ID=A.AUTHOR_ID
GROUP BY A.AUTHOR_ID, B.CATEGORY
ORDER BY A.AUTHOR_ID, B.CATEGORY DESC

SUM이 2번 들어가야 한다는 걸 이해하기 어려웠다.

서브쿼리를 통해 BOOK_SALES 테이블에서 2022-01에 BOOK_ID별로 각각 얼마나 판매되었는지를 구하고, BOOK 테이블과 AUTHOR 테이블을 조인해주었다.

그리고 BOOK_ID 별 판매량을 이용해서 다시 작가ID, 카테고리 별로 판매량을 구해주어야 한다. 각 BOOK_ID는 하나의 책을 가리키는데, 동일한 작가가 동일한 카테고리로 여러 권의 책을 쓴 경우도 있다. 즉, 작가와 카테고리로 그룹화를 했을 때 각 행에 포함되는 BOOK_ID는 여러 개일 수 있다는 것이다.
따라서 서브쿼리 내에서 더해준 BOOK_ID별 판매량을 작가와 카테고리 기준으로 한 번 더 더해주어야 한다.

Q69 - 대여 횟수가 많은 자동차들의 월별 대여 횟수 구하기

SELECT MONTH(START_DATE) MONTH, CAR_ID, COUNT(1) RECORDS
FROM CAR_RENTAL_COMPANY_RENTAL_HISTORY
WHERE CAR_ID IN 
     (SELECT CAR_ID
      FROM CAR_RENTAL_COMPANY_RENTAL_HISTORY
      WHERE DATE_FORMAT(START_DATE,"%Y-%m") BETWEEN "2022-08" AND "2022-10"
      GROUP BY CAR_ID
      HAVING COUNT(1)>=5) 
      AND DATE_FORMAT(START_DATE,"%Y-%m") BETWEEN "2022-08" AND "2022-10"
GROUP BY MONTH(START_DATE), CAR_ID
HAVING COUNT(1)>0
ORDER BY MONTH, CAR_ID DESC

서브쿼리 내에서도 2022-08 ~ 2022-10으로 기간을 설정하고, 서브쿼리 밖에서도 동일하게 기간을 설정해줘야 한다. (이걸 빼먹어서 오래 걸렸다..ㅠ)

서브쿼리는 해당 기간 내에서 총 대여 횟수가 5회 이상인 CAR_ID만 추출한 것이다.
서브쿼리에 포함된 CAR_ID만을 기준으로 MONTH, CAR_ID로 그룹화한 후 '해당 기간동안' 각각 몇 번 대여되었는지를 구해야 한다.

5문제는 풀고 싶었는데 뒤로 갈수록 난이도가 올라가서 시간이 너무 오래 걸린다ㅜ.ㅜ

---

데이터 리터러시 (2)

TIL#15_데이터 리터러시(1)

3. 지표 설정

지표

• 특정 목표나 성과 측정을 위한 구체적이고 측정 가능한 기준
• 목표 달성도 평가 및 전략적 결정에 필요한 핵심 정보 제공
• 정의한 문제에 대해 정확히 파악하기 위해 필요

문제 정의 = 어떤 문제를 풀고자 하는가?
지표 설정 = 어떤 결과를 기대하는가?

주요 지표

• 활성 유저 (Active User)

  • 활성 유저에 대한 정의에 따라 전략과 방향이 달라지며, 이탈 유저가 정의됨

  • 투자를 위한 서비스 지표에 중요한 역할

  • 활성 유저 설정 (예시)

    1) 사이트 진입 유저
    - 메인 홈 화면 진입시 활성 유저로 정의됨
    - 허들이 가장 낮고, 활성 유저 지표가 가장 높게 측정됨
    - 해당 유저 대상 액션 효율이 떨어진다는 단점

    2) 사이트 진입 후 추가 행동을 한 유저
    - 허들이 두번째로 낮음
    - 사이트 진입 유저 보다 대상 액션 효율이 높을 수 있음

    3) 서비스 최종 액션까지 수행한 유저
    - 가장 허들이 높음
    - 자사 서비스의 Goal 액션을 하고, 핵심과 효용성을 경험한 유저
    - 해당 유저 대상 액션을 할 때 효율과 이익이 가장 높음
    - 활성 유저 지표가 가장 낮게 측정

  • 우리 서비스만의 active user를 찾기 위해서 고려해야 할 사항들
    - 어디까지 경험한 유저가 활성유저인지
    - 일반유저와 활성유저의 분류 기준
    - 어디서 우리 서비스의 효용성을 느낄지
    - 우리가 핸들링할 수 있는 유저의 사이즈는 어느 정도인지

    그 외 주요 지표
    - 전체 Active User : 앱 접속 이력이 있는 유저
    - 서비스별 Active User : 서비스별 서브메인 이하 추가 액션이 있는 유저
    - DAU / WAU / MAU (Daily/Weekly/Monthly Active User)
    - 이탈유저 (이탈율) : 전체 DAU로 잡혔지만 각 서비스의 DAU로는 잡히지 않은 유저의 비율
    - CVR (Conversion Rate) : 특정 행동 후 전환된 비율
    - CTR (Click Through Rate) : 어떤 페이지 접근 후 특정 요소를 클릭한 비율

• 재방문율 (Retention Ratio)

  • 서비스를 사용한 사람이 다시 서비스를 사용하는 비율을 의미 (몇%의 유저가 우리 서비스를 다시 사용하는가?)

  • Retention
    : 한번 획득한 유저가 서비스로 다시 돌아왔는지에 대한 지표로, 서비스(특히 앱서비스) 성장에 매우 중요함

  • 리텐션이 높은 서비스는 획득 비용에 투자한 비용을 빠르게 회수 할 수 있음

  • 일반적으로 리텐션은 시간에 지남에 따라 자연스럽게 감소하는데, 시장에 적합한 서비스는 기울기가 점점 완만해지며 안정화되는 그래프를 가짐

  • 리텐션 측정 방법

    1) N-Day 리텐션 (or N-Week, N-Month)
    : 최초 사용일로부터 N일 후에 재방문한 Active User의 비율

    • 일반적으로 사용하는 리텐션 지표이며, 매일 습관적으로 사용하거나 반복적으로 행동을 유도하는 제품에 적합 (카카오톡, 인스타그램, 게임 등)
    • 유저가 Active user로 집계된 최초의 날을 Day0으로 설정하고, Day0에 활성 상태가 된 모든 유저들의 N일차 리텐션을 계산함
    • 서비스 사용 주기가 긴 경우에는 실제보다 더 과소평과 될 수 있다는 한계점 (매일 접속하다가 하루만 접속하지 않더라도 그 사람은 그 날의 리텐션 비율에 포함되지 않으므로 과소평가 될 수 있음)
    • 사용 주기가 긴 서비스들에서 N-day 리텐션을 적용하면 잘못된 액션을 할 가능성이 존재함 (불필요한 할인, 푸쉬 메세지 발송 등)
      

    2) Unbounded 리텐션
    : 특정 날짜를 포함하여 그 이후에 재방문한 유저의 비율
    특정일을 포함하여 그 이후에 한번이라도 재방문한 유저의 비율

    • 정기적으로 반복해서 방문하는 서비스가 아닐 경우에 적합함 (채용 사이트, 쇼핑몰, 부동산 매물 서비스 등 사용 빈도가 높지 않은 서비스에 활용하기 적합)
    • Unbounded 리텐션은 이탈률의 반대 개념으로 이해할 수 있음
    • 오랫동안 접속하지 않았던 유저가 접속할 경우 이전의 리텐션 값들까지 모두 변동되는 상황이 발생 가능하다는 한계점
    • 절대적 수치보다는 지표가 어떻게 변화하는 지, 트렌드 확인 용도로 활용하는 것을 권장

    3) Bracket 리텐션
    : 설정한 특정 기간에 대해 재방문율 측정
    (N-Day리텐션을 확장한 개념으로, 일/주/월 단위가 아니라 지정된 구간으로 나눔)

    • 활성 유저가 특정 활동을 위해 각 Bracket 내에 서비스 재방문시 잔존 유저로 해석됨
    • 하루 정도 서비스 접속을 안해도 리텐션에 영향을 주지 않으므로 기준이 더 널널함
    • 사용주기가 길거나 주기적인 경우에 사용하기 적합 (식료품 배달 서비스, 세차 서비스 등)

  • 리텐션이 높은 세그먼트를 발굴하는 작업이 필요함

  • 서비스 사용 주기에 따라 리텐션 조회 기간을 늘려야 함

  • 사후 분석 시 용이

• 퍼널 (Funnel)
  

  • 잠재고객을 유입시키며 최종적인 목표 액션 달성까지의 과정

  • 유저가 어디서 이탈하는지 확인하기 위한 구조화

  • 모든 서비스와 비즈니스는 각 단계로 갈수록 이용자 수가 감소함

  • 각 단계의 전환율 또는 첫 유입 대비 전환율을 측정

    AARRR
    : 디지털 마케팅시 퍼널을 활용하는 프레임워크
    - 단계별 전환율을 지표화하여 서비스 보완 지점을 탐색
    

• 고객 평생 가치 (LTV, Life Time Value)

  • 고객 생애 주기 : 유저 한 명이 서비스 사용을 시작하여 이탈할 때까지의 기간

  • LTV는 한 명의 유저가 생애 주기 동안 얼마만큼의 이익을 주는지 정량적으로 지표화 한 것

  • 유저와의 관계를 측정하고 이를 사업적 이익으로 가져가기 위해 중요한 지표

  • LTV가 높으면 서비스와 관계가 좋고 충성도가 높은 고객이 많다는 것을 의미

    LTV 산출 방법
    (다각도의 고민을 통해 여러가지 방법 중 선택)
    (1) 이익 * LifeTime * 할인율(미래 비용에 대한 현재 가치)
    (2) 연간 거래 * 수익률 * 고객 지속 연수
    (3) 고객 평균 구매 단가 * 평균 구매 횟수
    (4) (매출액 - 매출 원가) / 구매자 수
    (5) 평균 구매 단가 * 구매 빈도 * 구매 기간
    (6) (평균 구매 단가 * 구매 빈도 * 구매 기간) - (신규 획득 비용 + 고객 유지 비용)
    (7) 월 평균 객단가 / 월 가중 평균 잔존율

  • 자사 서비스에 딱 맞는 LTV 산출은 매우 어려운 일이며, 사용주기, 변수, 객단가 등 여러 요소들을 고려해야 함 (단순히 산출식에 집중하는 것이 아니라 '왜 쓰이는지?'에 집중해야 함)

  • LTV를 늘리기 위해서는 객단가 상승, 구매 빈도 증가, 이탈률 감소, 이용시간 증가 등의 방안이 있음

  • LTV는 가정을 베이스로 하는 지표이므로 꾸준한 모니터링이 필요함

북극성 지표

• 제품/서비스의 '성공'을 정의

• 제품/서비스가 유저에게 주는 core value를 가장 잘 나타낸 것

• 장기 성장을 위해 모니터링이 필수적

• 좋은 북극성 지표란?

  • 제품/서비스 전략의 핵심과 고객이 느끼는 가치를 잘 나타내며
  • 회사의 사업 목표를 나타내는 지표 중 후행지표가 아닌 선행지표
  • 좋은 북극성 지표를 위한 고려 사항

      - 언제 유저가 목적을 달성하는지
      - 모든 유저의 해당 여부
      - 측정 가능한 지표인지
      - 측정 주기가 적절한지
      - 외부 요인의 영향
      - 북극성지표의 성장이 사업의 성장과 함께 하는지
      - AARRR 퍼널 전 과정이 북극성 지표에 영향을 주는지
      - 북극성지표의 변화를 적어도 매주 관찰 가능한지

• 좋지 않은 북극성 지표

  • 외부 요인의 영향을 많이 받은 지표
  • 유저의 전체 여정을 반영하지 않은 지표
  • 유저가 직접 가치를 느낄 수 없는 지표
  • 측정 불가하거나 기간 설정이 안되는 지표

상황에 따라서 좋지 않은 지표라도 북극성 지표가 될 수 있음

• 북극성 지표는 전 직원을 하나의 목표에 집중시키며, 중복으로 일하는 것을 방지하여 효율을 증대시킴

4. 결론 도출

결과
: 데이터처리, 분석, 모델링 후 얻어진 구체적인 데이터의 출력
- 숫자, 통계, 그래프, 차트 등으로 나타낼 수 있음
- 계산과 분석을 통해 나온 결과물

결론
: 분석된 데이터 결과를 바탕으로 이끌어낸 의미나 통찰
- 데이터에 기반한 해석, 추론, 권고 사항을 포함
- 목적에 대해 어떤 의미가 있는지 설명하는 것

• 결론 도출 시에는 스토리텔링이 필요하지만, 필요 이상으로 자신의 해석을 융합하는 것이 아니라 데이터를 통해 알 수 있는 범위에서만 생각해야 함
• 문제 정의, 지표 설정을 할 당시의 목적을 떠올리며 정리
• 결론을 공유할 대상이 누구인지, 어떤 변화를 원하는지 등을 생각해야 함

1) 단순하고 쉽게 전달

- 핵심 지표 위주로 먼저 공유
- 지표 해석법 설명
- 해당 지표에 오너십이 있는 조직에서 활용할만한 포인트 제안
- '액션 아이템'을 전달하는 것이 핵심!

2) 흥미 유발

- 모든 내용이 아닌, 상대가 궁금해할만한 내용을 고민하고 필터링하여 전달
- 궁금한 사람들을 위해 디테일한 문서를 따로 공유

3) 대상자 관점에서 접근

- 대상자(공유 받는 사람)가 이해하기 쉽게 정리
- 지식의 저주에 빠지지 않고 논지를 뒷받침 할 자료 첨부
- 대상자의 허들이 낮은 시각화 활용
 (시각화는 화려한 그래프보다 직관적으로 이해 가능하도록 구성)

---

SQL이 생각보다 너무 안풀려서 거기에 기가 다 빨렸다,,
파이썬을 못 했다는 뜻....
아무래도 나머지 공부를 해야할 것 같다ㅜ.ㅜ
빅분기도 너무 놓고 있었는데 생각보다 시간 별로 안남아서 발등에 불떨어졌다ㅎ
암튼 열심히 하자 (o゜▽゜)o☆