GA4 사용자 속성이란 무엇일까?

앞 글에서는 이벤트 매개변수를 어떻게 설계할지 살펴봤습니다.

이번에는 한 걸음 더 나가서, 행동의 정보와 사용자 자체의 정보를 구분합니다.

그 가운데 사용자 자체의 정보가 GA4 사용자 속성, 즉 GA4 user property입니다.

예를 들어 purchase에 value = 49000, currency = KRW를 붙이는 것은 이벤트 매개변수입니다.

반면 membership_tier = pro처럼 사용자를 설명하는 정보는 사용자 속성으로 볼 수 있습니다.

중요한 점 하나:

사용자 속성과 User-ID는 같은 개념이 아닙니다.

1. 사용자 속성이란 무엇일까?

사용자 속성(User property)은 사용자를 설명하는 정보입니다.

쉽게 보면 이렇습니다.

이벤트 = 사용자가 무엇을 했는가
사용자 속성 = 이 사용자는 어떤 상태/특징인가

예시입니다.

membership_tier = pro
preferred_language = ko
customer_type = business

이것이 GA4 user properties의 기본 역할입니다.

2. 이벤트 매개변수와 차이

짧게 비교하면 이렇습니다.

구분	쉽게 이해하면
event parameter	특정 이벤트의 자세한 정보
user property	사용자 상태/특징

예:

purchase + value / currency
vs
membership_tier = pro

이번 글에서는 기초 비교만 합니다. GA4 이벤트 매개변수 차이를 더 자세히 보는 비교는 다음 글에서 이어갑니다.

3. 왜 사용자 속성이 필요할까?

사용자 그룹별 행동을 비교할 때 도움이 됩니다.

예를 들어 free와 pro를 나누면, 그룹별로 아래를 볼 수 있습니다.

login
purchase
기능 사용
key event

같은 행동을 해도, 어떤 사용자 그룹인지에 따라 해석이 달라질 수 있습니다.

4. 어떤 정보가 사용자 속성이 될 수 있을까?

예를 들면 이렇습니다.

membership_tier
preferred_language
customer_type

모든 사용자 정보를 보내는 것이 아닙니다.

실제 분석에 필요한 정보만 선택하세요.

5. 비교적 지속되는 정보에 적합

예를 들어 membership_tier = pro는 여러 이벤트에 걸쳐 일정 기간 유지되는 상태에 가깝습니다.

반면 cta_location = homepage_top처럼 특정 행동의 세부 값은 매개변수에 더 적합합니다.

사용자 속성은 “이번 클릭의 세부”보다 “이 사용자의 상태”에 가깝습니다.

6. 자주 바뀌는 값을 무조건 user property로 만들지 않기

예를 들면 이런 값입니다.

current_page
last_button_clicked
search_keyword

이런 정보는 보통 특정 행동에 가깝습니다.

사용자 속성은 변경될 수 있지만, 매 이벤트마다 계속 바뀌는 정보를 무조건 넣는 구조는 피하세요.

7. 안정적인 값 사용

좋은 예입니다.

free
pro
enterprise

같은 의미를 아래처럼 섞지 마세요.

무료
paid
premium
pro_user

값이 흩어지면 그룹 비교가 어려워집니다.

8. UI 문구와 분석 값 분리

화면에 무료 플랜, STARTMKTG Pro라고 보여도, 분석 값은 free, pro처럼 안정적으로 둘 수 있습니다.

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

화면 변경 때문에 과거와 현재 데이터 기준이 갈라지지 않게, 분석용 값은 따로 관리하세요.

9. 사용자 속성 이름도 일관되게

좋은 예입니다.

membership_tier
customer_type
preferred_language

피할 예입니다.

type
status
group
data

너무 모호한 이름은 피하세요.

GA4 사용자 속성 설정을 할 때도, 이름만 보고 의미를 알 수 있어야 합니다.

10. 하나의 이름은 하나의 의미

예를 들어 customer_type을 어떤 곳에서는 individual/business, 다른 곳에서는 free/pro로 쓰지 마세요.

필요하면 역할을 나누세요.

customer_type
membership_tier

하나의 이름은 하나의 의미만 담으세요.

11. 너무 세세하게 사용자 그룹을 나누지 않기

아래를 무작정 사용자 속성으로 만들지 마세요.

signup_month
last_page
last_button
last_campaign
favorite_category

핵심 질문은 이것입니다.

이 그룹을 나눠 어떤 결정을 할 것인가?

결정할 수 없는 그룹은 만들지 않는 편이 낫습니다.

12. 개인정보 주의

아래 값은 임의로 보내지 마세요.

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

분석 목적보다 개인정보 보호가 우선입니다.

13. 내부 DB 정보를 전부 GA4에 복사하지 않기

DB에 있다고 GA4에도 필요한 것은 아닙니다.

GA4는 운영 DB가 아닙니다.

분석에 필요한 최소 정보만 보내세요.

14. User-ID와 사용자 속성 차이

쉽게 보면 이렇습니다.

User-ID = 동일 사용자를 식별하는 별도 기능
User property = 사용자 특징/상태 설명

GA4 User-ID와 사용자 속성을 같은 개념으로 보지 마세요.

User-ID 상세는 뒤 PART나 별도 글에서 이어가면 됩니다.

15. 사용자 속성 값은 바뀔 수 있음

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

사용자 속성이 영구 고정 값만 담는다고 생각하지 마세요.

상태가 바뀌면 값도 바뀔 수 있습니다.

16. 언제 값을 바꿀지도 설계

예를 들어 결제 버튼 클릭 시점이 아니라, 실제 유료 전환 성공 후 membership_tier를 바꾸는 방식을 검토할 수 있습니다.

핵심은 이렇습니다.

이름
+
값
+
업데이트 시점

이름만 정하고 끝내지 마세요.

17. 값이 사라지거나 다시 바뀌는 상황도 고려

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

설계할 때 아래를 함께 생각하세요.

언제 설정하는가
언제 변경하는가
언제 제거하거나 다른 값으로 바꾸는가

세부 API 구현은 이번 글에서 다루지 않습니다.

18. 이벤트 이름마다 사용자 상태를 반복하지 않기

나쁜 예입니다.

pro_user_login
pro_user_purchase
pro_user_cta_click

더 확장 가능한 구조는 이렇습니다.

login
purchase
cta_click
+
membership_tier = pro

행동 이벤트와 사용자 상태를 분리하세요.

19. event parameter와 user property 함께 사용 가능

예를 들면 이렇습니다.

event: consultation_click
parameter: cta_location = pricing_page
user property: membership_tier = pro

사용자 그룹과 행동 세부 정보를 함께 볼 수 있습니다.

둘은 대체 관계가 아니라, 역할이 다른 정보입니다.

20. 측정 계획에 user property 기록

사용자 속성도 짧게 기록하세요.

사용자 속성	의미	값 예시	언제 변경
membership_tier	현재 요금제	free, pro	요금제 변경 확정 시
customer_type	고객 유형	individual, business	유형 확정/변경 시
preferred_language	선호 언어	ko, en	언어 설정 변경 시

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

21. 만들기 전에 네 가지 정의

새 사용자 속성을 만들기 전에 아래를 정하세요.

이름
의미
값
언제 설정/변경

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

의미: 현재 요금제
값: free, pro
업데이트: 요금제 변경 확정 시

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

22. 일반 보고서 분석에 추가 설정이 필요할 수 있음

사용자 속성을 전송했다고, 일반 보고서에서 원하는 형태로 바로 활용되는 것은 아닐 수 있습니다.

사용자 범위의 GA4 맞춤 측정기준 같은 설정이 필요할 수 있습니다.

상세 구현은 뒤 글에서 이어가면 됩니다.

23. 실제 값 확인

구현 후 아래를 확인하세요.

예상한 값인가
대소문자가 섞이지 않았는가
같은 뜻이 여러 표현으로 오지 않는가
상태 변경 후 이전 값이 남아 있지 않은가

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

24. 자주 하는 실수

사용자 속성을 만들 때 자주 하는 실수는 이렇습니다.

이벤트 매개변수와 사용자 속성을 섞어 봄
모든 DB 정보를 전송함
같은 의미를 여러 값으로 저장함
UI 문구를 분석 값으로 그대로 씀
개인정보를 전송함
업데이트 시점을 정하지 않음

좋은 사용자 속성은 많이 보내는 것이 아니라, 비교에 쓸 상태를 안정적으로 남기는 것입니다.

25. GA4 사용자 속성을 만들기 전에 확인할 8가지

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

특정 이벤트가 아니라 사용자를 설명하는 정보인가?
실제 분석에 필요한가?
GA4가 이미 제공하는 정보로 충분하지 않은가?
이름만 보고 의미를 알 수 있는가?
같은 의미에 같은 값을 쓰는가?
언제 설정/변경할지 정했는가?
event name/parameter에 같은 정보를 반복하지 않는가?
개인정보가 없는가?

26. 사용자 속성을 다시 정리하면

개념	쉽게 이해하면
user property	사용자 상태/특징
event parameter	이번 행동의 세부 정보
user property value	free, pro처럼 안정적인 분석용 값
업데이트 시점	언제 설정하고 언제 바꾸는가
User-ID	동일 사용자를 식별하는 별도 기능

핵심 구분은 이렇습니다.

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

27. 정리

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

정말 사용자 수준 정보인가?
→ 실제 분석에 필요한가?
→ 이름/값 통일
→ 업데이트 시점 결정
→ 개인정보 확인
→ 구현 후 실제 값 검증

다음 글에서는 GA4 사용자 속성과 이벤트 매개변수는 무엇이 다른지 조금 더 자세히 비교해보겠습니다.