GA4 맞춤 이벤트란 무엇일까?

앞 글에서는 Google이 권장하는 추천 이벤트를 살펴봤습니다.

그렇다면 Google이 이미 정해 둔 이벤트로는 표현하기 어려운 서비스 고유 행동은 어떻게 측정할까요?

이때 쓰는 것이 GA4 맞춤 이벤트, 즉 GA4 custom event입니다.

핵심 흐름은 이렇습니다.

측정하고 싶은 행동
→ 자동 수집 여부 확인
→ 향상된 측정 여부 확인
→ 추천 이벤트 여부 확인
→ 그래도 없으면 맞춤 이벤트 검토

맞춤 이벤트는 처음부터 만드는 기본 선택이 아닙니다. 기존 GA4 표준으로 표현하기 어려울 때의 마지막 선택에 가깝습니다.

이번 글은 언제 맞춤 이벤트를 써야 하는가에 집중합니다. GTM이나 코드 구현 상세는 깊게 다루지 않습니다.

1. 맞춤 이벤트란 무엇일까?

맞춤 이벤트(Custom event)는 GA4가 기본 제공하는 구조만으로 정확히 표현하기 어려운 행동을, 서비스 목적에 맞게 직접 정의한 이벤트입니다.

쉽게 보면 이렇습니다.

자동 수집
→ 안 됨

향상된 측정
→ 안 됨

추천 이벤트
→ 정확히 맞는 것 없음

그다음에서야 맞춤 이벤트를 검토합니다.

이것이 GA4 이벤트 설계의 기본 순서입니다.

2. 어떤 행동이 맞춤 이벤트가 될 수 있을까?

예를 들면 이런 행동이 있습니다.

무료 상담 신청 완료
견적 요청 완료
데모 신청 완료
특정 서비스 고유 행동 완료

개념 예시 이름은 이렇습니다.

consultation_submit
quote_request
demo_request
feature_trial_complete

이 이름들은 설명용 예시입니다.

실제 사용 전에는 Google 추천 이벤트와 기존 측정 계획을 먼저 확인하세요.

3. 왜 맞춤 이벤트를 너무 빨리 만들면 안 될까?

같은 상담 행동도 팀마다 다른 이름을 만들 수 있습니다.

consultation_submit
consult_submit
contact_submit
inquiry_complete

이렇게 되면 이런 문제가 생깁니다.

어떤 이벤트를 봐야 하는지 헷갈림
과거 데이터와 현재 데이터가 갈라짐
협업 비용이 커짐
나중에 이름을 바꾸거나 다시 구현할 가능성이 커짐

그래서 맞춤 이벤트는 빨리 만들기보다, 정말 필요한지부터 확인하는 편이 낫습니다.

4. 맞춤 이벤트 전에 확인할 순서

아래 순서를 장기 운영 원칙으로 두세요.

자동 수집인가?
향상된 측정으로 가능한가?
추천 이벤트가 있는가?
그래도 없으면 맞춤 이벤트

처음부터 새 이름을 만들지 말고, GA4에 이미 있는 구조부터 확인하세요.

5. 추천 이벤트를 억지로 쓰면 안 된다

추천 이벤트를 우선 검토하는 것과, 의미가 다른데 비슷한 이름을 억지로 쓰는 것은 다릅니다.

핵심은 이것입니다.

추천 이벤트의 의미 = 실제 사용자 행동의 의미

같은지 판단하세요.

같다면 추천 이벤트를 쓰고, 다르다면 억지로 끼워 맞추지 마세요.

6. 맞춤 이벤트 이름은 행동이 보이게 만들자

좋은 예:

consultation_submit

나쁜 예:

event_01
button_action
custom_event

GA4 이벤트 이름만 보고도, 어떤 행동인지 이해할 수 있어야 합니다.

이름 규칙의 세부 사항은 다음 글에서 다룹니다. 지금은 “행동이 보이는 이름” 원칙만 기억하세요.

7. 이벤트 이름 형식을 일관되게 관리

나쁜 혼합 예입니다.

consultationSubmit
quote-request
demo_request

일관된 예입니다.

consultation_submit
quote_request
demo_request

같은 서비스 안에서는 형식을 통일하세요.

세부 naming 규칙은 다음 글에서 이어서 설명합니다.

8. 맞춤 이벤트에도 매개변수가 필요할 수 있다

예를 들어 consultation_submit이라면, 이런 추가 정보가 필요할 수 있습니다.

consultation_type
form_location
service_category

이것이 GA4 맞춤 이벤트 매개변수를 함께 설계하는 이유입니다.

이벤트 이름만 있고 세부 정보가 없으면, 나중에 “어디서, 어떤 상담이 들어왔는지”를 보기 어렵습니다.

9. 매개변수 이름도 아무렇게나 만들지 말자

같은 의미를 아래처럼 흩뜨리면 안 됩니다.

type
consult_type
consultation_type
request_type

한 의미를 한 이름으로 고정하세요.

Google 표준 매개변수가 있다면 그걸 먼저 검토합니다.

세부 매개변수 설계는 뒤 글에서 이어가면 됩니다.

10. 하나의 행동에는 하나의 대표 이벤트

상담 신청 1회에 아래를 전부 보내면 혼란이 커집니다.

consultation_submit
inquiry_complete
lead_created

핵심은 이렇습니다.

하나의 실제 의미 → 하나의 일관된 대표 이벤트

서로 다른 분석 목적이 있어 별도 이벤트가 필요한 경우도 있습니다.

다만 같은 의미를 여러 이름으로 중복 표현하는 것은 피하세요.

11. 클릭보다 결과를 측정해야 할 때가 많다

예를 들어 비교해 보세요.

consultation_button_click

과

실제 상담 신청 성공

사업 목적이 신청 완료라면, 버튼 클릭보다 성공 완료 이벤트가 더 중요할 수 있습니다.

클릭과 성공은 다른 행동입니다. 목적에 맞게 구분하세요.

12. 버튼마다 이벤트를 따로 만들 필요는 없다

아래처럼 무한히 나누지 마세요.

button_1_click
button_2_click
button_3_click

같은 의미의 CTA 행동이라면, 예를 들어 이런 구조도 고려할 수 있습니다.

cta_click
+
cta_name
cta_location

즉, 이벤트 하나와 매개변수로 구분하는 방식입니다.

물론 이미 맞는 표준이나 추천 이벤트가 있다면 그걸 먼저 봅니다.

13. 너무 세세한 이벤트를 만들지 말자

예를 들면 이런 것들입니다.

menu_open
menu_close
mouse_enter
mouse_leave
image_hover

필요할 수도 있지만, 마케팅이나 서비스 의사결정에 쓰이지 않으면 관리 부담만 커집니다.

핵심 질문은 이것입니다.

이 이벤트를 보고 어떤 결정을 할 것인가?

14. 코드보다 측정 계획 먼저

코드부터 만들지 말고, 의미와 이름부터 짧게 정리하세요.

사용자 행동	이벤트 이름	언제 발생	주요 정보
상담 신청 완료	`consultation_submit`	신청 저장 성공 후	상담 유형, 위치
견적 요청 완료	`quote_request`	요청 저장 성공 후	상품/서비스
데모 신청 완료	`demo_request`	신청 저장 성공 후	데모 유형

거대한 tracking spec을 처음부터 만들 필요는 없습니다.

중요 행동부터 정리하면 됩니다.

15. 발생 시점도 중요

상담 버튼 클릭 때 보내는 것과, 신청 저장 성공 후 보내는 것은 다릅니다.

실제 목적이 완료라면, 성공 확인 후 이벤트를 보내는 편이 더 적절할 수 있습니다.

GA4 이벤트 네이밍뿐 아니라, 발생 시점(firing moment)도 함께 설계하세요.

16. 중요한 이벤트 중복 주의

실제 상담 신청 1건인데 consultation_submit이 2번 오면 숫자가 부풀 수 있습니다.

특히 아래처럼 중요한 행동은 중복을 꼭 확인하세요.

상담
견적
회원가입
구매

한 번의 완료에 한 번만 오는지 확인하는 것이 기본입니다.

17. 맞춤 이벤트는 어디에서 만들 수 있을까?

구현 방식 예시는 이렇습니다.

웹사이트 코드
Google Tag Manager
GA4의 이벤트 관련 기능

Google Analytics 4 custom event는 여러 경로로 보낼 수 있습니다.

이번 글의 핵심은 구현법보다 설계 기준입니다.

어느 화면의 어떤 버튼을 누르는지까지 지금 고정해 외울 필요는 없습니다.

18. 이벤트를 보냈다고 일반 보고서 분석까지 끝난 것은 아니다

맞춤 매개변수를 일반 분석에 활용할 때는, 맞춤 측정기준이나 맞춤 측정항목 같은 추가 설정이 필요한 경우가 있습니다.

보내는 것과, 보고서에서 편하게 보는 것은 단계가 다를 수 있습니다.

상세는 뒤 글에서 이어갑니다.

19. 구현 후 테스트

예를 들어 상담 신청 1회를 테스트해 보세요.

확인할 항목은 이렇습니다.

올바른 시점인가
정확한 이벤트 이름인가
필요한 매개변수가 있는가
값이 맞는가
중복이 없는가

필요하면 DebugView로 빠르게 확인할 수 있습니다.

20. 자주 하는 실수

맞춤 이벤트를 만들 때 자주 하는 실수는 이렇습니다.

추천 이벤트 확인 없이 새 이름을 만듦
의미가 안 보이는 이벤트 이름을 씀
클릭과 완료를 섞어 봄
같은 행동을 여러 이름으로 만듦
필요 없는 이벤트를 너무 많이 만듦

좋은 GA4 이벤트 네이밍과 설계는, 새 이름을 많이 만드는 일이 아닙니다.

정말 필요한 행동만, 일관된 구조로 남기는 일입니다.

21. 맞춤 이벤트를 만들기 전에 확인할 7가지

아래 일곱 가지를 먼저 확인하세요.

자동 수집인가?
향상된 측정으로 가능한가?
추천 이벤트가 있는가?
정말 서비스 고유의 중요한 행동인가?
이름만 보고 의미를 알 수 있는가?
정확한 발생 시점이 정해졌는가?
구현 후 중복과 매개변수를 확인했는가?

22. 맞춤 이벤트를 다시 정리하면

개념	쉽게 이해하면
맞춤 이벤트	기존 표준으로 표현하기 어려운 행동을 직접 정의한 이벤트
이벤트 이름	어떤 행동인지 보이게 정한 이름
이벤트 매개변수	그 행동의 세부 정보
발생 시점	언제 이벤트를 보낼지
측정 계획	행동·이름·시점·정보를 먼저 정리한 표

핵심 순서는 이렇습니다.

자동 수집
→ 향상된 측정
→ 추천 이벤트
→ 맞춤 이벤트

23. 정리

맞춤 이벤트는 자유롭게 만들 수 있습니다. 하지만 처음부터 새 이벤트를 만드는 것이 좋은 것은 아닙니다.

순서는 이렇습니다.

GA4 기본 구조 확인
→ 향상된 측정 확인
→ 추천 이벤트 확인
→ 정말 없으면 맞춤 이벤트

맞춤 이벤트를 만들기로 했다면, 아래를 함께 설계하세요.

무엇을 측정할지
이름
발생 시점
매개변수
실제 데이터 검증

다음 글에서는 GA4 이벤트 이름을 어떻게 정해야 하는지 알아보겠습니다.