Follow the Metrics for PM · 웹 교재 v1.0 · 2026-09-21
1. 요청·확정·안내
버튼 클릭은 사용자가 저장을 요청하려는 동작을 수행했는지, 서버 저장 확정은 유효한 내용이 보존되었는지, 완료 안내 노출은 결과 화면이 표시되었는지에 답한다. 노출만으로 사용자가 내용을 읽고 이해했다고 확정할 수는 없다.
클릭에서 확정까지의 과정은 실패·대기를 검토하는 데, 확정과 안내의 관계는 상태 전달을 검토하는 데 쓸 수 있다. 세 기록에는 같은 시도를 연결할 식별자가 필요하다.
2. 중복 제거 기준
동일 논리 사건의 재전송이면 event_id는 유지한다. 각 전달을 구분하는 delivery_id는 바뀔 수 있다. 같은 시도의 재전송이므로 해당 attempt_id와 저장 문서도 유지된다.
user_id만으로 중복을 제거하면 그 사용자가 정상적으로 여러 번 수행한 사건도 하나로 줄어든다. 반대로 매번 새 사건 식별자를 만들면 재전송을 구분할 수 없다. 같은 회고의 수정 저장까지 다룬다면 문서 식별자만으로 중복 제거하는 것도 부적절하다.
3. 총합이 같은 경우의 검수
초기 세 행은 a01의 동일 사건 두 행과 a02의 구버전 클릭 한 행이다. 실제 저장된 대상은 a01·a03·a04다. 전자는 두 시도만 나타내고 그중 하나는 저장 실패다. 후자의 두 저장은 초기 기록에 없다.
총합 차이 0은 정확성을 보장하지 않는다. 잘못 포함된 기록과 빠진 기록이 상쇄될 수 있으므로 시도·회고 단위로 대조하고 중복·오인정·누락을 별도로 분류한다.
4. 포착률과 성공률
초기 마감에는 구버전을 제외하고 중복을 제거한 저장이 a01 한 건이므로 포착률은 1/3 ≈ 33.3%다. 다음 날 마감에는 a03이 추가되어 2/3 ≈ 66.7%다. r04는 여전히 누락된다.
실제 저장 성공률은 3/5 = 60%다. 포착률의 분모는 실제 저장 세 건이고, 성공률의 분모는 전체 시도 다섯 건이다. 관찰된 두 저장을 다섯 시도로 나눈 40%를 실제 성공률로 쓰면 분석 누락을 사용자 실패와 혼합한다.
5. 원장 기반 복구
대상 문서 r04, 원장상의 저장 시각, 원천 자료, 복구 처리 시각, 사용한 규칙·버전, 복구 여부 표지를 남긴다. 원래 이벤트와 중복되지 않도록 연결 기준도 정해야 한다.
원장에 서버 저장만 있다면 저장 사실은 복구할 수 있지만 화면 노출은 복구할 수 없다. 사용자가 앱을 닫았거나 안내가 표시되지 않았을 수 있기 때문이다. 복구 가능한 사실과 추가 추정을 명확히 구분한다.
6. 스키마와 지표 정의
진단용 앱 버전 속성을 추가하는 변경은 이벤트 구조의 변경이다. 발생 조건이 그대로라면 저장의 의미는 유지될 수 있지만 필수 값 수집과 구버전 자료의 결측 처리 등을 검수해야 한다.
대상을 전체 계정에서 유료 계정으로 바꾸는 것은 지표 정의의 변경이다. 이벤트가 그대로여도 모집단이 달라져 기존 수치와 직접 비교할 수 없다. 실제 변경에서는 두 종류가 동시에 발생할 수 있으므로 각각의 버전·적용일·비교 영향을 기록한다.
7. 이벤트 명세 평가 기준
작성된 이벤트가 답할 질문이 분명하고, 발생 조건을 구현·검수 담당자가 재현할 수 있는지 확인한다. ‘사용자가 성공했을 때’처럼 관찰 방법이 없는 표현은 충분하지 않다.
| 확인 항목 | 충분한 작성의 조건 |
|---|---|
| 발생·제외 | 클릭, 처리 성공, 실패, 임시 상태를 구분 |
| 식별자 | 사용자·과업·업무 객체·사건의 관계가 명확 |
| 시각 | 원천 시각과 수신 시각, 날짜 배정 기준 명시 |
| 속성 | 질문에 필요한 최소 정보, 원문 수집 필요성 검토 |
| 검수 | 정상·중복·실패·지연·누락·버전 혼재 포함 |
| 운영 | 비교 기준 자료, 품질 점검 담당과 변경 기록 연결 |
예를 들어 메시지 전송 성공을 세는 데는 메시지 본문 전체가 필요하지 않을 수 있다. 전송 식별자·성공 상태·발생 시각만으로 답할 수 있는 질문인지 먼저 확인한다. 내용 품질을 연구하는 별도 질문과 기본 계측을 분리한다.
명세의 예외 처리도 확인한다. 계정 식별자가 없을 때 어떻게 분류할지, 구버전 사건을 어떤 근거로 해석할지, 발생 시각이 없으면 날짜를 어떻게 배정할지 적는다. 단순히 필드를 ‘필수’로 표시하는 것과 실제로 빠진 자료를 처리하는 것은 별도의 설계다. 정상 예시와 함께 인정하지 않는 예시를 붙이면 해석 차이를 확인하기 쉽다.
8. 저장 재시도와 기록 재전송
화면에 응답이 없더라도 서버에 이미 저장되었으므로 결과는 사용자 관점에서 미확인 상태다. 구현 검수에서는 다시 요청했을 때 같은 회고 결과를 확인하는지, 중복 문서가 새로 생성되는지, 완료 상태가 일관되게 표시되는지 확인한다. 같은 과업의 요청을 구분하고 연결할 기준이 필요하다.
분석 검수에서는 이미 발생한 저장 확정 사건을 다시 전달해도 하나의 논리 사건으로 집계되는지 확인한다. 재전송의 event_id는 유지하고 전달 기록을 구분한다. 실제 새로운 저장이나 수정이 발생했다면 그 사건까지 일괄 제거하지 않도록 정의를 대조한다.
| 층위 | 막으려는 문제 | 확인 근거 |
|---|---|---|
| 실제 서비스 처리 | 같은 작업으로 원치 않는 중복 문서 생성 | 요청·회고·처리 결과 |
| 분석 자료 처리 | 같은 확정 사건을 여러 번 완료로 집계 | 사건·전달 식별자와 정제 결과 |
| 사용자 안내 | 보존된 상태를 실패로 오해하거나 다시 입력 | 화면 상태와 과업 관찰 |
분석 대시보드에서 중복을 제거했다고 실제 사용자 문서의 중복까지 해결된 것은 아니다. 세 층위를 구분해 검수하는 답이 필요하다.
9. 배포 후 지표 감소의 조사
먼저 같은 발생 기간과 자료 마감에서 원장 결과와 분석 기록을 대조한다. 원장 저장은 유지되고 분석 포착만 감소했다면 수집·속성·정제 규칙을 우선 확인한다. 두 자료가 함께 감소했다면 실제 처리 문제와 이용 변화도 검토한다. 원장의 범위가 현재 남은 문서인지 과거 저장 이력인지도 확인해야 한다.
버전·기기·경로별로 차이를 나누어 배포 영향 범위를 좁힌다. 보고 상태에는 영향 기간과 지표, 확인된 사실, 잠정 또는 비교 보류 범위를 표시한다. 자료가 없다고 사용자 성과를 0으로 채우지 않는다.
복구 종료 기준은 수정 코드 배포만으로 정하지 않는다. 정상·실패·중복·지연 사례가 의도대로 기록되고, 원장과의 차이가 설명 가능하며, 영향 기간의 재집계 또는 복구 불가 범위가 정리되어야 한다. 마지막으로 정의서·이벤트 명세·대시보드가 같은 버전을 가리키는지 확인하고 담당자에게 인계한다.