2021 데이터야놀자에서 들은 내용을 적어 보았습니다.

schedule

1. 밑바닥부터 시작하는 프로덕트 데이터 분석

  • 매스프레소: 데이터 드리븐 프로덕트 개발
  • 실험 설계
    • 정형화된 프로세스 정립
  • 데이터 수집
    • 의사결정하기 위해 필요한 데이터 명확화
    • 실험, 대조군 할당은 필수
    • 데이터는 어디에 남길 것인가? 서버/클라이언트 DB 중 선택
  • 성과 분석
    • ATE: 실험군, 대조군 전체 비교
    • CATE: 조건 걸어 계층화. 유저를 그룹화한 후 그 안에서 실험군, 대조군 나눔
  • 일련의 과정에서 인과 추론(Causal Inference)을 공부하기도 함
  • 큰 사이클에서 푸는 문제들: Metric Hirarchy
    • 조직의 최상위 KPI로부터 내려가는 구조
    • Focus: 최상위 지표(KPI). (ex: 구독자 수)
    • 여기서 작은 단위의 지표 탐색. (ex: 유료 구독자 수)
  • 문화 만들기 및 레슨런 공유
    • 조직에서 다들 실험을 하고 싶어 하는데, 어떻게 해야 할까?
    • 슬랙을 통해 공유


2. 깨진 데이터도 다시 보자: Dynamic Mapping의 함정

  • Elastic 소속
  • 수 십년간 사용해 온 RDBMS의 형태적인 한계로 인해 NoSQL 등의 DB가 생겨난 상태
  • NoSQL
    • 스키마가 일정하지 않은 데이터 저장
    • 접속 로그. 시스템 메트릭, SNS 피드 등의 저장에 유용
    • 데이터가 입력되는 순간 각각의 필드를 보고 데이터 타입 매핑
  • Dynamic Mapping
    • 입력되는 데이터를 보고 알아서 매핑하는 기능
    • join 대신 서로 다른 매핑 데이터를 모을 수 있음
    • 데이터 타입 호환성도 제공. “6.3” → 6.3으로 인식
  • ElasticSearch
    • 소수점 있는 실수 값 입력하면, 정상적으로 저장은 되지만 5.7, “6.3”같이 그대로 저장되어 있음
    • Max 값을 계산할 때 오류 남. 정수로 저장됨. 5.7 → 5, “6.3” → 6
  • ElasticSearch 저장하는 구조
    • inverted index 사용. 저장된 텍스트 텀을 가지고 저장된 도큐먼트 아이디(위치) 저장
    • query phase, fetch phase
      • inverted index → index → 실제 데이터 찾는 과정
  • 5.1 ~ 5.9 range 숫자를 찾으면, 소스에는 5.7이 나와야 하지만 실제로는 5로 저장되어 검색되지 않음
  • 정수 타입으로 매핑이 되면, 실수가 모두 정수로 들어오게 되어 분석시 오류가 생김
  • ElasticSearch도 항상 데이터를 입력하기 전에 매핑 확인해야 함
  • 문제 발생시 오류 메시지 띄워 확인해야 함
  • 원래 필드에 데이터가 들어가야 하는데, 필드가 계속 생성되는 오류도 있음


3. 관점에서 시작하는 데이터 엔지니어링

  • 당근마켓
  • 관심사가 같더라도(카페가 잘 되는지?), 카페에서 사람 관점으로 보느냐, 음료 관점으로 보느냐에 따라서 로깅하는 데이터가 달라질 수 있음
  • 당근마켓이 사용자를 잘 이해하기 위해서, 어떤 관점으로 바라봐야 할까?
    • 어떤 물건을 구매하는지 등
  • 사용자들 카테고리화: perspective schema 생성
  • 카페 예시로 다시
    • 어떤 자리가 인기가 있느냐가 궁금할 때, 음료 갯수로 볼 수 있음
    • 근데 해당 자리에 체류 시간이 턱없이 적다고 하면, 체류 시간을 몰랐을 때와는 완전히 다른 결과
  • 클릭, 좋아요 등의 데이터는 만병통치약이 아님
    • 어떤 이유로 해당 액션이 이루어졌는지 알기 어려움
    • 사용자들이 여러 액션들을 하게 된 과정을 비디오로 볼 수 있으면 좋겠지만, 최대한 알 수 있도록 데이터를 설계해야 할 것
  • 데이터 엔지니어의 역할
    • 수동적으로, 요건대로 작업하는 경우가 많음
    • 클릭 대신 클릭++ 라는 좋은 metric을 개발함. 능동적으로 이거 쓰게 해 주세요, 라는 ‘데이터 홍보팀’의 역할도 함
  • 데이터 엔지니어가 능동적으로 하지 못하고 있는 이유
    • R&R 불분명. 인사이트를 내는 역할 / 인사이트를 내기 위한 metric을 만드는 역할 등
    • 데이터 팀을 바라보는 회사의 시각이 진화할 필요 있음


4. Data Driven Decision을 위한 데이터 플랫폼 구축기

  • 카카오모빌리티
  • 실험 플랫폼, 유저 행동 플랫폼 등을 Kubernetes로 개발
  • 테이블은 점점 많아지고, 일일이 SQL로 확인하기 어려운 상황
  • 현재 2,800만 유저의 방대한 행동 데이터 수집
  • 사내에서 데이터 활용 니즈는 증가하는데, SQL만으로는 유저의 교차 사용 패턴 등 인사이트 확인 어려움. 분석팀이 요청 사항을 모두 확인하기 어려움
  • 데이터 파이프라인 통해 유저 행동 패턴 확인, 세그먼트 나눔

이벤트 스키마 정의

  • 이벤트는 발생 시점에 다양한 정보를 담고 있어야 함
  • Event Property, User Property
  • Amplitude 등에서 제공하는 이벤트 템플릿 사용하여 이벤트 스키마 정의
  • 이벤트 스키마는 메타데이터로 관리되어야 함. 메타데이터를 이용하여 이벤트 로그 validation check

User Data와 User segmentation

  • 매출, 사용 빈도 등 고려하여 유저 CVL 관리. 데이터 분석, 마케팅에 활용
  • Custom Segment 생성, 관리할 수 있는 플랫폼 제공 (User Property 이용)
  • 이렇게 만든 세그먼트를 API 형태로 제공. 타겟 고객 정할 때 사용

AB Test

  • 기존과 다르게 택시 호출 상품이 다양해짐
  • 호출 상품에 따라 예상 요금 제공하는 기능 제안
  • 기능 제공 여부를 실험을 통해 검증
    • CTR 차이 거의 없고, 빠른 상품 비교 가능하다는 결과
  • AB 테스트 절차가 복잡한 경우, 실험보다는 추측으로 의사결정 하게 됨
  • Experimentation Platform 통해 실험 관리
  • 실시간 파이프라인을 통해 주요 metric 확인 가능
  • critical path
    • 화면 넘어가는 단계. 호출 탐색 → 호출중 → 호출 완료 → 운행 완료
    • 유저가 최근에 사용했던 도착지를 다시 사용하는 경우가 많음 → 도착지 자동 입력 기능 제공