GA4 사용자 속성과 이벤트 매개변수는 무엇이 다를까?

앞 글에서는 GA4 사용자 속성이 무엇인지 살펴봤습니다.

이번 글에서는 GA4 사용자 속성 이벤트 매개변수 차이, 즉 GA4 user property와 GA4 event parameter를 어떻게 고를지 비교합니다.

둘 다 추가 정보를 보내기 때문에 비슷해 보일 수 있습니다. 하지만 역할이 다릅니다.

핵심은 이렇습니다.

event parameter = 이번 행동은 어땠는가
user property = 이 사용자는 어떤 상태인가

이번 글은 둘의 선택 기준을 명확히 비교하는 글입니다.

1. 가장 쉬운 차이

예를 들면 이렇습니다.

consultation_click
+
cta_location = pricing_page
+
membership_tier = pro

consultation_click: 일어난 행동
cta_location: 이번 클릭의 위치 정보
membership_tier: 이 사용자의 요금제 상태

같은 순간에 함께 보낼 수 있지만, 설명하는 대상이 다릅니다.

2. 이벤트 매개변수는 특정 행동 설명

예를 들어 purchase에 value, currency를 붙이면, 이번 구매의 정보를 설명합니다.

GA4 이벤트 매개변수는 “그 행동이 어땠는지”를 담습니다.

행동이 바뀔 때마다 값이 달라질 수 있습니다.

3. 사용자 속성은 사용자를 설명

예를 들어 membership_tier = pro는 사용자를 설명합니다.

여러 이벤트에 걸쳐 유지될 수 있는 상태에 가깝습니다.

로그인, 구매, 상담처럼 다른 행동을 해도, 그 시점의 사용자 상태를 함께 볼 수 있습니다.

4. 같은 사용자라도 parameter는 계속 달라질 수 있음

같은 consultation_click이라도 cta_location은 계속 달라질 수 있습니다.

homepage
pricing_page
footer

사용자는 같아도, 이번 행동의 세부 정보는 달라질 수 있습니다.

5. user property도 바뀔 수 있지만 성격이 다름

예를 들어 free에서 pro로 바뀔 수 있습니다.

사용자 속성이 영구 고정값이라고 생각하지 마세요.

차이는 이렇습니다.

행동마다 바뀌는 정보
vs
사용자 상태가 바뀔 때 바뀌는 정보

변경 빈도만으로 결정하지 말고, 의미가 무엇인지가 먼저입니다.

6. 페이지 위치는 어느 쪽?

cta_location = homepage_top

이 값은 사용자를 설명하는 값이 아니라, 특정 행동의 위치입니다.

그래서 이벤트 매개변수 쪽이 자연스럽습니다.

last_cta_location을 사용자 속성으로 무조건 저장하지 마세요.

7. 요금제는 어느 쪽?

free, pro, business처럼 사용자 상태라면 사용자 속성을 검토하세요.

나쁜 이벤트 분리 예입니다.

pro_login
pro_purchase
free_purchase

행동과 사용자 상태를 분리하세요.

로그인과 구매는 행동이고, 요금제는 사용자 상태입니다.

8. 상품 정보는 어느 쪽?

상품이나 금액은 특정 구매 행동과 관련됩니다.

Google 전자상거래 표준 이벤트와 매개변수를 우선 검토하세요.

last_product 같은 사용자 속성을 무조건 만들지 마세요.

이번 구매의 정보라면 이벤트 쪽을 먼저 봅니다.

9. 언어 설정은 어느 쪽?

서비스 언어 설정이 비교적 유지된다면 사용자 속성 후보입니다.

예:

preferred_language = ko

단, GA4 기본 정보나 기존 기능으로 충분한지 먼저 확인하세요.

새 속성을 만들기 전에 “이미 있는 정보인가?”를 한 번 더 봅니다.

10. 검색어는 어느 쪽?

검색마다 값이 달라지는 행동 정보입니다.

보통 이벤트 매개변수 쪽이 자연스럽습니다.

last_search_keyword를 사용자 속성으로 습관적으로 만들지 마세요.

11. 사용자 상태를 모든 이벤트 parameter에 반복해야 하나?

예를 들어 모든 이벤트에 membership_tier = pro를 맞춤 매개변수로 반복하는 방식입니다.

본래 사용자 상태라면, 사용자 속성이 적절한지 먼저 검토하세요.

같은 의미를 이벤트 쪽과 사용자 쪽에 중복으로 설계하지 않는 것이 원칙입니다.

GA4 scope를 고를 때, 정보의 주인이 누구인지부터 보세요.

12. 행동 정보를 user property로 복사하지 않기

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

last_button_clicked
last_page
last_search
last_product

정말 필요한 분석 목적이 없다면, 기존 이벤트 데이터를 활용하는 편이 낫습니다.

최근 행동을 사용자 속성으로 계속 덮어쓰면, 역할이 흐려질 수 있습니다.

13. 같은 정보를 둘 다 보내면 더 좋은가?

항상 그렇지는 않습니다.

같은 membership_tier를 사용자 속성과 이벤트 매개변수에 둘 다 반복하면, 기준이 헷갈리거나 중복이 생길 수 있습니다.

핵심 질문은 이것입니다.

이 정보의 주인은 이벤트인가, 사용자인가?

14. 가장 중요한 선택 질문

이 정보는 무엇을 설명하나요?

이번 행동을 설명하는가?
→ event parameter 검토

사용자를 설명하는가?
→ user property 검토

이 한 질문이 GA4 맞춤 측정기준을 나중에 어떻게 쓸지에도 영향을 줍니다.

15. 값이 언제 바뀌는지도 보조 기준

행동 때마다 달라지면 이벤트 매개변수 가능성이 높습니다.

사용자 상태가 바뀔 때 달라지면 사용자 속성 가능성이 높습니다.

다만 변경 빈도만으로 결정하지 마세요.

의미가 최우선입니다.

16. 분석 질문을 먼저 생각

예를 들면 이렇습니다.

어느 위치에서 상담 클릭이 많은가?

→ 이벤트 + cta_location

free와 pro 중 누가 상담을 많이 하는가?

→ membership_tier 사용자 속성 + consultation 이벤트

분석 질문이 명확하면, 어디에 정보를 둘지도 분명해집니다.

17. user property 때문에 이벤트를 쪼개지 않기

나쁜 예입니다.

free_consultation_submit
pro_consultation_submit
business_consultation_submit

더 나은 구조는 이렇습니다.

consultation_submit
+
user property

사용자 그룹이 늘어나도 이벤트 구조를 바꾸지 않아도 됩니다.

18. parameter 때문에 이벤트를 쪼개지 않기

나쁜 예입니다.

homepage_consultation_click
footer_consultation_click
pricing_consultation_click

더 나은 구조는 이렇습니다.

consultation_click
+
cta_location

단, 실제 행동 의미가 다르면 이벤트를 분리할 수 있습니다.

세부 정보가 다른 것과, 행동 자체가 다른 것은 구분하세요.

19. 그렇다고 모든 행동을 하나의 이벤트로 합치지 않기

나쁜 예입니다.

user_action 하나로 login, purchase, consultation_submit을 전부 매개변수로 구분하는 방식입니다.

핵심은 이렇습니다.

행동 의미가 다름 → event 분리
같은 행동의 세부 정보 다름 → parameter 검토
사용자 상태 다름 → user property 검토

너무 쪼개지도, 너무 합치지도 마세요.

20. 개인정보 기준

이벤트 매개변수와 사용자 속성 모두 개인정보에 주의하세요.

예를 들면 아래입니다.

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

임의로 전송하지 마세요.

최소한의 분석 데이터만 사용하세요.

21. 측정 계획에 scope 기록

어디에 둘지도 짧게 기록하세요.

정보	역할	값 예시	이유
CTA 위치	event parameter	homepage_top	이번 클릭의 위치
구매 금액	event parameter	49000	이번 구매의 금액
현재 요금제	user property	free, pro	사용자 상태
고객 유형	user property	individual, business	사용자 특징

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

22. 이미 GA4가 제공하는 정보인지 확인

새 매개변수나 사용자 속성을 만들기 전에 확인하세요.

GA4 기본 정보
Google 표준

custom_page_type, custom_device, custom_source처럼 이미 있는 정보를 다시 만드는 중복 구조는 피하세요.

23. 애매할 때 네 가지 적기

애매하면 아래를 적으세요.

이 정보는 무엇을 의미하는가?
누구/무엇에 붙는 정보인가?
언제 값이 바뀌는가?
어떤 분석에 사용하는가?

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

의미: 현재 요금제
대상: 사용자
변경: 요금제 변경
분석: 요금제별 행동 비교

→ 사용자 속성이 자연스럽습니다.

24. 구현 후 실제 값 검증

매개변수에서 homepage, Home, home이 섞이지 않았는지 확인하세요.

사용자 속성에서 pro, paid, premium처럼 같은 의미가 갈라지지 않았는지도 확인하세요.

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

25. 자주 하는 실수

둘을 고를 때 자주 하는 실수는 이렇습니다.

모든 정보를 매개변수로 보냄
최근 행동을 사용자 속성으로 저장함
같은 정보를 둘 다 저장함
사용자 그룹마다 이벤트 이름을 만듦
서로 다른 행동을 하나의 이벤트로 합침
개인정보를 전송함

좋은 선택은 정보를 많이 보내는 것이 아니라, 올바른 자리에 보내는 것입니다.

26. 사용자 속성과 이벤트 매개변수 중 무엇을 쓸지 확인할 7가지

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

특정 행동을 설명하는가?
사용자의 상태/특징을 설명하는가?
행동마다 값이 달라지는가?
사용자 상태 변경 때 값이 달라지는가?
GA4가 이미 제공하는 정보인가?
같은 정보를 다른 쪽에 중복 저장하고 있지 않은가?
개인정보가 없는가?

27. 차이를 다시 정리하면

구분	이벤트 매개변수	사용자 속성
설명 대상	이번 행동	사용자
쉽게 이해하면	이번 행동은 어땠는가	이 사용자는 어떤 상태인가
예시	`cta_location`, `value`	`membership_tier`
값 변경	행동마다 달라질 수 있음	사용자 상태 변경 때 달라질 수 있음
활용 예	위치별 클릭 비교	요금제별 행동 비교

핵심은 이렇습니다.

행동의 세부 정보 → 이벤트 매개변수
사용자의 상태/특징 → 사용자 속성

28. 정리

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

무슨 정보인가?
↓
특정 행동 설명? → event parameter
사용자 설명? → user property

그리고 아래 순서로 보세요.

GA4 기존 정보 확인
→ Google 표준 확인
→ 필요성 확인
→ 어디에 둘지 결정
→ 이름/값 통일
→ 실제 데이터 검증

다음 글에서는 GA4에서 이벤트 중복과 누락을 어떻게 확인하는지 알아보겠습니다.