Case study · 03 · 실무
KPI Tree 설계와
앰플리튜드 택소노미 구축
인강의 핵심 지표를 정의하고,
지표를 볼 수 있는 분석 환경을 구축했습니다.
배경IELTS 개편 후 사업운영부서가 단순 매출과 GA4만 참조. 도입을 직접 제안해 시작
문제지표가 떨어져도 어디서 떨어졌는지 특정할 층이 없음. 측정 대상이 정의되지 않은 채 수집만 하는 구조
전략도구 도입 전에 KPI Tree부터: 핵심 가치 정의, NSM 확정, L0~L3 설계, 부서 합의, 그 트리를 재는 이벤트만 택소노미로
임팩트L0~L3 4계층 부서 합의 · 이벤트 40여 종 · User Property 37종 · 코호트 12종 배포 · L1~L3 대시보드 운영
수행 기간 · 역할 범위 · 산출물 · 협업
수행 기간 설계 '26.05~06 , 개발 연동·스테이징 검수·라이브 배포 '26.07 , 대시보드 구축 후 모니터링 (현재)
역할 범위 사업부서 제안 · 핵심 가치(Core Value) 정의 · NSM 확정 · KPI Tree 설계 · 택소노미 작성 · 유관부서 협의 · 개발 연동 · 스테이징 검수 · 대시보드 구축
산출물 KPI Tree L0~L3 · 이벤트 40여 종 · User Property 37종 · 코호트 12종 · 네이밍 규칙 및 정합성 체크리스트 · SDK 설치 가이드 · L1~L3 대시보드
스코프 IELTS 인강 + 어학원 · 앰플리튜드 신규 도입 · GA4 병행
협업 코어 3인 (기획 1 · 개발 1 · 컨텐츠마케팅팀 1) / 전체 관여 8인 · 3개 조직 (개발 1 · 컨텐츠마케팅팀 4 · 디자인 2 결과 공유) · 컨텐츠마케팅팀 부서장 포함
역할 범위 사업부서 제안 · 핵심 가치(Core Value) 정의 · NSM 확정 · KPI Tree 설계 · 택소노미 작성 · 유관부서 협의 · 개발 연동 · 스테이징 검수 · 대시보드 구축
산출물 KPI Tree L0~L3 · 이벤트 40여 종 · User Property 37종 · 코호트 12종 · 네이밍 규칙 및 정합성 체크리스트 · SDK 설치 가이드 · L1~L3 대시보드
스코프 IELTS 인강 + 어학원 · 앰플리튜드 신규 도입 · GA4 병행
협업 코어 3인 (기획 1 · 개발 1 · 컨텐츠마케팅팀 1) / 전체 관여 8인 · 3개 조직 (개발 1 · 컨텐츠마케팅팀 4 · 디자인 2 결과 공유) · 컨텐츠마케팅팀 부서장 포함
IELTS 플랫폼 개편 후 사업부서가 단순 매출 데이터와 마케팅 성과만을 모니터링한다는 것을 확인하고, 사업부서에 도입을 제안해 시작한 프로젝트입니다. "EDM IELTS 인강의 핵심 가치가 무엇이고, 그것을 깊이 있게 들여다볼 지표와 이벤트를 어떻게 설계할 것인가"를 확정하는 걸 핵심축으로 두고, 앰플리튜드를 도입했습니다.
L0~L3
KPI 4계층
개입 가능성 기준 분리
개입 가능성 기준 분리
37종
User Property
갱신 규칙 개별 정의
갱신 규칙 개별 정의
12개
코호트
경고 임계값 포함
경고 임계값 포함
L1~L3
대시보드 구축
현재 모니터링 중
현재 모니터링 중
01 · PROBLEM무료 혜택 이용 이후의 행동 데이터 부재
IELTS 플랫폼 개편을 끝내고 운영 지표를 모니터링하다가 걸린 게 있었습니다. 당시에는 매출과 유입 지표를 주로 보고 있었고, 무료 혜택 사용 이후의 수강·결제 흐름은 충분히 수집하지 못하고 있었습니다.
매출은 결과라서 이미 벌어진 일만 알려줌. 당시 GA4 설정과 수집 항목으로는 어떤 사용자가 어디서 멈추고 무엇을 하다 결제까지 갔는지를 확인하기 어려웠습니다. 개편과 신규 상품 런칭으로 매출은 우상향, 트래픽도 늘고 있었음. 그러나 별개로 무료 사용자의 동선을 파악할 수 있는 분석 도구나 지표는 부재한 상황
측정 밖에 있던 구간: 가입 혜택 2종
IELTS는 가입 혜택으로 24시 무료 패키지와 무료 레벨테스트를 제공합니다. 결제 전에 상품을 판단하게 만드는 구간이라, 실질적인 유료 전환 입구입니다.
- 두 혜택 모두 모객용 프로모션으로만 운영됨. 발급 건수는 집계되지만 쓴 다음의 행동은 남지 않음
- 24시 패키지 - 핵심 가치인 강의를 제공하는데도 어떤 강의를 재생했는지, 얼마나 들었는지, 실제 결제로 이어졌는지 관측 불가. 이 구간을 분석해야 다음에 무엇을 만들지까지 판단할 수 있는데 그 값이 비어 있었음
- 레벨테스트 - 쿠폰 사용 현황까지만 모니터링. 얼마나 들어오는지, 응시 시작에서 완료까지 어디서 멈추는지, 응시를 마친 유저 중 실제 결제 페이지에서 쿠폰을 적용한 유저가 얼마나 되는지는 미집계
혜택 사용 후의 행동이 남지 않으니 이탈이 프로모션 문제인지 콘텐츠 문제인지 구분할 방법이 없는 상태. 다른 소재로 광고를 돌리거나 트래픽을 더 붓는 것 말고 할 수 있는 판단이 제한적
지표가 아예 없었던 건 아니지만 보는 범위가 판단에 못 미쳤습니다.
사업부서에 관련 부서가 모두 같은 목표로 Align 될 수 있게 KPI Tree를 만들고, 두 혜택을 중심축으로 하는 행동 데이터 분석 환경을 갖추자고 직접 제안했습니다.
사업부서에 관련 부서가 모두 같은 목표로 Align 될 수 있게 KPI Tree를 만들고, 두 혜택을 중심축으로 하는 행동 데이터 분석 환경을 갖추자고 직접 제안했습니다.
측정 대상을 정하지 않고 수집부터 시작하면 대시보드를 만들어도 부서마다 다른 지표를 보게 됨. 그래서 도구가 바뀌어도 판단 방식이 남도록 KPI Tree를 먼저 설계하고 유관부서(콘텐츠 마케팅팀 · CS · 개발팀 · 디자인팀)와 필요한 지표를 합의한 뒤 이벤트를 정의
02 · THE DECISIONNSM부터 역추적한 지표 설계
✕툴 도입, 이벤트 심기, 대시보드, 나중에 지표 정의
1핵심 가치 정의: 사용자가 우리 플랫폼에서 실제로 누리는 것이 무엇인가
2NSM 확정: 유료 구매자 건수. 모든 지표의 최종 수렴점
3KPI Tree L0~L3 설계 + 유관부서 합의
4트리를 측정하는 데 필요한 이벤트만 택소노미로 옮김
✓모든 이벤트가 KPI Tree의 어느 노드를 위한 것인지 역추적 가능
협의 · 검수 · 배포
1사업부서 제안·설득: 매출과 GA4만으로 부족한 이유, 도입하면 새로 무엇을 볼 수 있는지를 KPI Tree로 제시해 필요성 합의. 주요 지표 외에 사업부서가 추가로 보고 싶어 하는 데이터까지 확장해 분석 범위 확정
2이벤트 택소노미 설계: KPI Tree의 각 노드를 재는 데 필요한 이벤트 40여 종·User Property 37종·코호트 12종을 정의하고, 발화 시점·속성 스펙·네이밍 규칙을 개발이 그대로 구현할 수 있는 형태로 확정
3유관부서 협의·조율: 마케팅·운영·CS가 각자 쓰던 용어를 하나로 맞춤. 같은 지표를 부서마다 다르게 부르면 택소노미가 성립하지 않음
4개발 연동 - SDK 설치 가이드를 정리해 전달하고, 이벤트별 발화 시점·속성 스펙을 개발이 그대로 구현할 수 있는 형태로 넘김
5스테이징 검수: 심어진 이벤트를 테스트 서버에서 직접 확인하고, 차이를 택소노미에 반영
6라이브 배포에서 대시보드 구축으로: 검수를 통과한 이벤트만 실서버로 올리고, L1~L3 주요 항목을 대시보드로 구성
스테이징 검수를 통해 택소노미 수정 업데이트
발화 시점이 한 단계 이르거나, 속성이 비어 있거나, 이벤트가 중복으로 계속 잡히는 등
문서상 정의와 실제 발화는 어긋나는 경우가 있어
개발이 심은 이벤트를 스테이징에서 집중 검수했습니다. 어긋난 정의로 배포되면 그 기간의 데이터는 다시 수집할 수 없고, 잘못 쌓인 값도 대시보드에는 정상 수치로 찍힙니다.
- 검수 결과로 택소노미를 보완: 실제 발화와 정의가 다른 지점을 문서에 반영하고, 검수 과정에서 필요하다고 판단된 이벤트·속성을 추가
- 상태 컬럼으로 단계 추적: 이벤트마다
Staging Live(테스트배포)→Production Live(실서버배포)로 올리며, 무엇이 어디까지 검증됐는지를 문서 하나로 관리 - 우선순위로 리소스 배분 -
P0~P3를 부여해 KPI 분자·분모에 직접 쓰이는 이벤트부터 검수·배포
03 · KPI TREE개입 가능성을 기준으로 나눈 KPI 4계층
레이어를 크기나 중요도가 아니라 "이 층을 사람이 직접 움직일 수 있는가"로 나눴습니다. 그래야 지표가 떨어졌을 때 무엇을 해야 할지가 층에서 바로 나옵니다.
L0 (NSM)최종 수렴점직접 개입 불가월간
유료 구매자 건수
↓
L1 핵심NSM을 구성하는 축간접 개입만 가능주간
혜택 발급률혜택 실사용률결제 전환율
↓
L2 드라이버실제로 손댈 수 있는 층직접 개입주간
무료 패키지 강의 진도율무료 CDT 응시율레벨테스트 응시완료율결제 페이지 도달률
↓
L3 진단원인을 좁히는 층진단 목적진단 시에만
진입 대비 재생 전환결제버튼 클릭률결제창 완료율
L1을 혜택 발급률·실사용률로 잡은 이유: 무료 혜택이 유료 전환의 입구이기 때문. 01에서 측정이 비어 있던 구간이 그대로 L1이 됨. 지표를 새로 늘린 게 아니라, 못 보고 있던 구간을 최상위 축으로 올린 것
검증되지 않은 지표에는 승격 조건을 걸어 KPI에 미리 섞이지 않게 함. Referral 계열은 +5%p 이상 기여가 확인될 때만 L1으로 승격. 가설과 확정 지표를 같은 층에 두지 않기 위한 규칙
04 · TAXONOMY이벤트와 속성: 정의·네이밍 규칙을 한 문서(SSOT)로 관리
택소노미가 무너지는 이유는 대개 기술이 아니라 이름. 같은 의미가 두 이름으로 존재하는 순간 지표가 갈라지므로, 네이밍을 규칙으로 못 박고 검수 항목으로 편입
| 규칙 | 올바른 예 | 잘못된 예 |
|---|---|---|
| 표기법 snake_case | page_viewed | PageViewed / pageViewed |
| 이벤트 구조 [object]_[action] | lecture_progress_80pct | progressOption |
Boolean is_ / has_ | is_first_payment | first_payment |
진도율 _progress_NNpct | lecture_progress_50pct | progress50 / completion |
| 단위 구분 | 강의는 lecture_, 옵션은 enroll_ | 둘을 섞어 쓰기 |
| SSOT | 같은 의미의 데이터는 어디서든 같은 이름 is_first_payment vs is_first_buyer 혼용 금지 | |
User Property 37종: 갱신 규칙을 속성마다 정의
속성은 "무엇을 담는가"보다 "언제 어떻게 덮어쓰는가"가 어려움. 세 가지 갱신 방식을 구분하고 속성마다 지정
Set
발생할 때마다 최신값으로 덮어씀
user_type, last_active_date
Set Once
최초 1회만 기록, 이후 불변
signup_channel, signup_date, first_payment_at
Add
누적 가산
lecture_complete_cnt, total_payment_amount
가장 까다로웠던 규칙: CDT 점수는 과목별로 응시를 할 수 있어, 과목별 응시 회차가 다름. 이번 회차에 Reading만 봤다면 Listening을 null로 덮어쓰면 안 됨. 그래서 "미응시 과목은 마지막으로 응시한 회차의 점수를 유지(null 덮어쓰기 금지)"를 규칙으로 명시하여 점수대별 전환율 분석이 조용히 망가질 수 있는 상황 방지.
이벤트로 분리할 것인가, 속성으로 담을 것인가
같은 행동을 이벤트로 쪼갤수록 카디널리티가 불어나고 분석이 오히려 어려워짐. 설계 중 두 건을 이벤트에서 속성으로 내렸습니다.
- 옵션 진도율: 초안은 옵션(전체 강좌) 진도율을
enroll_progress_50pct·enroll_progress_80pct로 각각 이벤트 정의. 그러나 KPI의 주요 측정 대상은 강의 단위 진도율이라 옵션 진도율까지 이벤트로 둘 이유가 없었음, 이벤트는enroll_progress하나로 두고 진도율 값을 속성으로 - 상품 상세 진입 경로: 초안은 상품 상세로 들어오는 경로마다 클릭 이벤트를 따로 정의. 이벤트 수가 과도해져 랜딩 도달 기준으로 분석을 단순화 →
product_detail_viewed하나로 두고 들어온 경로(버튼·배너)를 속성으로
둘 다 이유는 카디널리티 절감. 이벤트를 늘리는 대신 속성으로 내리면 지표 정의는 그대로 두고 분석 축만 늘릴 수 있음
정합성 검수 체크리스트 6항목: 이벤트명·속성명 일관성 / 명사 합성 통일(signup vs sign_up) / 분리 속성 명칭 / 옵션·강의 단위 구분 / 신규 이벤트 트리거 명확성 / 삭제된 속성이 다른 시트(KPI Tree·코호트)에서 참조되지 않는가
05 · COHORTNext Action까지 정의한 코호트 12개
코호트를 상시 모니터링할 수 있도록 각 코호트마다 어떤 메뉴에서 무엇을 확인하고, 어떤 숫자가 나오면 무엇을 할지를 함께 기재
| 유형 | 대표 코호트 | 비교 목적 | 경고 임계값 |
|---|---|---|---|
| C1 진입 경로 | C1-A 레벨테스트 유입 | 학습 동기 유입 vs 프로모션 동기 유입 유저 퀄리티 비교 | C1-A 전환율 < C1-B, 랜딩 UX · 쿠폰 혜택 접근성 점검 |
| C1-B 일반 이벤트 페이지 유입 | – | ||
| C2 혜택 사용 행동 | C2-A 무료패키지 강의 수강(진도율 50%) | 혜택을 실제로 쓴 유저의 결제 전환 상관관계 검증 | C2-A < C2-B, 콘텐츠 매력·난이도 문제 |
| C2-D 24시 수강권 혜택 미사용 이탈 | > 50%, 즉시 Activation 재검토 | ||
| C3 전환 시점 | C3-B 단기 전환 D+1~3 | 넛지 타이밍 설계 언제 리마인더를 보낼 것인가 | 리마인더 A/B 테스트 타겟 구간 |
| C3-C 중기 전환 D+4~7 | < 10%, 쿠폰 유효기간 연장 검토 |
(12개 중 6개 발췌)
C3 설계의 의도: 전환 시점을 D+0 / D+1~3 / D+4~7 / D+7 초과로 쪼갠 이유는 구간마다 해야 할 일이 다르기 때문. D+0은 이미 결심한 유저라 넛지가 불필요하고, D+1~3은 리마인더 효과가 가장 크며, D+4~7은 만료 임박 넛지 구간, D+7 초과는 리타겟팅 대상. 같은 '미전환'도 나이에 따라 처방이 다름
06 · TRADE-OFF얻은 것과 잃은 것 같이 명기
설계 문서에서 가장 신경 쓴 부분. 무엇을 포기했는지 적어두지 않으면 반년 뒤 "왜 이 숫자가 안 나오죠?"라는 질문에 답할 수 없음
| 결정 | 얻은 것 | 잃은 것 (문서에 명시) |
|---|---|---|
클릭 이벤트 11개를 page_viewed.entry_click_source로 통합 | 이벤트 관리 부담 감소, 랜딩 도달 기준으로 분석 단순화 | 노출 대비 클릭률 측정 불가 (도달률만 가능) |
신규회원 전용 User Property 미도입, signup_date 기반 동적 코호트로 운용 | 이벤트 기간이 바뀌어도 회고 분석 가능 | 이벤트마다 코호트를 수동 생성해야 함 |
current_band_score 삭제, reading_score·listening_score로 분리 | IELTS 특성상 중요한 과목별·점수대별 분석 가능 | 통합 밴드스코어 추이는 볼 수 없음 (정확도가 낮아 의도적 제외) |
07 · NOW대시보드 모니터링하며 임계값을 맞추는 중
'26.07 라이브 배포 후 L1~L3 주요 항목을 대시보드로 구성해 모니터링하고 있습니다. L0(NSM)은 월간 지표라 기존 매출 리포트로 보고, 대시보드에는 실제로 손댈 수 있는 층을 올렸습니다.
다음 사이클에 할 일: 설계 단계에서 가설로 잡아둔 임계값을 실측치로 조정. C2-D(혜택 미사용 이탈) 50%, C3-C(D+4~7 전환) 10% 같은 숫자는 경험에 기반한 출발점이지 검증된 값이 아님.
onboarding_lecture_cnt_7d의 임계값도 "모니터링 후 결정(TBD)"으로 열어둔 상태
⚠️ '26.07 배포라 이 체계로 만든 성과 수치는 아직 없습니다. 현재는 L1~L3 대시보드를 구축해 데이터를 쌓고 있는 단계이며, 이 케이스는 제안부터 설계·합의·검수·배포까지의 기록입니다. 같은 플랫폼에서 SQL·GA4로 원인을 추적해 상품을 만든 사례는 IELTS 개편 + 최적화 케이스의 Phase 2에 있습니다.