지금 읽는 곳UA는 왜 세션 중심으로 설계됐나목차
STEP 2 중급·실무 › 2-4. 데이터 분석·퍼포먼스 테크 › 과목 80 › 레슨 01
GA4의 핵심 패러다임: UA(유니버설 애널리틱스)의 세션 중심 데이터 구조와 GA4의 '이벤트 중심(Event-driven)' 구조 완벽 해부
숫자가 안 맞는 게 아니라 애초에 다른 언어로 집계된다 — UA 시절 보고서를 GA4에서 그대로 재현하려다 막히는 이유가 여기 있습니다.
핵심요약
- UA는 방문(세션)을 기본 단위로 삼아 히트를 페이지뷰·이벤트·거래 등 타입별로 나눠 집계했다
- GA4는 페이지뷰를 포함한 모든 상호작용을 '이벤트' 하나의 구조로 통일해 수집한다
- 세션조차 session_start라는 이벤트에서 파생된 개념일 뿐 별도 히트 타입이 아니다
- 이 구조 차이 때문에 UA 보고서와 GA4 보고서의 수치가 항목별로 딱 맞아떨어지지 않는다
- GA4를 제대로 쓰려면 '세션이 몇 개'가 아니라 '어떤 이벤트가 몇 번 발생했는가'로 사고를 바꿔야 한다
UA는 왜 세션 중심으로 설계됐나
유니버설 애널리틱스는 웹사이트 방문을 기본 분석 단위로 삼았습니다. 사용자가 사이트에 들어와 일정 시간(기본 30분) 안에 벌인 행동 전체를 하나의 세션으로 묶고, 그 안에서 발생한 상호작용을 페이지뷰 히트, 이벤트 히트, 전자상거래 히트처럼 타입별로 구분해 기록했습니다. 이 구조는 "이번 달 방문자가 몇 명이고, 세션당 몇 페이지를 봤는가"를 묻는 웹사이트 분석에는 잘 맞았지만, 앱과 웹을 동시에 쓰는 사용자의 행동을 하나로 이어 보거나, 페이지 이동이 아닌 클릭·스크롤 같은 미세한 행동을 표준화해서 다루는 데는 구조적으로 불리했습니다.
GA4가 이벤트 중심으로 바꾼 이유는 무엇인가
구글은 앱(파이어베이스 애널리틱스)과 웹의 측정 방식을 하나로 합치는 과정에서, 아예 측정 단위 자체를 이벤트로 통일했습니다. GA4에서는 페이지를 보는 것도 page_view라는 이벤트고, 스크롤도 scroll 이벤트, 구매 완료도 purchase 이벤트입니다. 히트 타입이라는 개념 자체가 사라지고, 모든 게 "이벤트 이름 + 매개변수(parameter)"라는 동일한 형태로 기록됩니다. 이 통일된 구조 덕분에 웹에서 일어난 행동과 앱에서 일어난 행동을 같은 스키마로 비교·결합할 수 있게 됐고, 새로운 행동을 추적하고 싶을 때도 새로운 히트 타입을 발명할 필요 없이 이벤트 이름 하나만 새로 정의하면 됩니다.
세션은 GA4에서 어떻게 취급되나
UA에서 세션은 독립적인 개념이자 보고서의 최소 단위였지만, GA4에서 세션은 session_start라는 이벤트가 발생했다는 사실, 그리고 각 이벤트에 자동으로 붙는 ga_session_id라는 매개변수로 재구성된 파생 개념입니다. 즉 GA4 안에 "세션 히트"라는 것은 존재하지 않고, 세션이라는 개념 자체를 이벤트 데이터에서 역산해 만들어낸 지표일 뿐입니다. 이 차이 때문에 세션 계산 기준(예: 자정을 넘기거나 캠페인 파라미터가 바뀌면 새 세션으로 처리하는 규칙)도 UA와 GA4가 세부적으로 다르고, 그 결과 같은 트래픽이라도 두 도구가 보고하는 세션 수가 정확히 일치하지 않습니다.
왜 두 도구의 숫자가 항목별로 어긋나는가
UA에서 GA4로 넘어온 팀이 가장 자주 당황하는 지점은 사용자 수·세션 수·이탈률 같은 익숙한 지표의 정의 자체가 바뀌었다는 사실입니다. 예를 들어 UA의 이탈률(bounce rate)은 "상호작용이 하나도 없었던 세션의 비율"이었지만, GA4는 정반대로 참여율(engagement rate, 10초 이상 체류하거나 전환·2페이지 이상 조회가 있었던 세션의 비율)을 기본으로 보여주고, 이탈률은 참여율의 역수로 계산됩니다. 계산 기준 자체가 다르니 두 도구를 나란히 띄워놓고 숫자가 안 맞는다고 확인하는 작업은 애초에 의미가 없습니다. 마이그레이션 초기에는 "숫자를 맞추는 것"이 아니라 "GA4 기준으로 새로 baseline을 잡는 것"이 맞는 접근입니다.
이벤트는 실제로 어떤 층위로 나뉘어 쌓이나
GA4의 이벤트는 발생 원리에 따라 크게 세 층위로 나뉩니다. 첫째는 first_visit, session_start처럼 스트림을 만들자마자 아무 설정 없이도 자동으로 수집되는 자동 수집 이벤트, 둘째는 스크롤·이탈 클릭·파일 다운로드처럼 관리자 화면에서 토글만 켜면 코드 삽입 없이 잡히는 향상된 측정 이벤트, 셋째는 purchase, sign_up처럼 사업 목적에 맞게 개발자나 GTM으로 직접 설계해서 심는 맞춤 이벤트입니다. 이 세 층위를 구분해서 이해해두면, 나중에 "이 이벤트가 왜 자동으로 잡히는지" 또는 "왜 우리 팀이 따로 코드를 심어야 하는지"를 헷갈리지 않게 됩니다. 각 이벤트에는 이름 하나와, 그 이벤트를 설명하는 key-value 형태의 매개변수(parameter)가 여러 개 붙는 구조인데, 이 매개변수 설계 방식은 뒤에 나올 이벤트·전환 설계 레슨에서 더 깊이 다룹니다.
사용자 개념도 UA와 GA4가 다르게 정의한다
UA의 '사용자'는 주로 쿠키 기반 클라이언트 ID로 식별된 순 방문자 수를 뜻했지만, GA4는 '활성 사용자(active users)'를 기본 지표로 채택해, 지정한 기간 동안 참여 세션(engaged session)을 하나 이상 발생시킨 사용자만 집계합니다. 겉보기엔 비슷한 '사용자 수'라는 이름이지만 내부 계산 기준이 다르기 때문에, 두 도구를 나란히 놓고 같은 값이 나오길 기대하면 안 됩니다. 이 차이는 나중에 사용자 식별(User-ID)·크로스 디바이스 레슨에서 다시 등장하니, 지금은 "이름이 같아도 정의가 다를 수 있다"는 원칙만 기억해두면 충분합니다.
실무에서 사고방식을 어떻게 바꿔야 하나
GA4를 다룰 때는 "이 페이지의 방문자가 몇 명인가"보다 "이 사용자가 어떤 이벤트를 순서대로 발생시켰는가"를 먼저 떠올리는 습관이 필요합니다. 맞춤 보고서를 설계할 때도 히트 타입을 고르는 게 아니라 이벤트 이름과 그 이벤트에 붙은 매개변수(예: page_location, value, currency)를 조합해서 원하는 지표를 만들어야 합니다. 이 이벤트 중심 사고는 다음 레슨에서 다룰 데이터 스트림·측정 ID 구조, 그리고 이후 레슨의 맞춤 측정기준·측정항목 설계까지 GA4 전체를 관통하는 기본 문법이므로, 여기서 확실히 정리하고 넘어가는 편이 뒤 레슨을 이해하는 속도를 크게 높여줍니다.