서비스 성과 측정, 기획 단계에서 미리 정해야 할 것들

안녕하세요. 사랑받는 IT 프로덕트의 첫걸음, 똑똑한개발자입니다.

오늘의 인사이트 요약

• 사용자가 끝내려는 일을 문장으로 적고 완료 조건을 정합니다.

• 시작·완료·실패 기록은 화면과 함께 설계합니다.

• 출시 후 지표를 읽을 담당자와 다음 판단을 미리 정합니다.

서비스 출시를 준비하다 보면 화면과 기능을 정하는 데 많은 시간을 씁니다.

그런데 출시 후 이용자가 잘 쓰는지 확인하려고 하면 방문자 수만 보이거나, 팀마다 성공의 의미가 달라 다음 개발을 정하기 어려울 수 있는데요. 분석 도구가 있어도 어떤 행동을 기록할지 정하지 않았다면 필요한 답을 얻기 어렵습니다.

오늘은 서비스 기획 단계에서 성과를 측정하려면 무엇을 미리 정해야 하는지 알아보겠습니다.

1. 사용자가 끝내려는 일부터 적어야합니다.

성과를 논의할 때는 사용자가 서비스에서 이루려는 일을 한 문장으로 적습니다.

예약 서비스라면 예약하기 버튼을 누르는 행동과 예약이 확정되는 결과는 다릅니다. 버튼 클릭 수가 늘어도 일정 선택이나 결제에서 막힌다면 원하는 일을 끝낸 사용자가 늘었다고 볼 수 없습니다.

예약 서비스를 예로 든 가정에서는 예약 완료를 어떤 상태로 볼지 먼저 합의합니다. 신청서 제출이 끝인지, 운영자의 승인까지 끝나야 하는지에 따라 개발할 기록과 확인할 시간이 달라집니다. 사용자의 신청 완료와 회사의 승인 완료가 모두 필요하다면 서로 다른 지표로 두는 편이 이해하기 쉽습니다.

똑똑한개발자팀은 초기 성과 지표를 정할 때 담당자들이 같은 기록을 같은 뜻으로 읽는지부터 확인해야 한다고 생각합니다.

마케팅팀은 신청 버튼 클릭을 세고 운영팀은 승인된 예약을 세고 있다면 같은 이름의 성과 수치를 놓고도 다른 이야기를 하게 됩니다.

2. 화면 설계와 함께 기록할 항목을 정해야 합니다.

기획서에는 화면에서 무엇이 일어날 때 기록을 남길지 적습니다.

이벤트는 버튼 클릭이나 예약 확정처럼 서비스에서 일어난 행동·상태의 기록입니다. 분석 도구를 설치한다는 한 줄만으로는 어떤 이벤트가 필요한지 개발자가 알기 어렵습니다. 업무 흐름마다 시작, 중간 진행, 완료, 실패를 구분하고 발생 조건을 설명합니다.

예약을 가정하면 날짜 선택 화면을 열었을 때와 실제 날짜를 선택했을 때를 구분합니다. 완료 버튼을 눌렀어도 서버 저장이 실패했다면 예약 완료로 세지 않도록 정합니다. 같은 요청이 다시 전송될 때 중복 기록을 어떻게 처리할지도 적어두면, 화면에서는 한 건인데 통계에서는 여러 건으로 보이는 혼란을 줄일 수 있습니다.

측정 정의에는 이벤트 이름과 발생 조건, 기록 위치, 중복을 구분할 값, 확인 담당자를 담습니다.

서버의 확정 상태와 화면 행동 중 어느 쪽을 근거로 삼는지도 표시합니다. 이름을 멋지게 짓기보다 팀원이 같은 조건으로 구현하고 확인할 수 있게 씁니다.

기록을 설계할 때는 업무에 필요한 항목만 고릅니다. 입력한 문장이나 연락처를 분석 기록에 그대로 복사하기보다, 완료 여부와 오류 유형만으로도 질문에 답할 수 있는지 검토합니다. 실제로 수집할 정보와 보관·접근 범위는 서비스의 정책과 맞춰 별도로 확인합니다.

외부에 개발을 맡길 때도 측정 정의를 작업 범위에 넣습니다.

이벤트 구현, 동작 확인, 분석 화면 구성 중 어디까지 맡길지 정해야 견적과 검수에서 같은 항목을 볼 수 있습니다. 화면을 완성하고도 성과 기록이 빠지지 않도록 출시 준비 때 기록이 남는지도 확인합니다.

3. 지표가 달라지면 무엇을 살필지 정합니다

출시 전에 현재 상태를 기록해두면 변화의 크기를 해석하기 쉽습니다. 기존 서비스가 있다면 같은 조건의 완료율이나 처리 시간을 남기고 새 서비스라 비교 자료가 없다면 초기에 수집한 값을 언제부터 비교 기준으로 삼을지 정합니다. 출처가 없는 목표 수치를 업계 평균처럼 쓰기보다 가정과 확인할 시점을 구분해두는 편이 낫습니다.

똑똑한개발자팀은 지표를 정할 때 값이 달라지면 누가 어떤 화면이나 업무를 살필지도 함께 적기를 권하는데요.

예약 완료율이 낮아졌다면 날짜 선택, 입력, 결제 중 어디에서 멈췄는지 보고 해당 과정을 점검합니다. 수치 하나만으로 원인을 단정하지 않고 사용자의 문의와 실제 이용 흐름도 같이 확인합니다.

비교 조건도 동일하게 맞춥니다.

신규 방문자가 많아진 기간과 기존 고객 중심의 기간은 이용 행태가 다를 수 있습니다. 캠페인 유입이나 기기 차이처럼 결과에 영향을 줄 만한 조건을 살피면, 변화가 모두 새 기능 때문이라고 해석하는 실수를 줄일 수 있습니다.

개선 여부를 판단할 때는 한 지표만 밀어 올리지 않습니다. 예약 완료율이 올라도 취소나 운영자의 재확인이 늘었다면 이용 과정이 충분히 좋아졌는지 다시 봅니다. 핵심 결과와 후속 문제를 함께 보면서 어떤 변화면 유지하고 언제 다시 점검할지 담당자끼리 합의합니다.

이 과정을 주기적으로 이어가려면 지표를 읽을 사람이 필요합니다. 회의 때 숫자를 공유하는 데서 끝내지 말고 확인한 문제와 다음에 고칠 항목을 기록합니다. 이후 같은 조건으로 다시 살펴보면 추가 개발의 우선순위를 설명할 자료가 됩니다.

기획과 개발을 출시 이후의 판단으로 잇습니다

성과 측정은 분석 화면을 만드는 일까지 이어집니다. 사용자에게 필요한 기능, 그 기능이 쓰였다는 기록, 기록을 읽고 개선할 담당자가 연결돼야 출시 후에도 다음 일을 고를 수 있습니다. 서비스를 기획할 때 함께 논의하면 화면 수만 세어서는 알기 어려운 개발 작업도 확인할 수 있습니다.

똑똑한개발자는 웹·앱부터 관리자 시스템과 SaaS까지 프로덕트를 기획·디자인·개발·운영해온 경험이 있습니다. 개발 전후의 업무를 함께 살피며 서비스를 만드는 접근은, 기능의 동작과 운영 과정에서 확인할 내용을 연결하는 데도 필요합니다. 아래 소개서에는 서비스 기획과 개발을 운영 지원으로 연결하는 범위가 담겨 있습니다.

서비스 기획부터 개발·운영까지 함께 살피며 출시 이후 개선을 준비하고 싶다면, 아래 똑똑한개발자 링크로 이야기 나눠주세요. 감사합니다. :)