운영 포털에서 Pendo를 테스트한 이유

운영 포털을 개선할 때 사용자에게 불편한 점을 직접 듣기는 했지만, 어떤 기능을 얼마나 사용하고 어느 단계에서 멈추는지는 파악하기 어려웠습니다. 오류 로그와 성능 지표만으로는 사용 흐름을 알기 어려워 React 포털에 Pendo를 붙여 테스트했습니다.

전면 도입하거나 기존 분석 도구를 교체한 작업은 아닙니다. 사용자 식별과 이벤트 수집을 연결하고, Guide와 NPS, Session Replay가 필요한 정보를 보여줄 수 있을지 살펴본 과정입니다.

로그인 이후의 초기화

포털에서는 로그인 뒤 사용자와 소속 정보가 정해졌습니다. 이 값이 준비되기 전에 초기화하면 의도한 사용자와 연결되지 않은 기록이 생길 수 있었습니다.

아래는 설치 스크립트와 SDK가 준비된 뒤, 인증 처리에서 호출할 수 있는 구조 예시입니다. 실제 사용자 정보나 이메일은 포함하지 않았습니다.

export function initializeAnalytics(pendo, { visitorId, accountId }) {
  if (!visitorId || !accountId) return false;
 
  pendo.initialize({
    visitor: { id: visitorId },
    account: { id: accountId },
  });
  return true;
}

이 함수만으로 로그인·로그아웃 처리가 모두 해결되지는 않습니다. React의 재렌더마다 초기화하지 않도록 호출 위치를 정하고, 사용자가 바뀌거나 로그아웃할 때 이전 식별 정보가 남지 않는지도 확인해야 합니다. SDK가 늦게 준비되는 경우도 초기화 완료 상태와 구분해야 합니다.

Visitor ID는 같은 사용자를 일관되게 식별할 수 있는 값이어야 합니다. Account는 분석하려는 조직이나 그룹을 나타내므로, 내부 팀과 파트너를 어떤 기준으로 묶을지부터 정해야 했습니다. 이름이나 이메일 같은 정보를 모두 보내야 하는 것은 아닙니다.

클릭과 작업 완료의 구분

페이지와 버튼 클릭 외에 실제 업무 결과를 나타내는 이벤트가 필요했습니다. 예를 들어 내보내기 버튼을 누른 것과 파일 생성이 끝난 것은 다릅니다.

이 이름은 실제 운영 이벤트 목록을 공개한 것이 아니라 구분 방법을 설명하기 위한 예시입니다. 요청과 완료를 연결할 수 있어야 중간에 오래 기다린 것인지, 실패한 것인지 확인할 수 있습니다.

이벤트 호출은 컴포넌트마다 흩어 놓기보다 작은 helper로 묶으면 이름과 속성을 관리하기 편합니다. 다만 클라이언트에서 이벤트 전송에 성공한 것과 분석 화면에 수집된 것도 따로 확인해야 합니다.

Guide·NPS·Replay의 검토 범위

Guide는 사용자가 해당 화면을 볼 때 기능 설명을 보여주는 데 사용할 수 있었습니다. NPS는 점수와 응답을 수집하는 기능이지만, 내부 사용자가 업무상 반드시 쓰는 도구의 만족도를 그 숫자 하나로 판단하기는 어렵습니다.

Session Replay는 이벤트 사이에서 사용자가 어떤 동작을 했는지 확인하는 방법으로 검토했습니다. 당시 테스트만으로 문제 해결이나 사용성 개선 효과까지 확인한 것은 아닙니다. 수집 범위와 마스킹, 권한·보관 설정도 검토해야 하는 항목이었습니다.

수집 결과 확인

먼저 현재 Visitor와 Account가 기대한 대상인지 확인하고, 개발·테스트 환경이 운영 데이터에 섞이지 않는지 살펴봤습니다. 이후 이벤트 이름과 속성이 전송되는지, 분석 화면에서 의도한 대상으로 집계되는지 확인하는 순서였습니다.

서버가 정상 응답했다는 기록과 사용자가 작업을 끝냈다는 기록을 함께 볼 수 있다면 문의 내용을 더 구체적으로 확인할 수 있겠다고 생각했습니다. 이번 테스트는 그 가능성을 살펴본 단계였고, 실제 도입 여부나 개선 성과를 확정한 사례로 남기지는 않았습니다.

참고 자료

• Pendo 조건부 초기화 
• Visitor·Account ID와 메타데이터 
• Session Replay 개요 
• 설치 결과 확인