페이지뷰와 완료 이벤트로 제품의 쓸모를 구분하는 법

방문자가 늘면 기분은 좋지만 그 숫자만으로 서비스가 문제를 해결했다고 말할 수는 없습니다. 계산기 페이지를 열고 바로 나간 사람과 계산을 끝내 결과를 저장한 사람은 같은 페이지뷰 한 건으로 보일 수 있기 때문입니다.

놀이공원 입구를 지난 사람 수와 놀이기구를 끝까지 탄 사람 수를 따로 세는 것처럼, 제품 분석도 시작과 완료를 나눠야 합니다. 먼저 가장 중요한 사용자 행동 한 가지를 정하면 복잡한 분석 도구 없이도 배울 수 있습니다.

페이지뷰는 입구를 지난 횟수에 가깝다

페이지뷰는 page view, 즉 웹페이지가 표시된 사건을 세는 값입니다. 어느 글이나 기능이 관심을 받았는지 보는 출발점이지만 같은 사람이 새로고침하거나 여러 번 돌아와도 늘 수 있습니다. 검색 제목이 매력적이어서 들어왔지만 원하는 기능을 찾지 못한 경우도 포함됩니다.

따라서 페이지뷰가 늘었다는 사실은 유입이 늘었다는 뜻에 가깝고, 해결이 늘었다는 뜻은 아닙니다. 방문 경로, 기기, 기간을 같은 조건으로 맞추지 않으면 지난주와 이번 주 비교도 쉽게 어긋납니다.

이벤트는 의미 있는 행동이 일어난 순간이다

이벤트는 event, 즉 사용자가 하거나 시스템에서 발생한 행동을 이름과 정보로 기록한 자료입니다. Google Analytics는 로그인, 검색, 가입, 구매, 환불 같은 권장 이벤트와 함께 사용할 매개변수를 안내합니다. 이름을 제멋대로 늘리기 전에 도구의 권장 정의가 내 행동과 맞는지 확인합니다.

tool_started        도구 입력을 시작함
tool_completed      결과가 정상 표시됨
tool_failed         결과를 만들지 못함

위 이름은 작은 도구를 설명하기 위한 연습 예시입니다. 완료 사건은 버튼을 누른 순간보다 결과가 실제로 표시되고 필요한 검사를 통과한 순간에 두는 편이 문제 해결에 가깝습니다.

이벤트 이름보다 완료 조건을 먼저 쓴다

같은 signup_complete라도 이메일을 보낸 시점, 계정이 생긴 시점, 첫 로그인이 된 시점으로 다르게 구현할 수 있습니다. 분석 전에 “무엇이 보여야 완료인가”를 한 문장으로 씁니다. 실패와 중단도 함께 정해야 완료율의 분모와 원인을 설명할 수 있습니다.

• 시작은 사용자가 실제 입력을 시작한 순간으로 둡니다.
• 완료는 약속한 결과가 화면이나 저장소에 생긴 순간으로 둡니다.
• 실패는 사용자에게 해결 방법을 보여 준 경우와 조용히 멈춘 경우를 나눕니다.
• 한 사건의 이름과 뜻을 팀 문서에 한 줄로 남깁니다.
• 이벤트 정의가 바뀐 날짜를 기록해 전후 데이터를 섞지 않습니다.

시작과 완료를 같은 흐름에서 비교한다

완료율은 시작한 사람 가운데 완료한 비율을 보는 방법입니다. 숫자 하나보다 단계별 차이를 함께 봅니다. 입구는 많지만 입력 시작이 적다면 첫 화면 설명이 약할 수 있고, 시작은 많지만 완료가 적다면 입력 오류나 처리 시간이 문제일 수 있습니다.

이 분석은 원인을 확정하는 판결문이 아니라 조사 방향을 좁히는 지도입니다. 이벤트가 빠졌거나 두 번 보내질 수도 있으므로 실제 화면 행동과 디버그 자료를 맞춰 봅니다. Google Analytics의 DebugView도 설정 중 특정 기기의 사건이 들어오는지 확인하도록 제공됩니다.

개인정보를 이벤트 속성으로 보내지 않는다

이벤트 속성은 행동을 설명하는 부가 값입니다. 도구 종류나 성공 여부처럼 집계에 필요한 값만 둡니다. 이메일, 전화번호, 이름, 검색창에 쓴 민감한 문장, 비밀키, 결제 카드 정보는 분석 편의를 이유로 보내지 않습니다.

실제 분석 태그를 설치하면 동의, 개인정보 처리 고지, 보관 기간, 접근 권한이 달라질 수 있습니다. 의미를 모르는 추적 코드나 외부 스크립트를 바로 붙이지 마세요. 운영 데이터 삭제, 이벤트 이름 일괄 변경, 결제 사건 시험은 복구와 비용 영향을 확인한 뒤 별도 환경에서 진행합니다.

이벤트가 잘 들어온다는 확인과 분석에 쓸 수 있다는 확인도 다릅니다. 버튼 한 번에 같은 완료 사건이 두 번 기록되거나, 페이지를 다시 열 때 완료가 반복되면 완료율이 부풀어집니다. 테스트 계정으로 시작부터 완료까지 한 번씩 움직이고, DebugView나 실시간 보기에서 순서와 개수를 대조합니다. 이후 보고서에 값이 나타나는 시차와 데이터 처리 기준은 사용하는 제품의 현재 문서를 확인합니다.

비교 기간에는 이벤트 정의를 고정합니다. 중간에 완료 조건을 바꿨다면 새 정의가 시작된 날짜를 표시하고 옛 값과 단순 합산하지 않습니다. 기능 화면이 바뀌었을 때도 이전과 같은 행동을 가리키는지 다시 확인해야 숫자가 제품 변화인지 측정 변화인지 구분할 수 있습니다.

오늘 바로 해볼 작은 실습

코드를 바꾸지 않고 기능 하나의 사건 지도를 만듭니다.

1. 사용자가 해결하려는 문제를 한 문장으로 적습니다.
2. 페이지 열림, 시작, 완료, 실패 네 사건을 순서대로 씁니다.
3. 각 사건이 발생했다고 판단할 화면 증거를 적습니다.
4. 사건마다 필요한 속성을 두 개 이하로 고릅니다.
5. 개인정보나 비밀값이 들어간 속성을 모두 지웁니다.
6. 직접 한 번 사용하며 순서가 실제 화면과 맞는지 표시합니다.

첫 분석표는 사건이 많을수록 좋은 것이 아닙니다. 한 기능의 시작과 완료와 실패를 믿을 수 있게 기록하면 방문 수와 실제 쓸모를 구분할 근거가 생깁니다.