Amplitude로 포트폴리오 사용자 흐름을 측정하고 IA 개선하기

봄·2026년 8월 6일

2026.07.07~2026.08.06 섹션별 고유 사용자 추이

포트폴리오를 배포한 뒤 방문자 수는 확인할 수 있었지만, 사람들이 실제로 어떤 콘텐츠까지 확인하고 어느 구간에서 이탈하는지는 알기 어려웠습니다.

제 포트폴리오는 한 페이지 안에서 여러 섹션이 길게 이어지는 구조이기 때문에 페이지뷰만으로는 사용자가 핵심 콘텐츠나 Contact 영역까지 도달했는지 확인할 수 없었습니다.

또한 피드백을 받아 콘텐츠나 정보 구조를 변경하더라도, 그 변경이 실제 사용자 탐색에서도 효과가 있었는지 판단할 기준이 필요했습니다.

그래서 Amplitude를 적용해 섹션 도달과 주요 링크 클릭을 직접 이벤트로 수집했습니다.

이벤트 정의

모든 클릭을 자동으로 수집하기보다는 실제로 확인하고 싶은 행동만 이벤트로 정리했습니다.

export const ANALYTICS_EVENT = {
  PORTFOLIO_VIEWED: "portfolio_viewed",
  SECTION_VIEWED: "section_viewed",
  PROJECT_CLICKED: "project_clicked",
  PROJECT_EXTERNAL_LINK_CLICKED: "project_external_link_clicked",
  CTA_CLICKED: "cta_clicked",
  CONTACT_FORM_STARTED: "contact_form_started",
  CONTACT_FORM_SUBMITTED: "contact_form_submitted",
  CONTACT_FORM_FAILED: "contact_form_failed",
} as const;

이벤트 이름을 각 컴포넌트에 직접 작성하면 오탈자나 이름 불일치가 발생할 수 있기 때문에 한 파일에서 관리했습니다.

Amplitude 설정에서는 페이지뷰, 세션, 유입 정보는 자동으로 수집하고, 클릭과 폼 인터랙션은 필요한 행동만 직접 기록하도록 설정했습니다.

amplitude.init(apiKey, undefined, {
  autocapture: {
    attribution: true,
    pageViews: true,
    sessions: true,
    elementInteractions: false,
    fileDownloads: true,
    formInteractions: false,
  },
});

섹션 도달 기준

섹션이 화면 끝에 조금만 걸려도 도달로 기록하면 실제보다 수치가 높게 집계될 수 있다고 판단했습니다.

그래서 IntersectionObserver의 rootMargin을 사용해 섹션이 화면 중앙 영역에 진입했을 때 도달 이벤트를 기록했습니다.

const observer = new IntersectionObserver(
  ([entry]) => {
    if (!entry || !entry.isIntersecting || hasTracked.current) {
      return;
    }

    hasTracked.current = true;

    trackAmplitudeEvent(ANALYTICS_EVENT.SECTION_VIEWED, {
      section_name: sectionName,
      section_order: sectionOrder,
      visibility_ratio: entry.intersectionRatio,
    });

    observer.disconnect();
  },
  {
    threshold: 0,
    rootMargin: "-40% 0px -40% 0px",
  }
);

같은 섹션을 여러 번 오가더라도 중복으로 기록되지 않도록 hasTracked를 사용했고, 한 번 기록한 뒤에는 Observer를 정리했습니다.

모든 이벤트에는 현재 경로, 화면 너비, 기기 유형도 공통으로 추가했습니다.

amplitude.track(eventName, {
  ...properties,
  pathname: window.location.pathname,
  viewport_width: window.innerWidth,
  device_type: getDeviceType(),
});

모바일과 데스크톱은 스크롤 길이와 화면 구성이 다르기 때문에 이후 기기별 탐색 흐름을 나누어 확인할 수 있도록 함께 수집했습니다.

첫 번째 사용자 흐름 측정

수집한 이벤트를 기준으로 다음과 같은 퍼널을 만들었습니다.

포트폴리오 방문
→ 핵심 역량 영역 도달
→ Contact 영역 도달

2026년 8월 6일 기준 첫 번째 측정 결과는 다음과 같았습니다.

핵심 역량 영역에 도달한 400명 중 Contact까지 내려간 사용자는 216명으로, 54.0%였습니다.

Amplitude를 적용하기 전에는 포트폴리오가 길다는 피드백을 받아도 실제로 얼마나 많은 사용자가 중간과 마지막까지 확인하는지 알 수 없었습니다.

측정 이후에는 단순 방문자 수가 아니라 섹션별 도달과 외부 링크 클릭을 기준으로 사용자 탐색 흐름을 확인할 수 있게 됐습니다.

다만 이 데이터만으로 사용자가 왜 이탈했는지까지 알 수 있는 것은 아닙니다. 따라서 특정 구간이 문제라고 단정하기보다, 정성적인 피드백과 함께 어떤 구조를 우선적으로 수정할지 판단하는 기준으로 사용했습니다.

첫 번째 측정 결과

  • 전체 방문자 653명
  • 핵심 역량 영역 도달 사용자 400명, 61.3%
  • Contact 도달 사용자 216명, 33.1%
  • 핵심 역량 도달 사용자 중 Contact 도달률 54.0%

단순히 방문자 수만 확인하던 상태에서, 실제 사용자가 어느 구간까지 탐색했는지 확인할 수 있는 측정 환경을 구축했습니다.

이후 실제로 정보 구조를 다시 설계했습니다.

첫 번째 분석 이후에는 데이터를 확인하는 데서 끝내지 않고, 실제 포트폴리오 구조를 다시 살펴봤습니다.

관련 pr: https://github.com/bom0320/web-portfolio/pull/11

초기에는 제가 작업하는 방식과 여러 프로젝트를 하나의 긴 서사 흐름 안에서 이어서 보여주는 구조로 구성했습니다.

하지만 현업자 피드백을 받는 과정에서 여러 프로젝트가 하나의 흐름 안에 묶여 있어, 사용자가 원하는 프로젝트를 빠르게 탐색하기 어렵다는 문제를 확인했습니다.

이를 반영해 Build와 Projects를 분리하고, 프로젝트를 독립적으로 탐색할 수 있도록 IA(정보 구조)를 재설계했습니다.

재설계 이후에는 Intro, Build, Projects, Contact를 각각 독립적으로 측정할 수 있도록 섹션 이벤트 구조도 다시 정리했습니다.

IA 재설계 이후 · 2026.08.01~2026.08.31 섹션별 일별 고유 사용자 추이

변경 이후 사용자 행동을 다시 검증했습니다.

정보 구조를 변경한 뒤에는 단순히 “더 좋아진 것 같다”고 판단하지 않고, 동일한 측정 기준으로 변경 전후의 사용자 행동을 다시 비교했습니다.

Amplitude 이벤트 수집을 시작한 2026.07.14부터 08.31까지 portfolio_viewed를 1회 이상 발생시킨 중복 제거 고유 사용자는 877명이었습니다.

이 데이터를 기반으로 정보 구조 개편 전후의 Contact 도달률을 비교한 결과는 다음과 같았습니다.

지표변경 전변경 후변화
Contact 도달률39.6%48.3%+8.7%p

정보 구조를 재설계한 이후 Contact까지 도달한 사용자 비율은 39.6%에서 48.3%로 8.7%p 증가했습니다.

초기 분석에서 확인한 33.1%는 2026년 8월 6일 시점의 첫 번째 퍼널 결과이고, 39.6% → 48.3%는 이후 IA 변경 효과를 확인하기 위해 동일한 조건으로 개편 전후를 비교한 별도의 지표입니다.

따라서 두 수치를 직접 비교하지 않고 각각 초기 사용자 흐름을 파악하기 위한 기준과 정보 구조 변경 효과를 검증하기 위한 기준으로 사용했습니다.

결과

처음 Amplitude를 도입한 목적은 단순히 방문자 수를 더 자세히 확인하기 위해서가 아니었습니다.

사용자가 실제로 어디까지 탐색하는지 확인할 기준을 만들고, 변경한 경험이 실제 사용자 행동에서는 어떻게 나타나는지 다시 확인하기 위해서였습니다.

  • 섹션 도달·외부 링크 클릭 등 필요한 행동을 커스텀 이벤트로 정의
  • 화면 중앙 영역 진입을 기준으로 섹션 도달을 측정
  • 초기 653명의 사용자 흐름을 분석해 탐색 흐름의 기준선 확보
  • 현업자 피드백을 반영해 Build와 Projects를 분리하고 IA 재설계
  • 2026.07.14~08.31 동안 877명의 중복 제거 고유 사용자 행동 분석
  • 정보 구조 개편 이후 Contact 도달률 39.6% → 48.3%, +8.7%p 개선

처음에는 사용자의 탐색 흐름을 확인하기 위한 측정 환경을 만드는 것에서 시작했지만, 이후에는 그 데이터를 실제 구조 변경과 검증까지 연결하게 됐습니다.

정성적인 피드백만으로 판단하는 데서 끝나지 않고, 피드백 → 구조 변경 → 사용자 행동 검증으로 이어지는 반복 개선 과정으로 확장했습니다.

profile
FE 개발 꿈틀이

0개의 댓글