GA4 이벤트 매개변수는 어떻게 설계해야 할까?

앞 글에서는 이벤트 이름을 어떻게 정할지 살펴봤습니다.

이번 글에서는 GA4 이벤트 매개변수 설계, 즉 GA4 event parameter를 어떻게 잡을지 봅니다.

나쁜 구조는 예를 들면 이렇습니다.

homepage_consultation_click
footer_consultation_click
product_consultation_click

개선 구조는 이렇습니다.

consultation_click
+
cta_location

핵심 원칙은 간단합니다.

이벤트 = 어떤 행동이 일어났는가
매개변수 = 그 행동의 세부 정보

예를 들면 consultation_click에 cta_location = homepage_top을 붙입니다.

위치나 상품, 캠페인 같은 값을 이벤트 이름에 계속 붙이지 말고, 변하는 상세 정보는 매개변수로 분리하세요.

이것이 GA4 이벤트 설계에서 이름과 세부 정보를 나누는 기본입니다.

1. 이벤트 매개변수란 무엇일까?

이벤트 매개변수(Event parameter)는 이벤트가 발생했을 때 함께 보내는 추가 정보입니다.

쉽게 보면 이렇습니다.

이벤트 = 무슨 일이 발생?
매개변수 = 어디서 / 어떻게 / 무엇과 관련?

기초 개념은 앞 PART의 매개변수 글에서 이미 다뤘습니다. 이번 글은 실제로 어떻게 설계할지에 집중합니다.

2. 왜 매개변수가 필요할까?

예를 들어 file_download만 있으면, 다운로드가 발생했다는 사실은 알 수 있습니다.

하지만 어떤 파일인지, 어떤 맥락인지까지 보려면 추가 정보가 필요할 수 있습니다.

행동이 “일어났다”는 사실과, 그 행동을 “어떻게 분석할지”는 다릅니다.

3. 이벤트 이름과 매개변수 역할 분리

역할을 이렇게 나누세요.

event name = 행동
parameter = 변하는 세부 정보

서비스가 커져도 이벤트 이름 수가 불필요하게 늘어나지 않게 하는 원칙입니다.

같은 CTA인데 위치만 다르다면, 이름을 계속 늘리기보다 매개변수를 먼저 검토하세요.

4. 값이 계속 바뀌는 정보는 parameter로 검토

예를 들면 이런 정보입니다.

CTA 위치
콘텐츠 종류
서비스 유형
상품 관련 정보

값이 자주 바뀌는 정보는 GA4 custom parameter 후보로 보면 됩니다.

단, Google 표준 이벤트나 표준 매개변수가 있다면 그걸 우선 사용하세요.

5. 같은 의미에는 같은 parameter name

나쁜 예입니다.

location
button_location
cta_position

같은 의미라면 한 이름으로 통일하세요.

이름이 흩어지면, 나중에 합쳐서 보기 어렵습니다.

6. 너무 모호한 이름 피하기

피할 예입니다.

type
name
data

맥락이 보이도록 쓰는 편이 낫습니다.

consultation_type
cta_name
service_category

너무 길지 않으면서도, 이름만 보고 의미를 알 수 있어야 합니다.

7. 너무 긴 parameter name도 피하기

나쁜 예입니다.

consultation_button_location_on_current_page

더 단순한 예입니다.

cta_location

짧지만 의미를 알 수 있게 정하세요.

8. 값의 표현도 통일

나쁜 예입니다.

homepage
home
Home
main
메인

같은 의미라면 같은 값을 쓰세요.

이름만 통일하고 값이 흩어지면, 보고서에서 숫자가 갈라집니다.

9. 대소문자도 일관되게

직접 정의하는 값은 하나의 convention을 유지하세요.

예를 들면 이렇습니다.

analytics
marketing
crm

어떤 형식이 절대 정답인지보다, 팀 안에서 일관되게 쓰는 것이 중요합니다.

10. 같은 뜻을 여러 값으로 만들지 않기

예를 들어 아래가 모두 “무료 상담”을 뜻한다면 문제입니다.

free
free_consultation
consultation_free

같은 의미가 여러 값으로 분리되지 않게 관리하세요.

11. 화면 문구와 분석용 값을 분리할 수 있음

버튼 문구가 지금 무료 상담 신청하기여도, 분석용 식별값은 free_consultation처럼 안정적으로 유지할 수 있습니다.

화면 문구는 나중에 바뀔 수 있습니다.

분석용 값은 오래 유지할 수 있는 식별값으로 두는 편이 낫습니다.

12. URL 전체를 무조건 custom parameter로 만들지 않기

페이지 관련 정보는 GA4가 이미 제공하는 경우가 많습니다. 먼저 확인하세요.

URL에는 query, 검색어, 사용자 입력값이 들어갈 수 있습니다.

불필요한 고유값이 늘어나고, 개인정보가 섞일 위험도 있습니다.

13. 값 종류가 지나치게 많아지는지 생각

예를 들면 이런 값입니다.

user_id
order_id
search keyword
full URL

고유값이 매우 많은 정보가 항상 나쁜 것은 아닙니다.

다만 보고서 분류용 측정기준처럼 무조건 쓰려고 하면, 관리와 분석이 어려워질 수 있습니다.

쉽게 말하면, 값이 너무 제각각이면 “분류해서 비교하기”가 힘들어집니다.

세부 제한은 뒤 글이나 별도 주제에서 이어가면 됩니다.

14. 매개변수를 많이 만든다고 좋은 것은 아님

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

button_color
button_size
text_length

실제 분석 질문이 없다면 수집하지 않는 편이 낫습니다.

핵심 질문은 이것입니다.

이 값으로 어떤 결정을 할 것인가?

15. GA4가 이미 제공하는 정보인지 먼저 확인

page, device, source처럼 GA4 기본 정보와 겹치는 custom parameter를 무작정 만들지 마세요.

이미 있는 정보를 다시 보내면, 관리만 복잡해질 수 있습니다.

16. Google 표준 parameter 우선

예를 들어 purchase라면, Google이 권장하는 구조를 먼저 봅니다.

transaction_id
value
currency
items

직접 order_total, payment_amount 같은 이름을 새로 만들기 전에 표준을 확인하세요.

전자상거래 구현 상세는 뒤 PART에서 다룹니다.

17. 하나의 parameter name은 하나의 의미

예를 들어 source를 어떤 곳에서는 페이지 위치, 다른 곳에서는 유입 source 의미로 쓰지 마세요.

핵심은 이렇습니다.

하나의 이름 = 하나의 의미

이름이 같아도 의미가 다르면, 분석이 바로 흔들립니다.

18. 값의 타입도 목적에 맞게

금액이나 수량처럼 계산해야 하는 값과, category나 name처럼 분류할 값은 역할이 다릅니다.

Google 표준 매개변수의 타입 규칙이 있으면 그걸 우선하세요.

세부 타입 제한은 공식 기준을 확인한 뒤 적용하면 됩니다.

19. 값이 없다고 가짜 값 채우지 않기

무조건 아래처럼 채우지 마세요.

unknown
none
null
0

값이 없을 때 어떻게 둘지, 분석 의미에 맞게 정책을 정하세요.

없는 값을 가짜로 채우면, 나중에 “진짜 없음”과 “가짜로 채운 값”을 구분하기 어렵습니다.

20. 개인정보 주의

특히 아래 값은 GA4 매개변수로 임의 전송하지 마세요.

이메일
전화번호
이름
직접 식별 가능한 값

URL, 검색어, 폼 입력값에도 개인정보가 섞일 수 있습니다.

개인정보가 들어갈 가능성이 있으면, 보내기 전에 한 번 더 멈추세요.

21. 측정 계획에 parameter도 기록

매개변수는 머릿속에만 두지 말고 짧게 기록하세요.

사용자 행동	이벤트	매개변수	값 예시
상담 CTA 클릭	`consultation_click`	`cta_location`	homepage_top
데모 신청	`demo_request`	`service_category`	analytics
구매	`purchase`	Google 권장 매개변수	transaction_id, value 등

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

22. 새 parameter 전에 네 가지 정의

새 매개변수를 만들기 전에 아래를 정하세요.

이름
의미
들어갈 값
어떤 분석에 사용하는지

예를 들어 cta_location이라면 이렇습니다.

의미: CTA 위치
값: homepage_top, footer
분석: 위치별 클릭 비교

이 네 가지가 비어 있으면, 아직 만들 준비가 안 된 것입니다.

23. 맞춤 측정기준/맞춤 측정항목 소개

쉽게 보면 이렇습니다.

event parameter = 데이터를 보냄
custom dimension / custom metric = 수집한 데이터를 GA4 분석에서 활용하도록 등록하는 방법 중 하나

즉, 매개변수를 보냈다고 해서 바로 모든 보고서에서 편하게 쓸 수 있는 것은 아닐 수 있습니다.

GA4 맞춤 측정기준과 GA4 맞춤 측정항목의 상세는 뒤 글에서 이어갑니다.

24. 구현 후 실제 값 확인

DebugView 등으로 아래를 확인하세요.

매개변수가 있는가
예상한 값인가
undefined나 빈 값은 없는가
대소문자가 섞이지 않았는가
같은 의미가 여러 표현으로 오지 않는가

이름만 맞추고 끝내지 말고, 실제 값까지 확인하세요.

25. 자주 하는 실수

매개변수 설계에서 자주 하는 실수는 이렇습니다.

모든 정보를 이벤트 이름에 넣음
같은 의미의 매개변수를 여러 개 만듦
같은 값을 여러 표현으로 보냄
필요 없는 매개변수를 너무 많이 만듦
Google 표준을 확인하지 않음
개인정보를 전송함

좋은 매개변수는 많이 만드는 것이 아니라, 분석에 쓰는 정보를 일관되게 남기는 것입니다.

26. GA4 이벤트 매개변수를 설계할 때 확인할 9가지

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

실제 분석에 필요한가?
GA4가 이미 제공하는 정보인가?
Google 표준 parameter가 있는가?
event name보다 parameter가 적절한가?
이름만 보고 의미를 이해할 수 있는가?
같은 의미에 같은 parameter name을 쓰는가?
값 형식이 일관되는가?
값 종류가 불필요하게 폭증하지 않는가?
개인정보가 들어가지 않는가?

27. 좋은 매개변수 설계를 다시 정리하면

원칙	쉽게 이해하면
이벤트와 역할 분리	행동은 이벤트, 세부는 매개변수
Google 표준 우선	권장 매개변수부터 확인
하나의 이름, 하나의 의미	같은 이름을 다른 뜻으로 쓰지 않음
값 일관성	homepage와 home을 섞지 않음
필요한 정보만 수집	결정에 쓰일 값만
변하는 값 매개변수 분리	위치/유형/상품은 parameter
개인정보 주의	이메일/전화/이름 등 전송 금지

28. 정리

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

이벤트 = 행동
매개변수 = 상세 정보

설계 순서는 이렇습니다.

GA4 기본 정보 확인
→ Google 표준 확인
→ 실제 분석 필요성 확인
→ 이름/의미/값 형식 결정
→ 구현
→ 실제 값 검증

다음 글에서는 GA4 사용자 속성이 무엇인지 알아보겠습니다.