출시 직전에 고민하면 늦는 데이터 계측: 선택률, 이탈 지점, 엔딩을 기록하는 방법

인터랙티브 영상 게임의 데이터 계측은 노드 데이터가 확정될 때 설계해야 한다. 실제로 유용한 데이터는 플레이어가 무엇을 봤고, 무엇을 선택할 수 있었으며, 최종적으로 무엇을 선택했는지, 그리고 기술적으로 재생이 성공했는지를 담아야 하기 때문이다. 버튼 클릭만 기록하면 미노출, 잘못 누름, 이탈, 로딩 실패가 뒤섞여 스토리에 대한 잘못된 판단을 내리게 된다.

먼저 제품에 관한 질문을 나열한다. 플레이어는 어느 챕터에서 떠나는가? 아무도 선택하지 않는 선택지는 매력이 없어서인가, 아니면 아예 나타나지 않았기 때문인가? 특정 엔딩에 도달하는 사람이 적은 이유는 조건이 너무 어렵기 때문인가, 아니면 플레이어가 그 경로를 원하지 않기 때문인가? 다시 플레이하는 사람은 무엇을 찾고 있는가? 각 질문에 지표와 최소한의 이벤트를 대응시키고, 모든 화면 조작을 업로드하지 않는다.

데이터만으로는 ‘왜’라는 질문에 완전히 답할 수 없다. 정량 분석으로 이상을 발견한 뒤에는 사용성 관찰, 댓글, 인터뷰를 함께 활용해 해석한다. 낮은 선택률은 문구, 캐릭터의 가치관, 이전 상태 때문에 발생할 수 있으므로 자동으로 나쁜 분기라고 판단해서는 안 된다.

최소한 세션 시작과 종료, 노드 진입, 미디어 준비 성공 또는 실패, 선택지 노출, 선택 제출, 상태 마일스톤, 엔딩 도달, 다시 플레이 시작을 기록한다. 공통 필드에는 익명 세션 ID, 게임 버전, 플랫폼, 언어, 노드 또는 선택지 ID, 시간, 필요한 실험 버전이 포함된다.

선택지 노출 이벤트에는 해당 시점에 보이는 선택지 집합과 시간 제한 규칙도 기록한다. 제출 이벤트에는 선택 ID, 노출부터 제출까지 걸린 시간, 시간 초과 여부를 기록한다. 이렇게 해야 선택률의 분모가 모든 플레이어가 아니라 ‘실제로 해당 선택지를 본 사람’이 된다.

프로그램은 종료 알림을 매번 확실하게 받을 수 없다. 특히 크래시, 정전, 모바일 운영체제에 의한 앱 종료 상황에서는 더욱 그렇다. 노드 진입과 주요 재생 단계에서 가벼운 하트비트를 기록하고, 다음 실행 때 이전 세션이 정상적으로 종료되지 않았는지 판단할 수 있다. 자발적 이탈, 백그라운드 시간 초과, 크래시, 정상 종료를 구분한다.

이탈 지점에는 노드뿐 아니라 재생 진행률, 선택을 기다리는 중이었는지, 가장 최근의 로딩 소요 시간, 반복 시청 여부도 기록한다. 플레이어가 같은 영상의 90% 지점에서 떠난다면 콘텐츠 문제일 수 있다. 0% 지점에서 떠나고 로딩도 실패했다면 기술적 문제일 가능성이 더 크다.

엔딩 이벤트에는 주요 엔딩 ID, 에필로그 변형, 핵심 상태 요약, 총 소요 시간, 재시도 횟수, 건너뛰기 사용 여부를 기록한다. 프레임별 전체 행동이나 자유 입력 텍스트를 업로드하지 말고, 설계 질문에 답하는 데 필요한 필드만 남긴다.

모든 전체 선택 순서를 저장하는 대신 핵심 선택에 대한 경로 퍼널을 만든다. 전체 경로 조합은 빠르게 희소해지고 개인정보 보호와 분석 부담도 늘린다. 보통 챕터 진입점, 핵심 노드, 엔딩만으로도 문제를 찾기에 충분하다.

이벤트 사전에는 이름, 발생 시점, 필드 유형, 예시, 담당자, 용도, 보존 기간, 버전을 포함한다. 이벤트 이름은 안정적으로 유지하고, 필드 추가는 하위 호환성을 보장한다. 의미가 바뀌면 새 버전을 만들고, 기존 필드를 아무 설명 없이 재사용해서는 안 된다.

각 이벤트는 하나의 시스템에서만 발생시킨다. 버튼, 노드 관리자, 플레이어가 모두 ‘선택 완료’를 전송하면 데이터가 중복된다. 제출 성공 후 고유 이벤트 ID를 생성하면 오프라인 재전송에서도 중복을 제거할 수 있다.

필요한 정보만 수집하고 이름, 원시 기기 식별자, 플레이어 입력 내용은 피한다. 수집 목적, 보존 기간, 수집 거부 방법을 설명한다. 적용 지역의 구체적인 법적 요구 사항은 자격을 갖춘 담당자가 검토해야 한다. 분석에 동의하지 않아도 게임의 핵심 흐름은 실행할 수 있어야 한다.

개발 로그와 분석 데이터를 분리한다. 전자는 문제 해결을 돕기 위해 로컬에 상세 상태를 담을 수 있지만, 후자는 집계에 필요한 필드만 업로드한다. 테스트 계정과 실제 플레이어도 표시해 분리하여 출시 후 데이터가 오염되지 않도록 한다.

각 이벤트에 테스트 케이스를 작성한다. 언제 발생해야 하는지, 언제 발생해서는 안 되는지, 필드가 유효한지 확인한다. 이미 알고 있는 경로 하나를 실행하고 예상 이벤트를 직접 계산한 뒤 백엔드와 하나씩 대조한다. 오프라인, 재연결, 중복 제출, 버전 간 동작, 시스템 시간 이상을 테스트한다.

마지막으로 최소한의 대시보드를 만든다. 챕터 도달률, 노드 이탈률, 선택지 노출과 선택률, 엔딩별 인원, 첫 플레이 완료 시간, 다시 플레이 시작률, 미디어 실패율을 포함한다. 어떤 차트가 의사결정에 도움이 되지 않는다면 ‘풍부한 데이터’를 위해 장기간 유지하지 않는다.

각 지표 옆에 ‘이 지표로 알 수 없는 것’을 한 문장씩 덧붙인다. 완료율 하락만으로 스토리가 나빠졌다고 입증할 수는 없으며, 높은 재플레이율도 저장 오류나 도전 과제 요구 사항 때문일 수 있다. 변경 사항을 배포하기 전에 버전별 그룹을 유지하여 신규 플레이어 구성의 변화를 콘텐츠 효과로 오인하지 않도록 한다. 표본이 매우 작을 때는 인원과 구간을 표시하고, 소수점으로 확실한 것처럼 보이게 하지 않는다.

데이터 검토는 행동으로 이어져야 한다. 관찰 지속, 심층 조사, 기술 문제 수정, 콘텐츠 조정 중 할 일을 정하고 담당자와 재검토 날짜를 지정한다. 행동으로 이어지지 않는 질문을 위해 계속 더 많은 필드를 수집할 필요는 없다.

다음 단계: 가장 중요한 설계 질문 세 가지를 고르고, 각 질문의 지표 공식, 필요한 이벤트, 의사결정 임계값을 작성한다. 이어서 테스트 담당자가 고정된 경로 하나로 원시 이벤트를 대조하여 분모가 잘못되지 않았는지 확인하게 한다.