GA4 세팅을 진행하다 보면 생각보다 많은 기업에서 “고객 이름과 전화번호도 같이 수집하면 안 되나요?”라는 질문을 받습니다. 고객 데이터를 한곳에서 보고 싶다는 마음에서 나온 자연스러운 요청이지만, GA4에는 분석에 아무리 유용해 보여도 절대 수집해서는 안 되는 데이터가 있습니다. 이 글에서는 GA4로 수집해서는 안 되는 데이터를 유형별로 정리하고, 수집하면 어떤 문제가 생기는지, 대안은 없는지, 이미 수집하고 있다면 어떻게 조치해야 하는지 알아보겠습니다.
1. GA4는 왜 개인정보 수집을 금지할까요?
구글 애널리틱스 서비스 약관은 개인정보를 다음과 같이 다루고 있습니다.
"’귀하’는 ‘Google’이 개인 식별 정보로 사용하거나 인식할 수 있는 정보를 해당 정보의 해싱 여부와 관계없이 ‘Google’에 전달하거나 제3자가 이를 전달하도록 돕거나 허용해서는 안 됩니다.” (출처: Google 애널리틱스 서비스 약관 7항)
여기서 주목할 부분은 “해싱 여부와 관계없이”라는 표현입니다. 이메일 주소를 해시값으로 변환해서 보내더라도 원칙적으로는 약관 위반이라는 뜻입니다. 해당 기능의 정책과 약관이 명시적으로 허용하거나, 그 기능을 위해 업계 표준 방식으로 해싱된 경우에만 예외로 인정됩니다.
구글이 이렇게 엄격한 이유는 GA4의 역할이 다르기 때문입니다. GA4는 개별 고객을 관리하는 CRM이 아니라, 익명 사용자의 행동을 집계해서 보는 분석 도구입니다. 쉽게 말해 GA4로 보내는 이벤트 매개변수는 봉투에 넣은 편지가 아니라 엽서에 가깝습니다. 맞춤 측정기준으로 등록하거나 빅쿼리로 내보내는 순간, 속성에 접근 권한이 있는 사람이라면 내부 구성원이든, 광고 대행사든, 외부 컨설턴트든 그 값을 그대로 읽을 수 있습니다(등록하지 않은 매개변수도 DebugView에는 그대로 노출됩니다). 이런 구조에 개인정보가 들어가는 순간, 의도하지 않은 개인정보 제공이 시작됩니다.
2. 수집해서는 안 되는 데이터 유형 총정리
| 유형 | 대표 예시 | 문제가 되는 이유 |
|---|---|---|
| 직접 식별 정보 | 이름, 이메일 주소, 전화번호, 상세 주소, 주민등록번호 | 구글이 명시한 대표적인 개인 식별 정보(PII) |
| URL 속 개인정보 | 쿼리스트링에 담긴 이메일, 이름, 인증 링크 | page_location으로 자동 수집됨 |
| 민감정보 | 건강, 의료, 금융 관련 값 | 다른 값과 결합 시 민감정보가 되어 리스크 증폭 |
| 인증, 보안 정보 | 비밀번호, 인증 토큰, 세션 키, 카드번호 | 유출 시 보안 사고로 직결 |
하나씩 알아보겠습니다.
1) 직접 식별 정보
이름, 이메일 주소, 전화번호, 상세 주소, 주민등록번호처럼 그 값만으로 특정 개인을 가리키는 정보입니다. 구글 고객센터의 개인 식별 정보 관련 권장사항 문서도 이메일 주소, 개인 전화번호, 주민등록번호를 대표 예시로 들고 있으며, 재설정이 불가능한 휴대전화의 기기 고유 ID처럼 특정 기기를 영구적으로 식별하는 값도 같은 범주로 봅니다.
실무에서는 회원가입 완료, 구매 완료, 상담 신청 완료 이벤트를 설계할 때 “어차피 우리 고객 정보인데”라며 이름과 연락처를 매개변수에 넣으려는 시도가 자주 나옵니다. 내부 DB에 보관하는 것과 구글 서버로 전송하는 것은 전혀 다른 문제입니다.
2) URL에 담겨 들어오는 개인정보
컨설팅 현장에서 자주 발견되는 유형입니다. GA4는 page_view 이벤트를 수집할 때 페이지 주소(page_location)를 쿼리스트링까지 통째로 저장합니다. 태깅을 잘못한 적이 없어도, 웹사이트가 URL에 개인정보를 실어 나르는 구조라면 개인정보가 그대로 쌓입니다.
실제로 한 고객사는 상담 신청 완료 페이지를 complete?name=홍길동&phone=01012345678 형태로 개발했고, GA4 담당자는 아무 설정도 잘못하지 않았는데 페이지 보고서에 신청자 이름과 전화번호가 전부 남아 있었습니다. 이메일 인증 링크, 비밀번호 재설정 링크, 이벤트 당첨자 확인 페이지에서도 같은 문제가 반복됩니다.
3) 건강, 의료, 금융 관련 민감정보
단독으로는 개인을 식별하지 못해도, 다른 값과 결합하는 순간 성격이 달라지는 정보가 있습니다. 예를 들어 진료 예약 서비스를 컨설팅하며 결제 이벤트에 예약자 실명과 진료 과목이 매개변수로 설계되어 있던 사례가 있었습니다. 이름 하나, 진료 과목 하나는 단순해 보여도 둘이 결합되면 “누가 어떤 진료를 받았는지”라는 의료 정보가 됩니다. 이런 값은 개인정보 중에서도 민감정보에 해당해 법적으로 더 엄격하게 보호되므로, 발견 즉시 수집을 중단하고 설계를 바꿔야 합니다.
4) 인증, 보안 정보
비밀번호, 인증 토큰, 세션 키, 카드번호는 개인정보이기 이전에 보안 사고로 직결되는 값입니다. 주로 URL이나 dataLayer에 디버깅용으로 남아 있던 값이 흘러 들어오는 형태로 발견됩니다. 분석에 쓸 일도 없는 데이터이므로 발견 즉시 걷어내야 합니다.
5) user_id에는 어떤 값을 써야 할까요?
로그인 사용자를 기기와 브라우저를 넘어 연결해 주는 User-ID 기능 자체는 구글이 공식적으로 제공하는 기능입니다. 다만 구글은 User-ID 가이드에서 “사용자 ID에는 서드 파티가 사용자의 신원을 파악하는 데 이용할 수 있는 정보가 포함되면 안 됩니다”라고 규정합니다. 내부에서만 의미를 갖는 회원번호(M10293 같은 값)는 사용해도 되지만, 이메일 주소나 전화번호를 그대로 user_id로 쓰면 위반입니다.
3. 수집하면 어떤 문제가 생길까요?
첫째, 약관 위반 상태가 됩니다. 개인정보가 담긴 순간부터 해당 속성은 구글과 맺은 약관을 위반한 채 운영되는 셈이며, 문제가 된 데이터의 삭제 절차를 밟는 동안 분석 데이터의 손실도 감수해야 합니다.
둘째, 법적 리스크가 생깁니다. GA4 수집은 개인정보가 국외 사업자의 서버로 전송되는 구조입니다. 이용자가 동의한 수집, 이용 범위에 이런 전송이 포함되지 않았다면 개인정보 보호법 관점에서 문제가 될 수 있고, 건강 정보처럼 민감정보에 해당한다면 별도 동의가 필요한 영역이라 리스크는 더 커집니다.
셋째, 노출 범위가 계속 넓어집니다. GA4 속성은 혼자 보는 도구가 아닙니다. 마케팅팀, 광고 대행사, 외부 컨설턴트까지 권한을 공유하고, 빅쿼리로 내보내면 데이터가 복제되며, 루커 스튜디오 대시보드로 만들면 열람 범위가 또 늘어납니다. 처음에는 매개변수 하나였던 개인정보가 어느새 여러 시스템에 퍼져 있게 됩니다.
넷째, 되돌리기 어렵습니다. GA4는 이미 수집된 데이터를 자유롭게 수정하는 기능을 제공하지 않습니다. 데이터 삭제 요청(Data deletion request) 기능으로 특정 필드의 텍스트를 지울 수는 있지만, 빅쿼리와 대시보드처럼 이미 바깥으로 나간 사본까지 지워 주지는 않습니다.
4. 안전한 설계로 바꾸는 방법: 개인정보 없이 분석하기
다행히 개인정보를 보내지 않고도 같은 분석을 할 수 있는 대안이 있습니다. 원칙은 세 가지입니다.
- 식별값은 내부 ID로 바꿉니다. 실명 대신 회원번호, 담당자 이름 대신 담당자 ID를 보냅니다.
- 상세값은 카테고리로 바꿉니다. “홍길동님의 내과 진료”가 아니라 “비대면 상담”이라는 서비스 단위의 고정값이면 분석에 충분합니다.
- 원본은 내부에 두고, 필요할 때 연결합니다. 상세 데이터는 내부 DB에 보관하고, 심층 분석이 필요하면 빅쿼리에서 내부 데이터와 user_id 기준으로 결합하는 방식을 권장합니다.
이 원칙대로면 분석에 필요한 정보는 그대로 남습니다. 누가 결제했는지 이름을 몰라도 회원번호로 사용자 여정을 추적할 수 있고, 진료 과목을 몰라도 서비스 단위의 전환율은 계산됩니다.
5. 이미 수집되고 있는지 점검하고 조치하는 방법
점검은 두 가지만 확인해도 대부분 드러납니다.
- 탐색 분석에서 페이지 위치(page_location)를 측정기준으로 놓고
email=,name=,phone=,tel=,token=같은 문자열로 필터를 걸어 확인합니다. - 이벤트 정의서와 실제 수집값을 대조합니다. DebugView에서 이벤트 매개변수에 실명, 연락처, 식별 가능한 값이 들어오는지 살펴봅니다.
개인정보가 발견됐다면 조치 순서는 다음과 같습니다.
- 수집 중단이 최우선입니다. URL에 개인정보를 싣지 않도록 개발단에서 구조를 바꾸는 것이 근본 해결책입니다.
- GA4 데이터 삭제(Data redaction) 기능을 켭니다. 웹 데이터 스트림 설정에서 이메일 주소와 지정한 URL 쿼리 매개변수를 수집 전에 자동으로 걸러내는 기능입니다(공식 문서). 이메일 주소는 모든 이벤트 매개변수에서 탐지되지만, 쿼리 매개변수 삭제는
page_location,page_referrer,page_path,link_url,video_url,form_destination여섯 개를 대상으로만 동작합니다. 걸러진 값은 (redacted)로 대체됩니다. - 과거 데이터는 데이터 삭제 요청으로 지웁니다. 속성 설정의 데이터 삭제 요청 기능으로 이미 쌓인 값의 텍스트 삭제를 요청할 수 있습니다. 다만 매개변수를 골라 지우는 방식은 맞춤 측정기준으로 등록된 매개변수와 사용자 속성에만 쓸 수 있습니다.
page_location처럼 자동 수집되는 매개변수는 “모든 이벤트에서 모든 매개변수 삭제”를 선택해야 지워지고, 이때는 이벤트 이름까지 함께 삭제됩니다. 요청에는 편집자 권한이 필요하고, 수집된 지 12일이 지난 데이터만 대상이며, 처리에 7~63일이 걸리고 완료 후에는 되돌릴 수 없습니다.
*주의: 데이터 삭제(Data redaction) 기능은 웹 스트림에서만 동작하며, 앱 스트림은 물론 측정 프로토콜(Measurement Protocol)이나 데이터 가져오기(Data import)로 들어오는 데이터에도 적용되지 않습니다. 구글도 이 기능을 완벽한 차단이 아닌 최선의 노력으로 안내하므로, 기능에 의존하기보다 애초에 보내지 않는 구조를 만들어야 합니다.
GA4를 도입하면서 개인정보 처리 방침을 어떻게 손봐야 하는지 궁금하신 분들은 GA4 설치 시 개인정보 처리 방침을 수정해야 하나요? 글을 함께 읽어보시기를 바랍니다.
마무리
GA4로 수집해서는 안 되는 데이터를 정리하면 네 가지입니다: 직접 식별 정보, URL에 담겨 들어오는 개인정보, 건강과 금융 같은 민감정보, 그리고 인증 정보입니다. 문제는 대부분 태깅 실수가 아니라 “URL과 dataLayer에 원래 있던 값”에서 시작되므로, 이벤트 정의서를 작성하는 단계에서 개인정보 여부를 함께 검수하는 것이 확실한 예방책입니다.
데이터는 많이 모을수록 좋은 것이 아니라, 모아도 되는 데이터만 모을 때 자산이 됩니다. 저희 오픈소스마케팅은 이벤트 설계 단계부터 개인정보 리스크를 함께 검수하는 GA4 구축 컨설팅을 진행하고 있습니다. 우리 회사 GA4에 개인정보가 쌓이고 있는 건 아닌지 점검이 필요하시다면 언제든 편하게 문의해 주세요.
