GA4란 무엇인가 — 구글 애널리틱스 4의 개념과 구조 완전 정복 1편
GA4가 뭔지, 왜 만들어졌는지, 어떤 원리로 동작하는지 처음부터 끝까지 완전 정복
매일 GA4를 열어서 숫자를 봅니다. 방문자 수, 세션, 이벤트 수. 그런데 그 숫자가 어디서 어떻게 만들어지는지 알고 계신가요?
모른다고 해서 사이트 운영이 불가능한 건 아닙니다. 하지만 GA4의 구조를 이해하고 숫자를 보는 것과, 그냥 숫자를 보는 것 사이에는 꽤 큰 차이가 있습니다. 똑같은 데이터를 보면서도 어떤 사람은 인사이트를 뽑아내고, 어떤 사람은 "방문자가 늘었네" 하고 끝납니다.
이 시리즈는 GA4를 처음부터 끝까지 다룹니다. 1편에서는 GA4가 왜 만들어졌는지, 이전 버전과 무엇이 다른지, 그리고 데이터가 어떤 구조로 수집되고 저장되는지를 다룹니다. 개념이 잡혀야 이후 보고서도 제대로 읽을 수 있습니다.
GA4가 등장한 배경
구글 애널리틱스의 역사는 2005년에 시작됩니다. 구글이 Urchin Software를 인수하면서 탄생한 이 도구는 이후 웹 분석의 표준으로 자리 잡았습니다. 2012년에는 UA(Universal Analytics, 유니버설 애널리틱스)라는 이름으로 대규모 업그레이드를 거쳤고, 이후 약 10년간 전 세계 수천만 개의 사이트에 설치되었습니다.
그런데 2020년, 구글은 완전히 새로운 설계의 분석 도구를 출시합니다. GA4입니다.
왜 잘 쓰고 있던 UA를 버리고 새로 만들었을까요. 세 가지 이유가 있습니다.
스마트폰과 앱의 부상
UA가 설계되던 시절, 대부분의 웹 사용은 PC 브라우저에서 이루어졌습니다. 그런데 스마트폰이 보급되면서 상황이 달라졌습니다. 사람들은 앱으로, 모바일 브라우저로, 태블릿으로 인터넷을 사용하기 시작했습니다.
UA는 구조적으로 웹 브라우저를 위한 도구였습니다. 앱과 웹을 하나의 도구로 통합해서 분석하는 것이 매우 어려웠습니다. 예를 들어 사용자가 스마트폰 앱으로 상품을 보고, 나중에 PC 브라우저로 구매했다면 UA에서는 이 두 행동이 같은 사람의 것인지 연결하기가 힘들었습니다. 기기도 다르고, 세션도 다르고, 쿠키도 달랐기 때문입니다.
쿠키 기반 추적의 한계
UA는 사용자를 식별하는 데 브라우저 쿠키에 크게 의존했습니다. 그런데 2010년대 후반부터 쿠키 규제가 전 세계적으로 강화되기 시작했습니다.
유럽의 GDPR, 애플의 ITP(Intelligent Tracking Prevention), 그리고 크롬의 서드파티 쿠키 폐기 예고. 이 흐름은 쿠키 기반 추적 방식 자체를 흔들었습니다. UA는 이 변화에 대응하기 어려운 구조였습니다.
머신러닝과 예측 분석의 필요성
데이터 분석의 패러다임이 바뀌고 있었습니다. "과거에 무슨 일이 있었는가"를 보는 것에서, "앞으로 무슨 일이 일어날 것인가"를 예측하는 방향으로 진화하고 있었습니다. UA의 구조는 과거 데이터를 집계하는 데는 강했지만, 머신러닝을 활용한 예측 분석을 붙이기에는 설계 자체가 맞지 않았습니다.
GA4는 이 세 가지 문제를 해결하기 위해 처음부터 새로 설계한 도구입니다. 2020년 10월 공식 출시되었고, 2023년 7월 1일에 구글은 UA의 데이터 수집을 완전히 중단했습니다. 이제 GA4가 유일한 표준입니다.
UA와 GA4, 무엇이 다른가
겉으로 보면 둘 다 "방문자 수 보여주는 도구"처럼 보입니다. 하지만 데이터를 수집하고 저장하는 방식이 근본적으로 다릅니다. 이 차이를 모르면 GA4의 숫자를 제대로 해석할 수 없습니다.

세션 기반 vs 이벤트 기반
UA의 데이터 단위는 세션(Session) 입니다. 사용자가 사이트에 접속하면 세션이 생기고, 그 세션 안에서 발생하는 페이지뷰, 이벤트, 전환이 모두 해당 세션에 귀속됩니다.
GA4는 다릅니다. GA4의 데이터 단위는 이벤트(Event) 입니다. 사이트에서 발생하는 모든 것이 이벤트입니다.
| 행동 | GA4 이벤트 이름 |
|---|---|
| 페이지를 열었다 | page_view |
| 페이지를 90% 스크롤했다 | scroll |
| 외부 링크를 클릭했다 | click |
| 동영상 재생을 시작했다 | video_start |
| 구매를 완료했다 | purchase |
GA4에서 세션은 여전히 존재하지만, 데이터의 기본 단위가 아닙니다. 세션은 session_start라는 이벤트로 시작되고, 이후에 발생하는 모든 이벤트에 세션 ID가 매개변수로 붙습니다. 세션이 이벤트들 사이의 관계를 설명하는 속성이 된 것입니다.
이 구조 덕분에 GA4는 웹과 앱을 동일한 방식으로 처리할 수 있습니다. 앱에서 화면을 봤을 때의 screen_view 이벤트와 웹에서 페이지를 봤을 때의 page_view 이벤트는 구조가 같습니다. 하나의 속성에서 웹과 앱 데이터를 통합 분석할 수 있는 이유입니다.
사용자 식별 방식의 변화
UA에서 사용자를 식별하는 기본 방법은 브라우저 쿠키에 저장된 클라이언트 ID였습니다. 쿠키가 삭제되거나, 다른 브라우저를 쓰거나, 다른 기기를 쓰면 다른 사람으로 인식됐습니다.
GA4는 사용자 식별에 세 가지 방법을 계층적으로 사용합니다.

| 우선순위 | 방법 | 설명 |
|---|---|---|
| 1순위 | 사용자 ID (User ID) | 로그인한 사용자에게 고유 ID 부여. 기기를 넘나들어도 동일 사용자로 인식 |
| 2순위 | 구글 신호 데이터 (Google Signals) | 구글 계정 로그인 + 광고 개인화 허용 시, 구글이 계정 기반으로 식별 |
| 3순위 | 기기 기반 식별 | 브라우저 쿠키(클라이언트 ID) 또는 앱 인스턴스 ID. UA와 유사한 방식 |
이 식별 우선순위는 GA4의 보고 ID(Reporting Identity) 설정에서 제어합니다. GA4 속성 → 데이터 표시 → 보고 ID에서 어떤 방식을 우선시할지 선택할 수 있습니다.
이벤트 구조의 유연성
UA에서 커스텀 이벤트를 수집하려면 카테고리, 액션, 라벨, 값이라는 4개의 고정 필드에 맞춰야 했습니다. 이 틀에 맞지 않는 데이터는 억지로 끼워 맞춰야 했습니다.
GA4는 이벤트 이름과 매개변수를 자유롭게 설계할 수 있습니다. 블로그 포스트 읽기 이벤트를 예로 들면 이렇게 구성할 수 있습니다.
이벤트 이름: post_read
매개변수:
post_title: "GA4란 무엇인가"
post_category: "Dev"
read_percentage: 85
reading_time_seconds: 420
UA로 같은 데이터를 담으려면 카테고리에 "post_read", 액션에 "Dev", 라벨에 제목을 넣고, 읽은 비율은 별도의 커스텀 차원을 추가로 설정해야 했습니다. GA4 방식이 훨씬 직관적입니다.
BigQuery 무료 연동
UA에서 BigQuery 연동은 GA4 360(유료 버전)에서만 가능했습니다. 원시 데이터를 내보내는 기능이 유료였습니다.
GA4는 BigQuery 내보내기를 무료로 제공합니다. GA4 인터페이스의 보고서는 구글이 미리 집계한 데이터를 보여주는 것이고, 경우에 따라 샘플링이 발생할 수 있습니다. BigQuery에 내보낸 원시 데이터는 샘플링 없이 이벤트 하나하나가 개별 레코드로 저장되어 있습니다. SQL로 직접 분석하면 GA4 인터페이스에서는 불가능한 깊이 있는 분석이 가능합니다.
아래 표로 UA와 GA4의 핵심 차이를 정리했습니다.
| 항목 | UA (유니버설 애널리틱스) | GA4 |
|---|---|---|
| 데이터 단위 | 세션(Session) | 이벤트(Event) |
| 웹+앱 통합 | 어려움 (별도 도구 필요) | 기본 지원 |
| 사용자 식별 | 쿠키 기반 | 계층적 (User ID → 신호 → 쿠키) |
| 이벤트 구조 | 카테고리/액션/라벨/값 고정 | 이름 + 매개변수 자유 설계 |
| BigQuery | 유료 버전만 가능 | 무료 제공 |
| 예측 분석 | 미지원 | 머신러닝 기반 예측 지원 |
| 서비스 상태 | 2023년 7월 종료 | 현재 표준 |
이벤트 기반 데이터 구조
GA4의 핵심은 이벤트입니다. 이벤트가 어떻게 분류되고 어떤 구조를 갖는지 이해하면, 이후 설정과 분석이 훨씬 명확해집니다.
이벤트의 네 가지 유형
GA4의 이벤트는 수집 방식에 따라 네 가지로 나뉩니다.

1. 자동 수집 이벤트 (Automatically Collected Events)
GA4 태그를 설치하는 것만으로 자동 수집됩니다. 별도 설정이 필요 없습니다.
| 이벤트 | 발생 시점 |
|---|---|
first_visit | 사용자가 처음 사이트를 방문했을 때 |
session_start | 세션이 시작될 때 |
user_engagement | 10초 이상 머물거나, 전환 발생 시, 2페이지 이상 조회 시 |
2. 향상된 측정 이벤트 (Enhanced Measurement Events)
GA4 데이터 스트림 설정에서 향상된 측정을 활성화하면 추가로 수집됩니다. 코드 작성 없이 GA4가 자동으로 감지합니다.
| 이벤트 | 발생 시점 |
|---|---|
page_view | 페이지가 로드될 때 (기본 활성화) |
scroll | 페이지를 90% 이상 스크롤했을 때 |
click | 외부 링크를 클릭했을 때 |
view_search_results | 사이트 내 검색 결과 페이지를 봤을 때 |
video_start | YouTube 영상 재생을 시작했을 때 |
video_progress | YouTube 영상을 10%, 25%, 50%, 75% 재생했을 때 |
video_complete | YouTube 영상 재생이 완료됐을 때 |
file_download | 파일을 다운로드했을 때 |
3. 추천 이벤트 (Recommended Events)
구글이 업종별로 권장하는 이벤트입니다. GA4가 자동으로 수집하지는 않지만, 정해진 이름과 매개변수 형식을 따르면 GA4의 표준 보고서에서 자동으로 집계됩니다.
전자상거래 관련 추천 이벤트를 예로 들면 아래와 같습니다.
| 이벤트 | 의미 | 필수 매개변수 |
|---|---|---|
view_item | 상품 상세 페이지 조회 | items |
add_to_cart | 장바구니에 추가 | items, value, currency |
begin_checkout | 결제 시작 | items, value, currency |
purchase | 구매 완료 | transaction_id, value, currency, items |
이 이벤트들은 이름과 매개변수를 정확히 맞춰야 GA4 보고서에서 올바르게 처리됩니다.
4. 맞춤 이벤트 (Custom Events)
위의 세 유형에 해당하지 않는, 직접 설계하고 구현하는 이벤트입니다. 사이트의 특성에 맞게 수집하고 싶은 행동을 정의하고, 해당 행동이 발생할 때 이벤트가 전송되도록 코드를 작성하거나 구글 태그 관리자(GTM)에서 설정합니다.
한 가지 주의할 점이 있습니다. 맞춤 이벤트 데이터는 GA4의 표준 보고서에 자동으로 나타나지 않습니다. 보고서에서 분석하려면 맞춤 정의(Custom Definition)를 설정해서 해당 매개변수를 차원이나 측정 항목으로 등록해야 합니다. 이 부분은 5편에서 자세히 다룹니다.
이벤트의 구조: 이름과 매개변수
GA4의 모든 이벤트는 두 가지 요소로 구성됩니다.
- 이벤트 이름: 어떤 행동이 발생했는지를 나타냅니다.
page_view,scroll,purchase같은 것들입니다. - 매개변수(Parameter): 그 이벤트에 대한 추가 정보입니다. 어떤 페이지를 봤는지, 어떤 상품을 샀는지 같은 정보가 담깁니다.
사용자가 이 블로그의 특정 포스트를 봤을 때 발생하는 page_view 이벤트는 실제로 이런 구조를 가집니다.
이벤트 이름: page_view
매개변수:
page_location: "https://dechive.info/archive/ga4-introduction"
page_referrer: "https://www.google.com"
page_title: "GA4란 무엇인가"
engagement_time_msec: 0
이벤트가 발생할 때마다 이 데이터가 구글 서버로 전송되고, GA4는 이를 저장하고 집계해서 보고서에 표시합니다.
매개변수에는 두 종류가 있습니다.
| 종류 | 설명 | 예시 |
|---|---|---|
| 이벤트 매개변수 | 해당 이벤트가 발생했을 때의 상황 정보 | 페이지 URL, 상품 가격, 카테고리 |
| 사용자 속성 | 이벤트와 무관하게 사용자 자체에 대한 정보 | 로그인 여부, 멤버십 등급, 언어 설정 |
사용자 속성은 한 번 설정하면 이후에 발생하는 모든 이벤트에 자동으로 붙어서 전송됩니다.
GA4의 데이터 수집 흐름
GA4가 데이터를 수집해서 보고서에 표시하기까지 어떤 과정을 거치는지 이해하면, 나중에 데이터가 이상하게 보일 때 원인을 파악하는 데 도움이 됩니다.

1단계: 사용자 행동 발생
사용자가 사이트에 접속해서 페이지를 보고, 스크롤하고, 클릭하고, 구매합니다. 이 모든 행동이 데이터의 원천입니다.
2단계: 클라이언트에서 이벤트 생성
사이트에 설치된 GA4 태그가 사용자의 행동을 감지하고 이벤트 데이터를 만듭니다. 이 과정은 사용자의 브라우저 안에서 자바스크립트가 실행되면서 일어납니다.
향상된 측정이 활성화되어 있다면 GA4 태그가 자동으로 스크롤, 클릭, 페이지 이동 등을 감지합니다. 맞춤 이벤트의 경우에는 개발자가 작성한 코드나 GTM에서 설정한 태그가 해당 시점에 데이터를 만듭니다.
3단계: 구글 서버로 전송
생성된 이벤트 데이터는 구글의 수집 서버로 전송됩니다. HTTP POST 요청으로 전송되며, 브라우저 개발자 도구 네트워크 탭에서 google-analytics.com/g/collect 요청으로 확인할 수 있습니다.
여기서 한 가지 알아두어야 할 것이 있습니다. 이 전송이 실패하면 데이터가 유실됩니다. 사용자가 너무 빨리 페이지를 이탈하거나, 광고 차단기가 GA4 요청을 막는 경우에 데이터가 수집되지 않을 수 있습니다. GA4가 수집하는 데이터는 실제 사용자 행동의 100%를 반영하지는 않습니다. 경향을 파악하는 도구로 이해하는 것이 정확합니다.
4단계: 데이터 처리 및 저장
구글 서버에 도달한 이벤트 데이터는 처리 과정을 거칩니다. 세션을 계산하고, 봇 트래픽을 필터링하고, 지리적 위치와 기기 정보를 분류합니다. 설정해놓은 필터나 이벤트 수정도 이 단계에서 적용됩니다.
이 처리에는 시간이 걸립니다. 구글 공식 문서 기준으로 대부분의 GA4 보고서 데이터는 이벤트 발생 후 24~48시간 내에 완전히 처리되어 표시됩니다. 단, 실시간 보고서는 별도로 수 분 내에 바로 확인할 수 있습니다. 오늘 데이터를 표준 보고서에서 정확하게 보려면 다음날 확인하는 것이 안전합니다.
5단계: 보고서에 표시
처리된 데이터는 GA4 인터페이스에 표시됩니다. GA4 보고서는 원시 데이터를 그대로 보여주는 것이 아니라, 미리 집계된 데이터를 보여줍니다. 데이터 양이 많은 경우 샘플링이 발생할 수 있습니다.
원시 데이터, 즉 이벤트 하나하나의 개별 레코드를 보려면 BigQuery 연동이 필요합니다. BigQuery에서는 events_YYYYMMDD 형태의 테이블에 날짜별로 원시 이벤트 데이터가 저장됩니다. 이 부분은 시리즈 후반에서 자세히 다룹니다.
GA4의 계정 구조
GA4를 처음 설정할 때 계정 구조가 헷갈릴 수 있습니다. GA4는 계정, 속성, 데이터 스트림의 3단계 구조를 가집니다.

| 단계 | 설명 | 예시 |
|---|---|---|
| 계정 (Account) | 최상위 단위. 하나의 비즈니스 또는 조직 | Dechive 계정 |
| 속성 (Property) | 분석의 기본 단위. 웹+앱 통합 가능. 측정 ID(G-XXXXXXXXXX) 부여 | Dechive 속성 |
| 데이터 스트림 (Data Stream) | 데이터가 유입되는 채널. 웹 / Android / iOS로 나뉨 | Dechive 웹 스트림 |
하나의 계정 안에 여러 속성을 만들 수 있고, 하나의 속성 안에 여러 데이터 스트림을 추가할 수 있습니다.
GA4 핵심 용어 정리
GA4 보고서에서 자주 마주치는 용어들입니다. 정확한 의미를 알아야 숫자를 제대로 읽을 수 있습니다.
사용자(User)
GA4는 사용자를 두 가지로 집계합니다.
| 구분 | 설명 |
|---|---|
| 총 사용자 (Total Users) | 선택한 기간 동안 최소 한 번이라도 방문한 사용자 수 |
| 활성 사용자 (Active Users) | 참여 세션을 시작하거나, 전환 이벤트를 발생시키거나, 앱을 처음 실행한 사용자 수 |
GA4 보고서에서 기본으로 표시되는 "사용자" 수치는 활성 사용자 수입니다. UA의 사용자 수치와 직접 비교하면 안 됩니다.
세션(Session)
사용자가 사이트에 접속해서 상호작용하는 단위입니다. GA4에서 세션은 session_start 이벤트로 시작되고, 30분간 아무 상호작용이 없으면 종료됩니다. UA와 달리 자정이 지나도 세션이 강제로 나뉘지 않습니다.
**참여 세션(Engaged Session)**은 GA4에서 새로 도입된 개념입니다. 아래 세 조건 중 하나 이상을 만족한 세션을 말합니다.
- 10초 이상 사이트에 머문 세션
- 전환 이벤트가 발생한 세션
- 페이지나 화면을 2개 이상 조회한 세션
전환(Conversion)
비즈니스 목표와 관련된 중요한 이벤트입니다. 원하는 이벤트를 전환으로 표시하면 GA4 보고서에서 별도로 집계되고, 구글 광고와 연동할 때 최적화 목표로 사용할 수 있습니다. UA의 "목표(Goal)"에 해당하는 개념입니다.
측정 기준과 측정 항목
GA4 보고서를 이해하는 데 가장 기본이 되는 두 개념입니다.
| 개념 | 설명 | 형태 | 예시 |
|---|---|---|---|
| 측정 기준 (Dimension) | 데이터를 분류하는 기준 | 문자열(텍스트) | 국가, 기기 유형, 채널, 페이지 URL |
| 측정 항목 (Metric) | 측정 가능한 수치 | 숫자 | 사용자 수, 세션 수, 전환율 |
보고서는 항상 "어떤 측정 기준으로 나눠서, 어떤 측정 항목을 볼 것인가"의 조합입니다. "국가별 활성 사용자 수"나 "채널별 전환율" 같은 방식입니다.
참여율과 이탈률
| 지표 | 정의 | 좋을수록 |
|---|---|---|
| 참여율 (Engagement Rate) | 전체 세션 중 참여 세션의 비율 | 높을수록 좋음 |
| 이탈률 (Bounce Rate) | 전체 세션 중 비참여 세션의 비율 (= 100% - 참여율) | 낮을수록 좋음 |
UA의 이탈률과 GA4의 이탈률은 계산 방식이 다릅니다. 두 도구의 이탈률 수치를 직접 비교하면 안 됩니다.
정리
1편에서 다룬 내용을 세 가지로 압축합니다.
첫째, GA4는 이벤트 중심입니다. 사이트에서 발생하는 모든 것, 페이지뷰도 클릭도 스크롤도 구매도 전부 이벤트입니다. 이 이벤트가 GA4 분석의 원재료입니다.
둘째, GA4는 사용자를 중심으로 분석합니다. 여러 기기에서의 행동을 하나의 사용자로 연결하는 것을 목표로 합니다. UA가 쿠키에만 의존했던 것과 달리, GA4는 사용자 ID와 구글 신호 데이터를 계층적으로 활용합니다.
셋째, GA4의 데이터는 처리 과정이 있습니다. 이벤트 발생에서 보고서 표시까지 24~48시간이 필요하고, 보고서의 데이터는 집계된 형태입니다. 원시 데이터가 필요하면 BigQuery를 활용합니다.
2편에서는 GA4의 이벤트 설계를 깊이 다룹니다. 어떤 이벤트를 수집해야 하는지, 이벤트와 매개변수를 어떻게 설계해야 분석에 유용한 데이터가 쌓이는지, 전환 설계의 기준은 무엇인지를 다룰 것입니다.
