GA4 고급 설정 실전: 이벤트 추적과 전환 퍼널 완전 가이드

2023년 7월 1일, Google은 Universal Analytics의 데이터 수집을 완전히 종료했습니다. 그날 아침 관리 화면을 열고 UA 보고서의 데이터 선이 딱 끊긴 것을 보면서 제 머릿속에 떠오른 생각은 하나뿐이었습니다. GA4, 이걸 대체 어떻게 써야 하지?

당신도 저처럼 UA에서 넘어온 뒤 기본 코드만 심어두고 GA4 화면 앞에서 멍해진 적이 있다면, 너무 걱정하지 않아도 됩니다. 혼자가 아닙니다. 많은 사이트 운영자가 사실상 “맨몸”으로 운영하고 있습니다. 페이지 조회는 보이지만 사용자가 어떤 버튼을 눌렀는지, 글을 얼마나 읽었는지, 어느 단계에서 이탈했는지 같은 정말 가치 있는 데이터는 하나도 잡히지 않습니다.

이 글은 GA4가 무엇인지 설명하지 않습니다. 대신 실전 이야기를 합니다. 이벤트 추적으로 사용자 행동을 어떻게 읽을지, 전환 퍼널로 이탈 지점을 어떻게 찾을지, 그리고 깊은 분석이 필요하다면 데이터를 BigQuery로 내보내 SQL로 직접 조회하는 방법까지 다룹니다. 먼저 이벤트의 세 가지 유형부터 보겠습니다.

1. GA4 이벤트 추적의 세 가지 유형

GA4의 핵심 로직은 UA와 완전히 다릅니다. UA는 “세션 + 페이지 조회” 모델이고, GA4는 “모든 것이 이벤트”인 모델입니다.

이 말을 여러 번 들어봤을 수 있습니다. 그런데 정확히 무엇을 뜻할까요? 간단히 말해 페이지 조회도 이벤트이고, 버튼 클릭도 이벤트이며, 동영상 재생도 이벤트이고, 페이지 하단까지 스크롤하는 것도 이벤트입니다. 모든 사용자 행동이 GA4에서는 독립적인 “이벤트” 기록입니다.

하지만 이벤트를 아무렇게나 만들면 안 됩니다. Google은 이벤트를 세 가지 유형으로 나누고, 각 유형마다 용도와 제한이 다릅니다.

1. 자동 이벤트(Enhanced Measurement): 바로 사용 가능

이것은 GA4가 제공하는 “공짜 점심”에 가깝습니다. 데이터 스트림을 만들 때 Enhanced Measurement가 기본으로 켜져 있고, 다음 7가지 상호작용을 자동으로 추적합니다.

• 페이지 조회(page_view)
• 스크롤(scroll). 단, 90% 스크롤 깊이만 추적
• 외부 클릭(click)
• 사이트 검색(search)
• 동영상 상호작용(video_start, video_progress, video_complete)
• 파일 다운로드(file_download)
• 양식 상호작용(form_start, form_submit)

꽤 충분해 보이지요? 하지만 여기에는 함정이 있습니다. 스크롤 추적은 사용자가 페이지의 90% 지점까지 내려갔을 때만 기록합니다. 글을 끝까지 읽은 사람이 얼마나 되는지 알고 싶거나, 50%, 75% 같은 지점에서 읽기 진행률을 추적하고 싶다면 Enhanced Measurement만으로는 불가능합니다. GTM으로 직접 설정해야 합니다.

제안은 간단합니다. Enhanced Measurement는 켜두되, 너무 큰 기대는 하지 마세요. 이것이 주는 것은 기본 데이터입니다. 정말 가치 있는 사용자 행동은 결국 직접 설정해야 합니다.

2. 추천 이벤트: Google의 규격을 따르기

Google은 업종별로 미리 정의한 “추천 이벤트”를 제공합니다. 예를 들어 이커머스에는 add_to_cart, begin_checkout, purchase가 있고, 콘텐츠 사이트에는 sign_up, login, share가 있습니다.

추천 이벤트의 장점은 올바른 이벤트 이름과 매개변수를 사용하면 GA4가 관련 보고서를 자동으로 만들어준다는 점입니다. 예를 들어 purchase 이벤트를 쓰면 GA4가 해당 보고서를 자동으로 생성할 수 있습니다.

다만 추천 이벤트가 자동으로 발생하는 것은 아닙니다. 여전히 웹사이트에 코드를 추가하거나 GTM으로 설정해야 합니다. 단지 이벤트 이름과 매개변수를 Google의 규격에 엄격히 맞춰야 할 뿐입니다.

블로그 사이트에서 자주 쓰는 추천 이벤트 예시는 다음과 같습니다.

이벤트 이름	트리거 상황	핵심 매개변수
sign_up	사용자 가입 성공	method(가입 방식)
login	사용자 로그인 성공	method(로그인 방식)
share	사용자가 콘텐츠 공유	content_type, item_id

저는 제 블로그에서 sign_up 이벤트로 구독 행동을 추적했습니다. 처음에는 이벤트 이름을 signUp처럼 camelCase로 썼는데, GA4가 전혀 인식하지 못했습니다. 추천 이벤트는 반드시 snake_case를 써야 하고, 글자 하나도 틀리면 안 됩니다.

3. 맞춤 이벤트: 원하는 것은 무엇이든 추적할 수 있지만 비용이 있다

추적하려는 행동이 Google 추천 목록에 없다면 직접 이벤트를 정의해야 합니다. 예를 들어 저는 “사용자가 글을 끝까지 읽음”을 추적하기 위해 article_read_complete 이벤트를 정의했습니다.

맞춤 이벤트는 자유도가 높지만 몇 가지 제한이 있습니다.

1. 매개변수 상한: 이벤트 하나당 맞춤 매개변수는 최대 25개입니다. GA4 분야의 권위자인 Simo Ahava가 테스트한 결과, 25개를 초과한 매개변수 데이터는 BigQuery로는 내보낼 수 있지만 GA4 기본 보고서에서는 무시됩니다.

2. 명명 규칙: 문자, 숫자, 밑줄만 사용할 수 있고 반드시 문자로 시작해야 합니다. 추천 이벤트와 일관성을 맞추기 위해 snake_case를 권장합니다.

3. 보고서 지연: 맞춤 이벤트를 설정한 뒤 GA4 보고서에 표시되기까지 24-48시간이 걸릴 수 있습니다. 설정이 틀렸다고 바로 판단하지 말고 먼저 기다려보세요.

설정 우선순위: 간단한 의사결정 트리

어떤 이벤트 유형을 써야 할지 모르겠다면 다음 순서로 판단하세요.

1. 먼저 Enhanced Measurement에 있는지 확인합니다. 바로 쓸 수 있고, 쓸 수 있다면 아끼는 편이 좋습니다.
2. 그다음 추천 이벤트 목록을 확인합니다. 규격을 따르면 보고서가 자동으로 생성됩니다.
3. 정말 없을 때만 맞춤 이벤트를 만듭니다. 자유도는 높지만 유지보수 비용도 큽니다.

솔직히 말하면 대부분의 블로그 사이트는 Enhanced Measurement와 몇 개의 추천 이벤트만으로도 충분합니다. 맞춤 이벤트는 깊은 분석이 필요한 사람을 위한 도구입니다.

2. 이벤트 추적 실전 설정

세 가지 이벤트 유형의 차이를 이해했다면 이제 직접 설정할 차례입니다.

GA4 이벤트를 설정하는 주된 방식은 두 가지입니다. Google Tag Manager(GTM)를 쓰거나, 웹페이지에 gtag.js 코드를 직접 작성하는 방식입니다. 저는 GTM을 권합니다. 학습 비용은 조금 높지만, 이후 유지보수가 훨씬 편합니다. 트리거 조건을 바꾸려고 코드를 다시 배포할 필요가 없습니다.

GTM으로 GA4 이벤트 설정하기: 네 단계

“블로그 글 읽기 완료” 행동을 추적한다고 가정해 보겠습니다. 전체 흐름은 다음과 같습니다.

1단계: GA4 Event Tag 만들기

GTM을 열고 새 Tag를 만든 뒤 유형으로 Google Analytics: GA4 Event를 선택합니다. Measurement ID를 입력하고 이벤트 이름에는 article_read_complete를 넣습니다.

2단계: Trigger 설정하기

이 단계는 GTM에 “언제 이 이벤트를 발생시킬지” 알려주는 과정입니다.

“읽기 완료”에는 보통 스크롤 트리거를 씁니다. 사용자가 페이지의 90% 지점까지 스크롤하면 발생하도록 합니다. 새 Trigger를 만들고 유형은 Scroll Depth, Vertical Scroll Depths는 90%로 설정합니다.

하지만 세부적으로 주의할 점이 있습니다. 블로그에 “읽기 진행률 바” 같은 기능이 있다면 GTM의 스크롤 추적과 충돌할 수 있습니다. 저도 이 문제를 겪었습니다. 페이지 상단에 진행률 바가 있었고, 그 결과 스크롤 이벤트가 과도하게 발생해 데이터가 잡음으로 가득 찼습니다. 해결책은 제한 조건을 추가하는 것입니다. 같은 사용자가 같은 글에서 한 번만 트리거되게 만드세요.

3단계: Event Parameters 추가하기

매개변수는 이벤트의 “영혼”입니다. 누군가 글을 끝까지 읽었다는 사실만으로는 부족합니다. 어떤 글인지, 어떤 카테고리인지, 작성자가 누구인지 알아야 합니다.

Tag 설정에 Event Parameters를 추가합니다.

매개변수 이름	값	설명
article_title	{{Page Title}}	글 제목
article_category	{{Custom JS Variable}}	글 카테고리(직접 JS로 추출 필요)
reading_time	{{Custom JS Variable}}	예상 읽기 시간

매개변수 값의 타입은 일관되게 유지해야 합니다. reading_time에 숫자를 넣었다면 계속 숫자로 넣으세요. 어떤 때는 5, 어떤 때는 "5분"을 넣으면 GA4는 이것을 서로 다른 매개변수처럼 처리합니다.

4단계: Debug 검증하기

설정을 마쳤다고 바로 배포하지 마세요. GTM의 Preview 모드로 테스트합니다. 블로그 페이지를 열고 90%까지 스크롤한 뒤 GA4 DebugView에 이벤트가 들어오는지 확인하세요.

DebugView는 GA4 관리자 화면의 Configure > DebugView에서 열 수 있습니다. 이벤트가 보이지 않는다면 Trigger 조건이 잘못됐는지 확인하세요. 이벤트는 들어오는데 매개변수 값이 없다면 Variable 설정을 확인해야 합니다.

GTM을 쓰고 싶지 않다면? gtag.js로 직접 설정하기

블로그가 Astro나 Hugo 같은 정적 생성기를 쓰고 있고 GTM의 복잡성을 들이고 싶지 않다면 gtag.js 코드를 직접 작성해도 됩니다.

// 페이지 로드 완료 후 실행
window.addEventListener('load', function() {
  // 90%까지 스크롤하면 트리거
  window.addEventListener('scroll', function() {
    var scrollPercent = (window.scrollY / (document.body.scrollHeight - window.innerHeight)) * 100;
    if (scrollPercent >= 90 && !window.articleReadTracked) {
      window.articleReadTracked = true;
      gtag('event', 'article_read_complete', {
        'article_title': document.title,
        'article_category': document.querySelector('meta[name="category"]')?.content || 'unknown',
        'reading_time': parseInt(document.querySelector('meta[name="reading-time"]')?.content || 0)
      });
    }
  });
});

이 코드는 GTM 설정과 같은 일을 합니다. 사용자가 90%까지 스크롤하면 article_read_complete 이벤트를 보냅니다. 차이는 코드가 페이지에 고정되어 있어서 나중에 수정하려면 다시 배포해야 한다는 점입니다.

흔한 함정들(전부 제가 밟아본 것들입니다)

함정 1: 이벤트 이름이 규칙에 맞지 않음

articleReadComplete, article-read-complete, article_read_complete. 이 세 가지는 GA4에서 서로 다른 이벤트입니다. 모두 snake_case로 통일하고 Google 공식 방식과 맞추는 것을 권합니다.

함정 2: 매개변수 값 타입이 일관되지 않음

오늘은 reading_time: 5, 내일은 reading_time: "5 minutes", 모레는 reading_time: true를 보낸다면 GA4는 이것을 세 개의 다른 매개변수처럼 다룹니다. 보고서가 금방 엉망이 됩니다.

함정 3: Consent Mode v2 때문에 이벤트가 필터링됨

웹사이트가 EU 사용자를 대상으로 하고 Google Consent Mode v2를 켰다면, 사용자가 Cookie를 거부할 때 일부 이벤트가 전송되지 않을 수 있습니다. 이것은 오류가 아니지만 보고서 데이터가 “줄어듭니다”. 설정 문제라고 바로 단정하지 마세요.

함정 4: 이벤트 이름과 매개변수 이름에 예약어를 사용함

page_view, session_start, first_visit는 GA4의 예약 이벤트 이름입니다. 맞춤 이벤트 이름으로 쓰지 마세요. 매개변수 이름에도 예약어 목록이 있으니 설정 전에 공식 문서를 확인하는 것이 좋습니다.

블로그 사이트 실전 예시

블로그 상황에 맞춰 자주 쓰는 이벤트 설정을 정리해보면 다음과 같습니다.

행동	이벤트 이름	핵심 매개변수
글 읽기 완료	article_read_complete	article_title, category, author
댓글 제출	comment_submit	article_title, comment_length
구독 버튼 클릭	newsletter_click	button_location, article_title
목차 내비게이션 클릭	toc_click	section_title, article_title

이 이벤트들을 설정하면 GA4에서 사용자가 블로그에서 실제로 어떤 행동을 하는지 볼 수 있습니다. 다음 단계는 이 행동 데이터를 분석하는 것입니다. 여기서 전환 퍼널이 필요합니다.

3. 전환 퍼널 설정과 분석

이벤트 추적을 설정했다면 이제 핵심 질문에 답해야 합니다. 사용자가 “처음 방문”한 뒤 “내가 원하는 목표 행동”을 완료하기까지 중간에서 얼마나 이탈할까요?

전환 퍼널이 해결하는 문제가 바로 이것입니다.

GA4의 Funnel Exploration 보고서는 UA보다 훨씬 강력합니다. UA의 퍼널 보고서는 고정적이고 딱딱했지만, GA4에서는 각 단계를 직접 정의하고 세그먼트 비교를 추가하며 이탈 시간을 분석할 수 있습니다. 유료 도구의 기능을 무료 버전 안으로 옮겨온 느낌입니다.

첫 전환 퍼널 만들기

GA4를 열고 Explore > Funnel Exploration으로 이동합니다. 빈 퍼널 템플릿이 보일 것입니다.

첫 번째 단계는 “퍼널 단계”를 정의하는 것입니다. 최대 10단계까지 정의할 수 있지만, 실제로 블로그 사이트에서는 보통 4-5단계면 충분합니다.

블로그 구독 퍼널을 예로 들어보겠습니다.

1. 1단계: 글 페이지 조회(event: page_view, 조건: page_location에 /posts/ 포함)
2. 2단계: 구독 페이지 방문(event: page_view, 조건: page_location에 /subscribe 포함)
3. 3단계: 구독 양식 제출(event: newsletter_signup)
4. 4단계: 확인 메일 열람(event: email_opened). 이 단계는 이메일 시스템의 추적 설정이 필요합니다.

단계를 정의할 때 한 가지 요령이 있습니다. 각 단계의 조건을 최대한 단순하고 명확하게 만드세요. 조건 조합이 복잡해질수록 퍼널 데이터 해석도 어려워집니다.

퍼널 분석: 이탈 지점 찾기

퍼널을 설정하면 각 단계의 전환율과 이탈 사용자 수를 볼 수 있습니다.

제 블로그 구독 퍼널 데이터가 다음과 같다고 가정해 보겠습니다.

단계	사용자 수	전환율(이전 단계 기준)
글 페이지 조회	10000	-
구독 페이지 방문	800	8%
구독 양식 제출	240	30%
확인 메일 열람	180	75%

한눈에 보입니다. 첫 번째 이탈 지점은 “글 페이지 → 구독 페이지”입니다. 사용자의 8%만 구독 페이지로 이동합니다. 이는 구독 진입점이 충분히 눈에 띄지 않거나, 구독 페이지로 들어가는 위치가 적절하지 않다는 뜻일 수 있습니다.

두 번째 이탈 지점은 “구독 페이지 → 양식 제출”입니다. 전환율은 30%입니다. 양식이 너무 길거나, 구독의 가치가 충분히 명확하지 않을 수 있습니다.

이탈 지점을 찾았다면 다음 단계는 세그먼트 데이터를 비교해 이탈에 패턴이 있는지 보는 것입니다.

세그먼트 비교: “누가” 이탈하는지 찾기

Funnel Exploration은 세그먼트를 추가해 서로 다른 사용자 그룹의 전환 차이를 비교할 수 있습니다.

자주 쓰는 세그먼트 차원은 다음과 같습니다.

• 신규 사용자 vs 재방문 사용자: 신규 사용자는 보통 전환율이 더 낮습니다. 아직 콘텐츠 가치를 잘 모르기 때문입니다.
• 모바일 vs PC: 모바일에서는 양식 입력 경험이 더 나쁜 경우가 많습니다.
• 유입 채널: 검색엔진에서 온 사용자 vs 소셜 미디어에서 온 사용자

예를 들어 신규 사용자와 재방문 사용자의 구독 퍼널을 비교해 보겠습니다.

단계	신규 사용자 전환율	재방문 사용자 전환율
글 페이지 → 구독 페이지	5%	15%
구독 페이지 → 양식 제출	25%	40%

재방문 사용자는 모든 단계에서 전환율이 더 높습니다. 자연스러운 결과입니다. 이미 콘텐츠 가치를 인정했기 때문입니다. 하지만 신규 사용자의 “글 페이지 → 구독 페이지” 전환율은 5%에 불과합니다. 신규 사용자가 구독 진입점을 거의 보지 못한다는 뜻입니다.

이 발견을 바탕으로 저는 글 마지막에 눈에 잘 띄는 구독 카드를 추가했습니다. 신규 사용자 전환율은 5%에서 12%로 올랐습니다.

Open Funnel: 사용자 경로의 다양성 분석하기

Funnel Exploration의 기본값은 “선형 퍼널”입니다. 사용자가 순서대로 각 단계를 완료해야 전환으로 집계됩니다.

하지만 실제 사용자 행동은 그렇게 얌전하지 않습니다. 어떤 사용자는 구독 페이지를 건너뛰고 글 하단에서 바로 구독을 제출합니다. 어떤 사용자는 확인 메일을 연 뒤 다시 글 페이지로 돌아와 한 번 더 읽기도 합니다.

GA4는 “Open Funnel” 모드를 제공합니다. 순서를 강제하지 않고, 사용자가 어떤 단계를 완료하기만 하면 그 단계에 진입한 것으로 계산합니다.

Open Funnel은 “비정형 경로”를 찾는 데 도움이 됩니다. 예를 들어 구독 사용자의 15%가 전용 구독 페이지를 거치지 않고 글 하단에서 바로 제출했다는 사실을 발견할 수 있습니다. 이것은 글 하단의 구독 진입점이 전용 구독 페이지보다 더 효과적이라는 뜻입니다. 그렇다면 구독 페이지보다 글 하단 구독 경험을 조정하는 데 더 많은 노력을 써야 합니다.

퍼널 분석의 흔한 오해

오해 1: 최종 전환율만 본다

첫 단계에서 마지막 단계까지의 “전체 전환율”도 물론 중요합니다. 하지만 개선의 핵심은 중간 단계의 이탈 지점입니다. “1.8%의 사용자가 구독을 완료했다”만 보지 말고, “어느 단계에서 92%의 사용자가 이탈했는지”를 봐야 합니다.

오해 2: 시간 차원을 무시한다

Funnel Exploration에서는 “전환 시간”을 설정할 수 있습니다. 사용자가 첫 단계에서 마지막 단계까지 가는 데 얼마나 걸렸는지를 보는 기능입니다. 퍼널이 “읽기 → 주문 → 결제”라면, 사용자가 읽기에서 결제까지 7일이 걸렸다는 것은 의사결정 주기가 길다는 뜻입니다. 신뢰 형성을 강화하거나 결제 유도 접점을 늘릴 필요가 있을 수 있습니다.

오해 3: 데이터가 너무 적은데 분석한다

퍼널 분석에는 충분한 데이터량이 필요합니다. 어떤 단계에 사용자가 수십 명뿐이라면 전환율 변동이 커서 결론이 신뢰하기 어렵습니다. 수백 명 이상의 데이터가 쌓인 뒤 깊게 분석하는 것을 권합니다.

4. BigQuery 데이터 내보내기 실전

앞에서 다룬 내용은 모두 GA4 화면 안에서 하는 작업입니다. 하지만 GA4 기본 보고서에는 제한이 있습니다. 데이터량이 클 때 샘플링이 발생할 수 있습니다. 예를 들어 블로그 월간 활성 사용자가 50만 명이라면 GA4 보고서는 10% 데이터 샘플만으로 만들어질 수 있습니다.

샘플링이 나쁜 것은 아닙니다. 보고서 로딩 속도를 높여줍니다. 하지만 정확한 전환율 분석을 해야 하거나, 10개가 넘는 차원을 조합해 데이터를 봐야 한다면 샘플링 결과는 믿기 어려워집니다.

이럴 때 BigQuery 내보내기가 구원투수입니다.

BigQuery 내보내기 설정: 세 단계로 끝내기

BigQuery는 Google의 데이터 웨어하우스 서비스입니다. GA4 데이터를 BigQuery로 내보내면 SQL로 전체 데이터를 조회할 수 있고 샘플링 제한을 받지 않습니다.

설정 단계는 간단합니다.

1단계: BigQuery 프로젝트 만들기

Google Cloud Console에서 프로젝트를 만들고 BigQuery API를 활성화합니다. 신규 사용자에게는 무료 한도가 있습니다. 매월 10GB 저장소와 1TB 쿼리 처리량이면 블로그 사이트에는 충분합니다.

2단계: GA4에서 내보내기 설정하기

GA4 Admin을 열고 BigQuery Linking을 찾습니다. Link를 클릭하고 BigQuery 프로젝트를 선택한 뒤 내보내기 빈도를 고릅니다.

• Daily: 전날 데이터를 하루 한 번 내보냅니다.
• Streaming: 실시간 내보내기입니다. 몇 시간 안에 당일 데이터를 볼 수 있습니다.

저는 둘 다 켜는 것을 추천합니다. Daily 내보내기는 데이터 구조가 더 안정적이라 장기 분석에 적합하고, Streaming 내보내기는 당일 실시간 데이터를 보는 데 좋습니다.

3단계: 데이터가 흐르기 시작할 때까지 기다리기

설정을 마치면 GA4는 24시간 이내 BigQuery로 데이터를 내보내기 시작합니다. 다만 중요한 함정이 있습니다. BigQuery 내보내기에는 과거 데이터 소급 적재가 없습니다. 오늘 설정하면 오늘부터의 데이터만 받을 수 있고, 지난 2년의 GA4 데이터가 자동으로 들어오지는 않습니다.

따라서 깊은 분석이 필요하다면 BigQuery 내보내기를 최대한 일찍 설정하세요. 과거 데이터가 필요해진 뒤에야 발견하면 이미 늦습니다.

BigQuery 데이터 구조: 한눈에 이해하기

GA4가 BigQuery로 내보낸 데이터는 하루에 하나의 테이블로 저장됩니다. 테이블 이름 형식은 events_YYYYMMDD입니다. 예를 들어 events_20260429에는 2026년 4월 29일의 이벤트 데이터가 들어 있습니다.

각 기록은 하나의 이벤트이며, 필드는 다음과 같습니다.

필드	설명
event_name	이벤트 이름(예: page_view, article_read_complete)
event_timestamp	이벤트 발생 시간(마이크로초 단위 Unix 타임스탬프)
user_pseudo_id	사용자 익명 ID(동일 사용자의 교차 기기 식별)
event_params	이벤트 매개변수(중첩 구조라 SQL로 펼쳐야 함)
geo	지리 정보(국가, 도시)
device	기기 정보(브라우저, 운영체제, 기기 유형)

초보자가 자주 막히는 지점이 있습니다. event_params는 단순한 열이 아니라 중첩 필드입니다. 매개변수 값을 조회하려면 UNNEST로 펼쳐야 합니다.

실용적인 SQL 쿼리 몇 가지

특정 이벤트의 사용자 수 조회하기:

SELECT
  COUNT(DISTINCT user_pseudo_id) as unique_users
FROM `your-project.analytics_123456789.events_*`
WHERE event_name = 'article_read_complete'
  AND _TABLE_SUFFIX BETWEEN '20260401' AND '20260429'

이 SQL은 4월에 글 읽기를 완료한 순 사용자 수를 계산합니다.

특정 이벤트 매개변수의 분포 조회하기:

SELECT
  param.value.string_value as article_category,
  COUNT(DISTINCT user_pseudo_id) as users
FROM `your-project.analytics_123456789.events_*`,
UNNEST(event_params) as param
WHERE event_name = 'article_read_complete'
  AND param.key = 'article_category'
  AND _TABLE_SUFFIX BETWEEN '20260401' AND '20260429'
GROUP BY article_category
ORDER BY users DESC

이 SQL은 event_params를 펼쳐서 글 카테고리별 읽기 완료 사용자 수를 집계합니다.

BigQuery vs GA4 기본 보고서: 언제 무엇을 쓸까?

상황	GA4 기본 보고서 사용	BigQuery 사용
일별 트래픽 빠르게 확인	예	-
전환 퍼널 보기	예	-
4개를 넘는 차원을 조합해 분석	-	예
전환율을 정확히 계산(샘플링 없음)	-	예
다른 도구로 데이터 내보내기(Looker, Python)	-	예
실시간 모니터링(당일 데이터)	예(Streaming)	예(Streaming)

간단히 말해 일상적인 보고서 확인은 GA4 화면에서 하고, 깊은 분석은 BigQuery로 하면 됩니다.

BigQuery 비용 관리

BigQuery는 쿼리가 처리한 데이터량 기준으로 과금됩니다. 블로그 사이트는 데이터량이 크지 않아 보통 비용이 통제 가능하지만, 몇 가지 절약 팁은 알아두는 것이 좋습니다.

1. _TABLE_SUFFIX로 날짜 범위를 제한하기: 전체 테이블을 조회하지 말고 필요한 날짜만 조회하세요.
2. WHERE 조건으로 필터링하기: 가능한 한 일찍 필터링할수록 처리 데이터가 줄어듭니다.
3. 물리화 뷰 만들기: 자주 조회하는 데이터는 미리 집계해둘 수 있습니다.

제 블로그의 월 데이터량은 대략 1GB이고 쿼리량은 월 100GB를 넘지 않습니다. 무료 한도 안에 충분히 들어옵니다. 큰 사이트라면 비용을 신경 써야 하지만, 중소형 블로그라면 걱정하지 않아도 됩니다.

5. GA4 vs UA: 이전 사용자가 반드시 알아야 할 차이

UA에서 넘어온 오래된 사이트 운영자라면 이 장은 특히 중요합니다.

GA4와 UA의 차이는 화면만 바뀐 정도가 아닙니다. 기본 로직이 완전히 달라졌습니다. UA에서 “당연하다”고 여겼던 많은 개념이 GA4에는 없거나 정의가 바뀌었습니다.

이벤트 모델 vs 세션 모델

UA의 핵심은 “세션”입니다. 사용자가 방문하고, 둘러보고, 떠납니다. 이것이 하나의 세션입니다. 하나의 세션 안에는 여러 페이지 조회와 여러 이벤트가 있을 수 있습니다.

GA4의 핵심은 “이벤트”입니다. 각 사용자 행동이 독립적인 원자 단위입니다. 세션은 분석의 출발점이 아니라 이벤트의 묶음이 되었습니다.

이것은 무엇을 의미할까요?

UA에서는 “세션 수”, “세션당 페이지 조회 수”를 보는 데 익숙했을 것입니다. GA4에서는 이런 개념이 “이벤트 수”, “사용자 수”로 대체됩니다.

GA4에도 여전히 “세션” 개념은 있습니다. 다만 세션보다 “사용자 여정”을 더 강조합니다. 한 사용자가 오전에 블로그를 열고 오후에 다시 돌아올 수 있습니다. UA에서는 두 개의 세션이지만, GA4에서는 한 사용자의 여러 번의 방문으로 이해하는 쪽에 가깝습니다.

Engagement Rate vs Bounce Rate

UA의 “이탈률”(Bounce Rate)은 많은 사이트 운영자가 집착하던 지표였습니다. 이탈률이 낮을수록 사용자를 잘 붙잡았다고 봤습니다.

하지만 GA4에서는 이탈률이 사라졌습니다. 대신 “참여율”(Engagement Rate)이 생겼습니다.

왜일까요? UA의 이탈률 정의에는 문제가 있었습니다. 사용자가 한 페이지만 보고 떠나면 “이탈”로 계산됩니다. 그런데 사용자가 한 페이지만 보더라도 10분 동안 머물며 글을 진지하게 끝까지 읽었다면 어떨까요? UA는 여전히 이것을 “이탈”로 계산합니다.

GA4의 참여율 정의는 더 합리적입니다. 사용자가 사이트에 10초 넘게 머물렀거나, 최소 하나의 전환 이벤트가 발생했거나, 2개를 넘는 페이지를 봤다면 “참여”로 계산합니다. 참여율 = 참여 세션 / 전체 세션 수입니다.

따라서 GA4의 참여율과 UA의 이탈률을 직접 비교하지 마세요. 두 지표는 반대 개념이 아니라 서로 다른 측정 기준입니다.

Data Streams vs Views

UA에는 “보기”(Views) 개념이 있었습니다. 여러 보기를 만들고 각 보기에 서로 다른 필터를 적용할 수 있었습니다. 예를 들어 한 보기는 국내 트래픽만 보고, 다른 보기는 내부 IP를 제외하는 식입니다.

GA4에는 View가 없습니다. 대신 “데이터 스트림”(Data Streams)이 있습니다. Web, iOS App, Android App 각각 하나의 데이터 스트림을 둡니다.

그렇다면 필터 기능은 어떻게 할까요? GA4는 “Property Filters”로 대체합니다. 하지만 UA의 View 필터보다 기능이 훨씬 약합니다. 내부 트래픽과 스팸 트래픽 정도만 필터링할 수 있고, UA처럼 서로 다른 데이터를 보는 여러 View를 만들 수 없습니다.

UA의 View로 다차원 데이터 분리를 해왔다면 GA4로 이전한 뒤 데이터 구조를 다시 설계해야 합니다. BigQuery로 내보낸 뒤 직접 필터링하거나, Looker Studio에서 여러 보고서 보기를 만드는 방식이 필요합니다.

UA Goal은 다시 매핑해야 한다

UA의 “목표”(Goals)는 GA4에서 “전환 이벤트”(Conversion Events)가 되었습니다.

설정 방식도 바뀌었습니다. UA Goal은 “특정 페이지 방문”, “X분 이상 체류”, “특정 이벤트 발생”처럼 설정할 수 있었습니다. GA4의 전환 이벤트는 “어떤 이벤트가 발생함”만 가능합니다. 페이지 방문을 전환으로 추적하고 싶다면 먼저 page_view 이벤트를 설정하고, 그 page_view를 전환으로 표시해야 합니다.

이전할 때는 UA Goals를 하나씩 나열한 뒤 GA4의 전환 이벤트로 다시 매핑하세요. 번거롭지만 꼭 필요한 과정입니다. 그렇지 않으면 과거 전환 데이터의 흐름을 이어가기 어렵습니다.

마무리

길게 이야기했지만 핵심은 네 가지입니다.

1. 이벤트 추적: 세 가지 유형(자동, 추천, 맞춤)을 이해하고 우선순위에 따라 설정합니다.
2. 전환 퍼널: 이탈 지점을 찾고, 세그먼트 데이터를 비교하며, Open Funnel로 비정형 경로를 발견합니다.
3. BigQuery 내보내기: 깊은 분석이 필요하다면 일찍 설정하세요. 과거 데이터는 소급해서 채울 수 없습니다.
4. 이전 관점: UA의 지표를 GA4에 억지로 끼워 맞추지 말고 새 로직에 적응해야 합니다.

이 글을 읽고 바로 한 가지를 한다면, GA4를 열어 Enhanced Measurement가 켜져 있는지 확인한 뒤 3-4단계짜리 전환 퍼널을 만들어 블로그 구독 흐름을 분석해보는 것을 추천합니다.

데이터가 스스로 답을 말해주지는 않습니다. 하지만 문제가 어디에 있는지는 알려줍니다. 남은 일은 그 문제를 해결할 방법을 찾는 것입니다.

---

참고 자료

• Set up events | Google Analytics | Google for Developers - GA4 공식 이벤트 설정 문서
• Recommended events - Analytics Help - 추천 이벤트 목록
• Enhanced measurement events - Analytics Help - 자동 이벤트 설명
• Funnel Exploration Report in GA4 - Analytics Mania - 퍼널 보고서 상세 설명
• GA4 BigQuery Export Schema Tutorial - Optimize Smart - BigQuery 내보내기 튜토리얼