GA4 이벤트 이름은 어떻게 정해야 할까?

같은 회원가입 행동을 아래처럼 여러 이름으로 만들면 데이터가 갈라집니다.

signup
sign_up
register
join_member

숫자가 흩어지고, 어떤 이름을 봐야 하는지도 헷갈립니다.

이번 글에서는 GA4 이벤트 이름, 즉 GA4 event naming을 어떻게 정할지 봅니다.

핵심 흐름은 이렇습니다.

Google 추천 이벤트 확인
→ 기존 이벤트 확인
→ 행동의 의미 정의
→ 일관된 이름 선택
→ 세부 정보는 매개변수로 분리
→ 구현 전 최종 검토

이름을 아무렇게나 만들고 나중에 바꾸는 방식은 피하세요.

데이터가 쌓인 뒤 이름을 바꾸면, 과거와 이후가 서로 다른 이벤트로 나뉠 수 있습니다. 처음부터 오래 쓸 이름을 정하는 편이 낫습니다.

1. 가장 먼저 Google 추천 이벤트 확인

GA4 이벤트 이름을 직접 만들기 전에, 먼저 확인하세요.

Google이 이미 같은 의미의 추천 이벤트를 제공하는가?

예를 들면 이렇습니다.

sign_up
purchase

같은 의미라면 GA4 추천 이벤트 표준을 우선합니다.

GA4 custom event name을 새로 만들기 전에, 표준부터 보는 것이 GA4 이벤트 이름 규칙의 첫 단계입니다.

2. 이벤트 이름을 처음부터 잘 정해야 하는 이유

이벤트가 적을 때는 아무 이름이나 써도 괜찮아 보일 수 있습니다.

하지만 수십 개, 수백 개로 늘어나면 이런 문제가 커집니다.

의미 파악이 어려움
비슷한 이름이 중복됨
협업이 헷갈림
과거 데이터와 이후 데이터가 갈라짐
나중에 이름을 바꾸는 비용이 커짐

처음부터 오래 쓸 이름을 정하는 편이 안전합니다.

3. 이름만 봐도 행동이 보여야 한다

좋은 예:

consultation_submit

나쁜 예:

event_01
action_a
custom_event

핵심 질문은 이것입니다.

이름만 보고 어떤 행동인지 이해 가능한가?

4. 행동을 나타내는 단어 사용

예를 들면 이렇습니다.

consultation_submit
quote_request
demo_request

개념적으로는 대상이나 맥락과 행동이 보이면 좋습니다.

대상/맥락
+
행동

단, Google 추천 이벤트가 있으면 이 자체 규칙보다 Google 표준이 우선입니다.

5. 같은 프로젝트에서는 이름 순서 통일

일관된 예입니다.

consultation_submit
quote_request
demo_request

혼합된 예입니다.

submit_consultation
quote_request
request_demo

같은 의미 계열의 이름 순서를 계속 바꾸지 마세요.

6. 소문자와 밑줄 형태

맞춤 이벤트는 일관된 naming convention이 중요합니다.

추천하는 프로젝트 형식은 예를 들면 이렇습니다.

consultation_submit
quote_request
demo_request

아래처럼 혼용하지 마세요.

ConsultationSubmit
consultation-submit
consultation submit

lowercase_with_underscores 형태를 팀 규칙으로 두면 관리가 쉽습니다.

다만 Google 공식 추천 이벤트 이름은 그대로 최우선으로 유지하세요.

7. 같은 뜻에는 같은 단어

완료나 신청 관련 의미를 매번 아래처럼 제각각 쓰지 마세요.

complete
finish
done
success

어떤 영어 단어가 절대 정답이라고 단정할 필요는 없습니다.

중요한 것은 같은 의미를 같은 단어로 표현하는 일관성입니다.

8. 너무 긴 이벤트 이름 피하기

나쁜 예입니다.

homepage_top_blue_consultation_button_click

세부 정보는 GA4 event parameter로 분리할 수 있습니다.

예를 들면 이렇습니다.

cta_click
+
cta_name
cta_location

핵심은 이렇습니다.

이벤트 이름에는 핵심 행동
매개변수에는 변하는 상세 정보

매개변수 설계의 세부는 다음 글에서 다룹니다.

9. 버튼 위치마다 새 이벤트를 만들지 말자

아래처럼 위치마다 이름을 나누면 이벤트가 금방 늘어납니다.

homepage_consultation_click
footer_consultation_click
product_consultation_click

같은 의미라면 이런 구조를 검토하세요.

consultation_click
+
location parameter

서로 다른 행동 의미라면 분리해도 됩니다.

같은지 다른지는 실제 분석에서 구분할 필요가 있는지로 판단하세요.

10. 클릭과 완료는 다른 이벤트

예를 들면 아래 두 이름은 의미가 다릅니다.

consultation_click
consultation_submit

click은 버튼을 누른 행동입니다.

submit은 신청 제출이나 완료에 가까운 맥락입니다.

실제 발생 시점은 서비스 구현과 정의에 맞게 정확히 정해야 합니다.

11. 시도와 성공을 구분

결제 버튼 클릭과 실제 purchase는 다릅니다.

이벤트 이름을 만들기 전에 먼저 정의하세요.

이 이벤트가 시도인가, 성공인가?

시도인지 성공인지가 섞이면, 나중에 성과 해석이 어려워집니다.

12. 새 이벤트 전에 기존 이벤트 검색

이미 consultation_submit이 있는데 inquiry_complete를 새로 만들면, 같은 의미가 나뉠 수 있습니다.

새 이벤트를 만들기 전에 기존 측정 계획과 이벤트 목록을 확인하세요.

13. 비슷하지만 의미가 다르면 분리

반대로 아래처럼 실제 사업 의미가 다르면, 별도 이벤트가 적절할 수 있습니다.

consultation_submit
demo_request

핵심 질문은 이것입니다.

실제 분석에서 서로 다른 행동으로 구분할 필요가 있는가?

같으면 하나로 묶고, 다르면 분리하세요.

14. 이벤트 이름에 값 넣지 않기

아래처럼 값마다 새 이벤트를 만들지 마세요.

purchase_shoes
purchase_bag
purchase_hat

purchase와 item/category 관련 매개변수 구조를 우선 검토하세요.

Google 전자상거래 표준이 있으면 그것을 우선합니다.

15. 날짜나 캠페인을 이벤트 이름에 넣지 않기

나쁜 예입니다.

summer_2026_signup
instagram_august_click

캠페인이나 날짜가 바뀔 때마다 이벤트가 계속 늘어납니다.

행동 이벤트는 오래 유지하고, 캠페인 정보는 UTM이나 관련 측정기준으로 보는 편이 낫습니다.

16. 숫자 기반 이름 피하기

예를 들면 이렇습니다.

event_1
event_2
cta_01_click

UI가 바뀌거나 시간이 지나면 의미가 사라집니다.

행동 의미가 드러나는 이름을 쓰세요.

17. Google 예약 이름/접두어 확인

맞춤 이벤트를 만들기 전에는 Google 공식 문서에서 아래를 확인하세요.

reserved event names
reserved prefixes
event name limitations

GA4 이벤트 네이밍은 공식 제한과 예약 규칙을 따라야 합니다.

제한값이나 글자 수를 추측해서 외우기보다, 구현 전에 공식 문서를 확인하는 습관이 중요합니다.

18. 간단한 naming 규칙 문서화

복잡한 규칙을 수십 개 만들 필요는 없습니다.

예를 들어 아래 정도면 충분합니다.

Google 추천 이벤트 우선
맞춤 이벤트는 일관된 소문자 형식
단어 구분은 밑줄
이름만 보고 행동을 이해 가능
위치/캠페인/상품 등 상세값은 매개변수
같은 의미에 같은 단어

짧고 지키기 쉬운 규칙이 더 오래 갑니다.

19. 측정 계획에 이름 기록

이름만 머릿속에 두지 말고, 짧게 기록하세요.

사용자 행동	이벤트 이름	발생 시점	주요 매개변수
상담 신청 완료	`consultation_submit`	신청 저장 성공 후	상담 유형, 위치
데모 신청 완료	`demo_request`	신청 저장 성공 후	데모 유형
회원가입 완료	`sign_up`	가입 완료 후	가입 방식

Google 표준이 있는 sign_up은 그대로 사용합니다.

20. 이미 데이터가 쌓인 이름 변경은 신중

예를 들어 기존 consult_submit을 consultation_submit으로 바꾸면, 과거와 이후 데이터가 나뉠 수 있습니다.

“나중에 이름 고치자”보다, 구현 전에 검토하는 편이 안전합니다.

정말 바꿔야 한다면, 과거 데이터와 이후 데이터를 어떻게 볼지도 함께 계획하세요.

21. 자주 하는 실수

이벤트 이름을 정할 때 자주 하는 실수는 이렇습니다.

추천 이벤트를 확인하지 않음
같은 뜻을 여러 이름으로 만듦
페이지나 캠페인을 이름에 넣음
클릭과 완료를 섞어 봄
모든 세부 정보를 이벤트 이름에 넣음

좋은 이름은 길게 만드는 것이 아니라, 오래 유지할 수 있게 만드는 것입니다.

22. GA4 이벤트 이름을 정할 때 확인할 8가지

아래 여덟 가지를 먼저 확인하세요.

Google 추천 이벤트가 있는가?
같은 의미의 기존 이벤트가 있는가?
이름만 보고 행동을 이해할 수 있는가?
같은 의미에 같은 단어를 쓰는가?
이름 형식이 일관적인가?
변하는 세부 정보는 매개변수로 분리 가능한가?
클릭/완료/성공의 의미가 구분되는가?
구현 전 충분히 검토했는가?

23. 좋은 이벤트 이름을 다시 정리하면

원칙	예시
Google 표준 우선	`sign_up`, `purchase`
행동이 보이는 이름	`consultation_submit`
형식 일관성	`quote_request`, `demo_request`
상세 정보 매개변수 분리	`cta_click` + `cta_location`
같은 의미 하나의 이름	상담 완료는 한 이름만
오래 유지 가능한 이름	날짜/캠페인을 이름에 넣지 않음

24. 정리

한 번 더 정리하면 이렇습니다.

Google 추천 이벤트 확인
→ 기존 이벤트 확인
→ 행동 의미 정의
→ 일관된 이름
→ 상세 정보 매개변수 분리
→ 구현 전 검토

좋은 이벤트 이름은, 나중에 다시 봐도 이해되고 서비스가 커져도 유지 가능한 이름입니다.

데이터가 쌓인 뒤 rename하는 비용이 크므로, 처음부터 충분히 검토하세요.

다음 글에서는 GA4 이벤트 매개변수를 어떻게 설계해야 하는지 알아보겠습니다.