Event taxonomy design → synthetic event log (benchmark-anchored) → SQL-first Funnel · Cohort Retention · LTV · Segmentation
(EN): I designed a mobile-brokerage event taxonomy (GA4/Amplitude-export-compatible), generated a benchmark-anchored synthetic event log (15,000 users, 90 days, ~384k events, seed=42), and ran the full product-analytics cycle in SQL (PostgreSQL): strict-order funnel with a 14-day conversion window, weekly cohort retention with a D1/D30 calibration check against public benchmarks, observed-LTV curves with CAC scenarios, and RFM segmentation. The data is synthetic and says so loudly. The deliverable is the methodology, not the findings.
이 저장소의 데이터는 합성(synthetic) 데이터다. 가상의 주식거래 앱 "K-Invest"를 설정하고, 유저 행동 이벤트 로그를 직접 설계한 택소노미로 생성했다. 행동 모수는 가능한 한 공개 벤치마크를 기준값으로 삼았고, 전체 모수표와 출처는 ASSUMPTIONS.md에 있다.
| 증명하는 것 ✅ | 증명하지 않는 것 ❌ |
|---|---|
| 이벤트 로그 택소노미를 스스로 설계할 수 있다 | 실제 유저에 대한 인사이트 발견 |
| Funnel·Cohort·Retention·LTV·RFM을 정의부터 세우고 SQL로 계산할 수 있다 | 실서비스 트래픽 위 실험 운영 |
| 생성 데이터조차 벤치마크로 역검증하는 습관 | 실제 전환율·수익률의 절대값 |
"분석 결과"로 서술된 모든 수치는 이 합성 세계 안에서의 측정값이며, 병목의 위치나 채널 품질 차이는 생성기에 심은 가정의 재발견이다. 이 구분을 흐리지 않는 것이 이 프로젝트의 첫 번째 설계 원칙이다.
모바일 서비스 분석의 표준 방법론(LTV·AARRR·Cohort·Funnel)은 "정의를 아는 것"과 "이벤트 로그 위에서 처음부터 끝까지 굴려보는 것" 사이의 간극이 크다. 공개된 실제 핀테크 이벤트 로그는 존재하지 않으므로, 그 간극을 메우기 위해 로그 설계 → 데이터 생성 → 웨어하우스 SQL 분석 → 지표 검증 → 액션 제안의 전체 사이클을 직접 구축했다. 국내 주요 핀테크가 상용 분석 도구 대신 자체 로깅·분석 스택을 운영한다는 점(참고자료 ①②)을 고려해, 특정 도구 사용법이 아니라 어느 스택에서든 통하는 이벤트 데이터 모델링과 SQL에 초점을 맞췄다.
한 행 = 한 이벤트. 공통 필드 user_pseudo_id · event_name · event_timestamp · event_date · event_params(JSON). GA4 BigQuery export / Amplitude 이벤트 구조와 호환되는 형태다. UX 이벤트(screen_view)와 비즈니스 이벤트를 분리하는 구성은 화면·클릭 로그를 자동 수집하는 국내 핀테크의 공개된 로깅 철학을 참고했다(참고자료 ①). 정의는 src/taxonomy.py가 단일 출처다.
| 구분 | 이벤트 | 주요 params |
|---|---|---|
| 획득 | first_open |
channel, device_os |
| 온보딩 Funnel | sign_up → kyc_start → kyc_complete → account_open → first_deposit → first_trade |
amount_krw, fee_krw … |
| 반복 사용 | session_start, screen_view, deposit, trade_executed |
session_id, screen_name, symbol, market, amount_krw, fee_krw |
src/generate_events.py(seed=42)가 유저 15,000명 × 90일(2026-04-01~06-29), 약 38만 건의 이벤트를 생성한다. 핵심 설계:
- 혼합 Retention 모델: 감쇠형(casual)과 바닥 유지형(core) 유저를 섞어 Retention 커브가 평평해지는 구간을 만든다
- 채널별 품질 차이: referral/organic > paid (방향성 가정, 근거는 ASSUMPTIONS)
- 시장 변동성 이벤트일 4일: 거래 강도·금액 스파이크 (증권 서비스의 외생 변수 감도 모사)
- 거래 수수료 롱테일: 소수 헤비 트레이더가 수수료 수익 대부분을 만드는 구조
생성 후 두 단계로 검증한다: ① src/validate.py의 7개 무결성 체크(Funnel 이벤트 유일성·시간 순서·수수료 부호·기간 등), ② 노트북의 캘리브레이션 역검증: 측정된 D1 24.5% / D30 9.4%가 공개 벤치마크 밴드(금융앱 D1 20%·주식거래앱 23%, D30 9~12%; Adjust 2023 글로벌 중앙값) 안에 들어오는지 분석 단계에서 확인.
분석의 순서가 방법론의 순서다: AARRR 지도로 병목 단계를 먼저 찍고(→ Activation 16.1%) → 그 구간을 Funnel로 해부 → Cohort와 실험 설계로 검증 → 개선 효과를 LTV로 환산한다. SQL은 전부 sql/에 있고(파일 상단에 지표 정의 명시, PostgreSQL 방언), notebooks/analysis.ipynb가 그 SQL 쿼리를 그대로 실행한다.
① AARRR 지도: 5단계 대표 지표를 한 표로 깔고 병목 = Activation으로 판정한다. 근거는 두 가지다. Retention과 Revenue는 공개 벤치마크 밴드 안에 있는 반면 Activation 16.1%는 개선 여지가 가장 크고, Activation은 이후 단계 전체에 곱해지는 값이라 같은 폭을 개선했을 때 효과가 가장 크다. 이 병목의 위치 역시 생성기에 심은 가정의 산물이다 — 이 절이 보여주는 것은 병목 그 자체가 아니라, 지도에서 병목을 찍고 해부·검증·환산으로 좁혀 가는 판정 절차다.
② Funnel (해부): 설치→첫 거래 16.1% (conversion window 14일, this order). 절대 이탈 최대 구간은 계좌개설→첫 입금(단계 전환 56%, 이탈 2,421명). 채널로 나누면 첫 거래 전환 referral 42.7% vs social_ads 5.0% (8.5배) → 전체 수치 비교의 함정(구성비 효과)까지 명시.
③ Cohort Retention (검증): 주간 Cohort 히트맵과 채널별 커브. 모든 채널에서 커브가 평평해지며, 평평해진 높이(남는 core 유저)가 채널 품질의 실체: referral ~50% vs social_ads ~25% (W8).
④ LTV(Lifetime Value, 고객 생애 가치) (환산): Cohort 누적 수수료 곡선(관측 LTV 하한): W12 누적 10,200원/설치자. 12개월 연장 시나리오 3.1만~4.8만 원(가정 명시). CAC(Customer Acquisition Cost, 고객 획득 비용) 25,000원 가정 시 LTV:CAC 1.3~1.9로 3:1 기준 미달 → "획득 확대보다 입금 전환·Retention 개선 먼저"라는 판단 연습. 사이클의 마지막 고리로, 병목 개선을 돈으로 번역했다: 입금 단계 전환 56→65% 시나리오에서 앱 설치자당 W12 누적 수수료 +16%(+1.6천 원), 설치 10,000명 Cohort 기준 분기 약 +1,610만 원(선형 비례 가정, 상한 추정으로 명시).
⑤ Segmentation: RFM 5분류: Champions 526명(거래 유저의 21%)이 수수료의 43.8%, 상위 30%가 약 70% (파레토). 변동성 이벤트일 주문은 평상시의 약 1.6배. 증권 지표 분석에서 시장 통제가 필요한 이유다.
⑥ 실험 설계로의 연결: 병목(첫 입금)에 대한 가설→실험 설계까지 작성: 개설 완료 유저 무작위 50:50, OEC = 14일 첫 입금 전환율, 가드레일 = 입금 후 7일 내 전액 출금률. (합성 데이터라 설계까지가 산출물)
pip install -r requirements.txt
python src/generate_events.py # data/ 생성 (seed=42, 항상 동일)
python src/validate.py # 무결성 체크 7종 (DB 무관, pandas)
# PostgreSQL 준비 (로컬 설치 또는 docker 한 줄):
# docker run -d --name kinvest-pg -e POSTGRES_PASSWORD=kinvest \
# -e POSTGRES_DB=kinvest -p 5432:5432 postgres:16
python src/load_postgres.py # 스키마 생성 + COPY 적재 (DATABASE_URL로 대상 지정)
jupyter notebook notebooks/analysis.ipynb분석 엔진은 PostgreSQL이다. 프로젝트마다 실제로 써 온 DB라서(MelMoveNow 백엔드, 교통 분석의 PostGIS, DW 과제) 방언과 실행 계획까지 스스로 설명할 수 있다. 같은 스키마는 Railway Postgres나 Azure SQL(타입 일부 조정)에도 그대로 적재된다.
데이터 파일은 커밋하지 않는다(.gitignore). 생성기가 곧 데이터다. data/sample_events.csv(1,000행)만 미리보기용으로 포함.
한계: 합성 데이터(모든 발견 = 가정의 재발견) · 수수료 외 수익원(환전 수익(외환거래이익)·예탁금 이용료)은 분리해 모사하지 않았다 · 추천 루프/푸시 등 CRM 이벤트 미포함 · LTV 꼬리는 단순 연장. 다음 단계: ① BigQuery 공개 GA4 실데이터(Google Merchandise Store)로 동일 분석 재현(실데이터 + UNNEST 중첩 스키마) ② BG/NBD·Gamma-Gamma 예측 LTV(pymc-marketing) ③ 입금 넛지 실험 계획서(표본 계산 포함).
① 토스 기술블로그, "프론트엔드 로깅 신경 안 쓰기" (디자인시스템 자동 로깅) — https://toss.tech/article/engineering-note-5 ② 토스 기술블로그, 데이터 플랫폼 관련 글 (자체 데이터레이크 구축) — https://toss.tech/article/datalake-iceberg ③ Adjust, "Invest in success with finance app marketing data and insights" (2024) — Retention 벤치마크 — https://www.adjust.com/blog/finance-app-insights/ ④ Mixpanel, "The 2024 Mixpanel Benchmarks Report" — https://mixpanel.com/blog/2024-mixpanel-benchmarks-report/ ⑤ 토스증권 2024년 실적 보도 (영업수익 4,266억 원·MAU 384만 — ARPU 자릿수 기준값) — https://www.industrynews.co.kr/news/articleView.html?idxno=60204 ⑥ David Skok, "SaaS Metrics 2.0" / "Startup Killer" (LTV:CAC 3:1, 12개월 회수 관행) — https://www.forentrepreneurs.com/saas-metrics-2/ ⑦ Google Analytics, BigQuery Export schema (이벤트 구조 참조) — https://support.google.com/analytics/answer/7029846 ⑧ Fader, Hardie & Lee (2005), "'Counting Your Customers' the Easy Way", Marketing Science 24(2) — 예측 LTV 다음 단계 — https://www.brucehardie.com/papers/018/
Author: Gayoung Dan (LinkedIn). AI 페어 프로그래밍으로 만든 프로젝트다. 문제 정의, 이벤트 택소노미, 지표 정의, 모수 기준값 선정, 검증과 해석을 소유하고 코드 초안 작성은 Claude와 협업했다. 전체 코드를 리뷰·수정했으며 처음부터 끝까지 재현할 수 있다.