Follow the Metrics for PM · 웹 교재 v1.0 · 2026-09-21
1. 기기·계정·행동 기준의 집계
앱 진입 기기는 d1~d5의 5대, 진입 계정은 u01~u04의 4개, 저장 계정은 u01·u02의 2개다. u01이 두 기기를 사용하므로 기기 수와 계정 수가 다르다.
기기 수는 이용 환경이나 기기별 문제를 검토하는 데, 진입 계정 수는 서비스 이용 범위를 확인하는 데, 저장 계정 수는 핵심 기능의 도달 범위를 확인하는 데 쓸 수 있다. 목적이 다른 지표를 같은 ‘활성’이라는 이름으로 보고하지 않는 것이 중요하다. 계정이 실제 사람과 일치하는지도 별도의 식별 문제다.
2. 날짜별 고유 수의 합산
첫날 집합은 {u01, u02, u03, u04}, 둘째 날 집합은 {u01, u02, u05}다. 중복인 u01·u02를 제외한 합집합은 5개다. 산술로는 4 + 3 − 2 = 5다.
7은 계정이 활동한 날의 총수, 즉 7계정·일로 해석할 수 있다. 두 날짜 모두 이용한 한 계정은 이 단위에서 두 번 기여한다. 7을 고유 계정 수라고 보고하면 반복 이용과 이용 범위를 혼동하게 된다.
3. 분모와 질문
2/4 = 50%는 앱을 연 계정 중 저장한 계정의 비율이다. 2/3 ≈ 66.7%는 작성을 시작한 계정 중 저장한 계정의 비율이다. 전자는 진입 이후 전체 경로, 후자는 작성 과정에 더 가까운 질문이다.
분모가 0이면 비율은 계산 불가로 표시한다. 0%는 분모가 양수일 때 아무도 완료하지 않았다는 의미로 남겨야 한다. 보고서에 대상 수를 함께 표시하면 두 상황을 구분하기 쉽다.
4. 합산·단순평균·고유 계정
과업 합산은 (2+2)/(3+2) = 80%다. 일별 비율의 단순평균은 (2/3+1)/2 ≈ 83.3%다. 기간 고유 계정 기준은 저장자 {u01,u02,u05} / 시작자 {u01,u02,u03,u05} = 3/4 = 75%다.
80%는 각 과업에 같은 무게를 주고, 83.3%는 각 날짜에 같은 무게를 준다. 75%는 기간의 각 고유 계정에 같은 무게를 준다. 따라서 올바른 답은 한 값을 선택하는 것에 그치지 않고 질문과 가중 단위를 일치시키는 것이다.
5. 발생일과 자료 마감
세계시 9월 1일 15:05는 한국 시간 9월 2일 00:05다. 발생일 기준 집계에는 9월 2일에 들어간다. 한국 시간 9월 2일 00:00 마감 시점에는 사건 자체가 아직 발생하지 않았고 수신도 되지 않았다.
9월 3일 09:00 이후 해당 기록을 포함하는 마감에서는 9월 2일 이용에 배정한다. 이 사건은 9월 1일의 지연 도착 자료가 아니다. 발생 기간과 자료 수신 마감을 따로 확인하는 것이 핵심이다. 마감 경계의 포함 여부는 정의서와 맞춰야 한다.
6. 활성 정의 변경의 보고
보고 예: ‘이번 보고부터 활성 기준을 앱 진입에서 서버 회고 저장으로 변경했다. 새 기준은 핵심 작성 기능의 이용 범위를 나타낸다. 종전 수치와의 차이에는 인정 행동의 변화가 포함되어 있어 이용 감소로 직접 해석하지 않는다.’
기록에는 적용일, 기존·신규 정의, 대상 버전, 병행 관찰 가능 기간, 과거 재집계 범위, 담당자를 포함한다. 과거 서버 저장 기록이 없으면 새 기준으로 환산한 추세를 만들 수 없다는 점을 남긴다. 같은 이름으로 시계열을 덮어쓰는 방식은 피한다.
7. 지표 정의서 평가 기준
서비스마다 다른 답이 가능하다. 다음 항목으로 작성물을 검토한다.
| 평가 항목 | 확인할 내용 |
|---|---|
| 목적 | 어떤 결정에 쓰는지 구체적인가 |
| 단위·대상 | 사람·계정·과업·사건을 구분했는가 |
| 시간 | 시간대, 시작·끝 경계, 마감이 있는가 |
| 계산 | 분자·분모의 자격, 중복·제외가 명시되었는가 |
| 해석 | 기록으로 확인하지 못하는 사용자 결과가 적혀 있는가 |
| 운영 | 자료 품질, 담당, 변경 이력을 관리할 수 있는가 |
‘주간 주문 완료 사용자’라면 주문 생성과 결제 성공, 배송 완료 중 무엇을 완료로 인정하는지까지 적어야 한다. 주문이 완료되었다는 사실과 고객이 필요한 물건을 제때 받아 목적을 달성했다는 사실은 서로 다른 평가 범위다.
초안에 ‘주간 완료율 = 완료 사용자 / 전체 사용자’만 적혀 있다면 그대로 구현을 요청하기 어렵다. ‘전체’가 누적 가입자인지 이번 주 기능 이용 가능 계정인지, ‘완료’가 어느 처리 단계인지부터 보완한다. 경계 사례로 기능을 볼 수 없는 계정, 여러 번 요청한 계정, 결과가 늦게 도착한 계정을 넣고 각각 어떻게 집계할지 확인한다. 이 사례를 문서만으로 판정할 수 있어야 정의서가 업무에 사용될 수 있다.
8. 횟수·비중·변화량
4/3 ≈ 1.33은 이틀 동안의 저장 계정당 저장 횟수다. 분자는 사건이고 분모는 계정이므로 부분집합의 비중이 아니다. ‘저장 비율 133%’라고 표현하면 단위가 잘못 전달된다. ‘이틀간 저장 경험 계정당 평균 1.33회’처럼 집계 기간과 분모를 함께 적는다.
완료율 50%→60%의 차이는 10%p이며, 이전 값에 대한 상대 변화율은 20%다. 상대 변화의 기준은 이전 50%다. 시작값이 0이면 같은 방식의 상대 변화율을 계산할 수 없으므로 절대 차이와 원자료를 제시해야 한다.
이 문제에서는 계산 결과뿐 아니라 각 숫자의 단위를 올바르게 서술했는지 평가한다. 같은 나눗셈이라도 계정당 반복 횟수, 대상 중 완료의 비중, 이전 수준 대비 변화는 다른 질문이다.
9. 보고서 불일치 검토 메모
작성 예: ‘세 보고서의 날짜와 자료 마감은 같지만 활성의 정의가 다르다. 5는 앱 진입 기기, 4는 진입 계정, 2는 저장 계정이다. u01의 두 기기가 첫 차이를 만들고, 저장하지 않은 u03·u04가 두 번째 차이를 만든다. 현재 자료에서는 원자료 오류를 확인하지 못했으므로 값의 수정 대신 표시 이름과 단위를 구분하고 정의서에 연결한다.’
추가 조사는 별도 업무로 적는다. ‘저장하지 않은 계정이 왜 저장하지 않았는지는 현재 집계만으로 알 수 없다. 작성 시작 여부에 따라 경로를 나누고, 작성 의도와 중단 조건을 경험 분석에서 확인한다.’ 이렇게 쓰면 정의 정리와 제품 문제 조사가 섞이지 않는다.
| 검토 요소 | 충분한 답 | 보완이 필요한 답 |
|---|---|---|
| 차이 설명 | 식별자와 인정 행동으로 재현 | 어느 도구가 맞을 것이라는 추측 |
| 수정 범위 | 원자료·이름·정의 중 수정 대상을 구별 | 세 숫자를 근거 없이 하나로 맞춤 |
| 해석 | 기록이 설명하는 범위를 명시 | 활성 감소나 만족 하락을 단정 |
| 후속 업무 | 미확인 원인과 확인 방법 연결 | ‘추가 분석 필요’만 남김 |