본문 바로가기
서비스 웹 서비스 개발 앱 개발 AI 알고리즘 개발 AI 컨설팅 AI 마케팅 프로젝트 인사이트 회사소개 고객게시판
데이터 분석 8 MIN READ

클릭 수가 늘었는데 업무는 끝났을까: 성과 중심 이벤트 설계법

B2B 제품 분석에서 버튼 클릭 대신 업무 시작·실패·완료를 정의하고, 안정적인 이벤트 이름과 개인정보 최소 수집 원칙으로 실행 가능한 지표를 만드는 방법.

Category
데이터 분석
Published
Read
8분
Author
네이처프랙탈
클릭 수가 늘었는데 업무는 끝났을까: 성과 중심 이벤트 설계법 대표 이미지

제품 사용량 보고서에서 버튼 클릭이 지난달보다 30% 늘었다고 합시다. 관리자가 해야 할 질문은 ‘사람들이 더 많이 눌렀네?’가 아니라 ‘고객 업무가 더 빨리 끝났나?’입니다. 오류 때문에 같은 버튼을 다섯 번 눌렀다면 클릭 수 증가는 오히려 품질 악화의 신호일 수 있습니다.

B2B 서비스에서는 방문·체류보다 고객이 끝내려던 업무가 무엇이었고 실제로 완료됐는지를 먼저 정의해야 합니다. 견적 승인, 설비 점검 완료, 데이터 업로드 검증, 보고서 공유처럼 의미 있는 단위를 분석의 중심에 둡니다.

화면이 아니라 업무를 기준으로 이벤트를 세운다

한 업무에 최소한 세 가지 사건을 둡니다. 시작은 사용자가 명확한 의도로 흐름에 들어온 순간, 실패는 검증·권한·시스템 문제로 목표를 못 이룬 순간, 완료는 서버가 결과를 확정한 순간입니다. 가능하다면 중간 초안 저장과 재개도 별도로 기록합니다. 완료 이벤트를 화면의 축하 애니메이션 표시 시점에만 보내면 실제 서버 처리 실패를 놓칠 수 있습니다.

예를 들어 주문 생성 흐름은 ‘화면 열기’보다 ‘주문 초안 생성→품목 검증 실패 또는 통과→서버 주문 확정’이 유용합니다. 시작 대비 완료 비율, 단계별 소요 시간, 실패 사유별 비중을 비교하면 클릭 수에서 보이지 않던 개선 지점을 찾습니다. 업무별 목표 시간은 먼저 현장 관찰과 기준선을 통해 정해야 하며, 일률적인 정답은 없습니다.

수많은 클릭보다 업무 시작, 실패, 완료 이정표를 측정하는 분석 흐름
클릭의 양보다 업무가 끝났는지와 어디서 막혔는지가 개선 우선순위를 알려준다.

이벤트 이름은 오래 유지할 계약이다

이벤트 이름을 order.submitted처럼 의미 중심의 안정적인 값으로 만들고 주문 ID, 고객명, 페이지 URL 전체를 이름에 끼워 넣지 않습니다. 달라지는 값은 허용된 속성으로 분리합니다. 이름이 매번 달라지면 집계와 대시보드가 분열됩니다. OpenTelemetry의 이벤트 규약도 이벤트 이름을 안정적이고 낮은 카디널리티로 유지할 것을 권합니다.

명세에는 이름만 적지 말고 발생 조건, 책임 시스템, 타임스탬프 기준, 업무 식별자, 허용 속성, 중복 처리 규칙, 소유 팀을 적습니다. 클라이언트에서 보내는 ‘클릭’과 서버에서 확정하는 ‘완료’를 구분하면 네트워크 재시도나 탭 종료에도 지표 의미가 흔들리지 않습니다. 이벤트 버전을 바꿀 때는 새·구 대시보드를 함께 검증하는 기간을 둡니다.

개인정보를 분석 이벤트에 싣지 않는다

분석을 잘하려고 고객명, 이메일, 자유입력 메모를 속성에 넣는 순간 검색·내보내기·장기 보관 경로가 늘어납니다. 업무 구분에 필요한 익명·가명 식별자, 기능 버전, 실패 유형 정도부터 시작하고, 민감정보는 수집 금지 목록으로 명시합니다. 자유입력 값을 그대로 전송하는 범용 error_message도 주의해야 합니다. OWASP의 로그 가이드가 강조하는 민감정보 배제 원칙은 제품 이벤트 수집에도 유용한 설계 기준입니다.

고객사별 분석이 필요하다면 테넌트 식별자의 접근 권한과 보존 기간을 별도로 정합니다. 작은 조직에서는 특정 조합만으로 개인이 추정될 수 있으므로 집계 최소 단위도 고려해야 합니다. ‘수집할 수 있다’와 ‘수집해야 한다’는 다릅니다.

안정적인 이벤트 이름과 안전한 속성을 기록하고 민감정보를 제외하는 구조
이벤트 명세에는 이름·시점·허용 속성·수집 금지 항목을 함께 적는다.

실제로 쓸 대시보드는 네 가지 질문에 답한다

  1. 업무를 시작한 고객 중 완료한 비율은 얼마인가?
  2. 완료까지 가장 오래 걸리는 단계는 어디인가?
  3. 실패는 사용자의 입력, 권한, 서비스 장애 중 무엇 때문인가?
  4. 변경 배포 전후에 완료율과 소요 시간이 함께 좋아졌는가?

세그먼트는 역할·조직 규모·기능 버전처럼 의사결정에 필요한 축만 사용합니다. 평균이 좋아도 한 고객군의 실패가 급증할 수 있으므로 분포와 오류 사유를 함께 봅니다. 신규 기능이라면 측정 시작 전에 ‘완료’ 정의를 제품·개발·운영 팀이 합의해야 숫자에 대한 불필요한 논쟁을 줄일 수 있습니다.

도입 순서: 이벤트를 늘리기보다 정리한다

먼저 고객의 핵심 업무 3개를 선정하고 각 업무의 시작·실패·완료 이벤트만 설계합니다. 테스트 환경에서 서버 결과와 이벤트 발생을 대조하고, 중복·누락·시각 오차를 확인합니다. 이후 이벤트 명세를 코드 리뷰와 배포 절차에 연결합니다. 한 분기 뒤에는 실제로 사용하지 않는 이벤트를 정리합니다.

좋은 이벤트 체계는 많은 데이터를 쌓는 장치가 아니라 고객의 막힌 업무를 정확히 발견하는 도구입니다. 클릭 수가 늘었는지보다, 고객이 덜 헤매고 일을 끝냈는지를 보아야 합니다.

#제품분석 #이벤트설계 #이벤트택소노미 #업무완료율 #퍼널분석 #B2BSaaS #데이터분석 #데이터거버넌스 #개인정보보호 #UX지표

데이터 데이터 거버넌스 데이터 아키텍처

/ 다음 단계

이런 문제, 직접 겪고 계신가요?

글로 정리한 방법을 실제 환경에 맞춰 적용하는 일까지 함께 하겠습니다.

영업일 기준 3일 이내 회신 · 상담 및 범위 견적 무료