Key events & 퍼널
GA4 key event, create/modify event, funnel exploration을 비즈니스 전환 기준으로 설계하기
GA4의 key event는 비즈니스 성공에 중요한 행동을 표시하는 장치입니다. 모든 중요한 클릭을 key event로 만드는 것이 아니라, 후속 의사결정과 최적화에 직접 쓰는 성공 이벤트만 남겨야 합니다.
Key event 후보 판정
| 질문 | Yes면 key event 후보 |
|---|---|
| 이 행동이 매출, 리드, activation, retention과 직접 연결되는가? | 예 |
| 광고 최적화나 audience building에 써도 왜곡이 적은가? | 예 |
| 이벤트가 중복 발화되지 않도록 QA할 수 있는가? | 예 |
| 이벤트 이름과 파라미터가 6개월 뒤에도 같은 의미로 유지되는가? | 예 |
| 모든 page_view나 모든 click처럼 너무 넓은 이벤트는 아닌가? | 예 |
SaaS key event 기본 세트
| 단계 | 이벤트 | key event 여부 | 이유 |
|---|---|---|---|
| Acquisition | generate_lead | 선택 | B2B lead 품질 관리 |
| Signup | sign_up | 선택 | 가입을 성공 기준으로 보는 초기 제품 |
| Activation | activation_complete | 권장 | 제품 가치 경험의 핵심 |
| Revenue | purchase | 권장 | 매출 발생 |
| Retention | subscription_renew 또는 core_action_repeat | 선택 | 결제/반복 사용 모델에 따라 다름 |
| Expansion | plan_upgrade | 선택 | PLG/seat expansion 측정 |
Create vs Modify event
Google 공식 문서는 기존 이벤트가 거의 원하는 행동을 측정하지만 key event로 바로 쓰기 어렵다면 Analytics 안에서 event를 만들거나 수정할 수 있다고 설명합니다. 다만 modify는 기존 이벤트를 덮어쓰기 때문에 신중해야 합니다.
| 방법 | 언제 쓰나 | 예시 |
|---|---|---|
| Create event | 기존 이벤트를 보존하면서 조건에 맞는 새 이벤트 생성 | /thank-you page_view에서 lead_submit 생성 |
| Modify event | 기존 이벤트 자체를 보정 | 잘못된 parameter name 보정 |
| Code/GTM event | 제품 이벤트를 명확히 직접 발화 | activation_complete, checkout_start |
page_view를 직접 key event로 만들지 않기
특정 완료 페이지 방문을 전환으로 보고 싶다면 모든 page_view를 key event로 승격하지 말고, 조건 기반으로
thank_you_view나 lead_submit 같은 새 이벤트를 만든 뒤 key event로 표시합니다.
퍼널 설계
| 퍼널 | 단계 | 분석 질문 |
|---|---|---|
| Signup funnel | page_view → sign_up_start → sign_up | 가입 마찰은 어디에 있는가? |
| Activation funnel | sign_up → onboarding_complete → activation_complete | 신규 사용자가 가치 경험까지 가는가? |
| Lead funnel | pricing_view → demo_request → generate_lead | 어떤 세그먼트가 고품질 리드인가? |
| Checkout funnel | view_item → begin_checkout → purchase | 결제 이탈은 어느 단계인가? |
| Retention funnel | activation_complete → D7 core_action | 가치 경험이 반복되는가? |
Funnel parameter 기준
| 파라미터 | 목적 |
|---|---|
source / medium / campaign | 유입 맥락 |
plan | 요금제별 전환율 |
role | 사용자 역할별 activation |
segment | SMB/mid-market/enterprise 구분 |
variant | 실험/메시지/온보딩 버전 |
surface | landing, onboarding, app, billing 등 발생 위치 |
운영 루프
- key event 후보를 월 1회 검토합니다.
- 새 key event는 스테이징 또는 debug 환경에서 먼저 중복 발화를 확인합니다.
- key event 변경은 광고/리포트/audience 영향도를 기록합니다.
- 삭제 대신 archive 가능 여부를 먼저 확인합니다.
- 변경 후 24~48시간 동안 Realtime, DebugView, standard reports, BigQuery를 함께 확인합니다.