내부 및 개발자 트래픽을 따로 분류하는 작업은 필수적이다. 원치 않은 데이터를 쌓지 않기 위해서이기도 하지만, 태그 설치가 원활하게 되었는지 효율적으로 체킹할 수 있기 때문이다. 기존 UA와는 다르게 GA4에서는 내부 트래픽을 필터링하는 원리와 방식이 바뀌었다. GA4에서는 모든 데이터 수집을 '이벤트' 기준으로 변경되었다. 내부 트래픽 필터링 역시 그 원리가 적용되는데, 내부 IP를 정의하면 내부 트래픽 이벤트가 필터를 통해 걸러내진다. 이말은 즉슨, GA4에 '우리 내부 트래픽은 이겁니다!'라고 알려줘야하며, 그 내부 트래픽 이벤트를 GA4가 어떻게 할 것인지에 대한 설정이 필요하다. 쉽게 말해, 내부 트래픽을 정의하고, 정의된 내부 트래픽에 필터를 걸어 걸러내는 작업 이 두가지 작업이 필요하다.
[ 내부 트래픽 정의하기 ]
들어간 이후, '내부 트래픽 정의'에 들어가보자
만들기를 누른 후에 제외할 내부 트래픽을 입력하면 된다.
traffic_type이라는 매개변수가 있으며, 그 값이 'internal'라는 의미. 해당 IP 주소는 internal이 되는 것이다.
[ 내부 트래픽에 필터 걸기 ]
그렇다면 '해당 IP 주소 = internal'이 되었음으로, internal이라는 이벤트를 필터링해보도록 하자.
데이터 필터 항목에 들어가면 아까 설정한 'internal Traffic'이 존재한다.
하단에 보면 '필터 상태'가 보일 것이다. 총 세가지 (테스트/활성/비활성)이 있는데, 이에 대한 설명을 하자면
- 테스트 : 디폴트 설정 값. 필터링된 데이터가 제외되는 것이 아니기 때문에 측정기준을 통해 보고서에서 확인 가능한 데이터
- 활성 : 필터링 한 데이터가 보고서 내에 완전히 제거됨
- 비활성 : 필터링을 하지 않는 상태로, 내부 트래픽 정의가 되어 있어도 필터링 되지 않음
내부 데이터를 제거하려면 그럼? '활성' 시키면 된다. 그렇다면, 끝인가? 데이터 필터는 생성 시점부터 적용된다. 이전에 수집된 데이터에 전혀 영향을 주지 않으며, 필터가 적용된 데이터는 변경하거나 삭제할 수 없음으로 반드시 테스트 필터를 통해 검증 및 적용 해야한다. 왜냐면 '활성'을 시키는 순간부터 어디에서도 해당 테이터를 체킹할 수 없음으로 테스트 후에 '활성'을 시키도록 하자.
[ 데이터 필터 테스트 ]
데이터 필터가 잘 적용되었는 지 확인하는 방법은 크게 2가지가 있다. 하나는 위 사진과 같이 '디버그뷰'에 들어가서 확인하는 것이다. 이벤트 매개변수에 'traffic_type - internal'이 포함되어 있으면 필터가 잘 적용된 것이다.
다른 하나는 보고서 내 '비교추가' 버튼을 누른 후, 측정기준으로 '테스트 데이터 필터 이름 - internal Traffic' 과 같이 활성화되어 있으면 테스트 데이터 필터로 분류되고 있음을 알 수 있다. 하지만, 바로 이것을 실행에 옮긴 분들은 '엥? 활성화 안 되어 있는데요? 잘못 설정한건가요?'라는 상황이라면 기다리자. 테스트 필터가 생성되면 바로 측정기준이 조회되지 않고, 반나절 시간 후에 해당 측정기준이 활성화되기 때문이다.
그렇다면 개발자 트래픽은 어떻게 제외시켜야할까?
[ 개발자 트래픽 제외 ]
내부 트래픽 제외와 같이 하면 되겠지~ 생각하면 안 된다. 개발자 트래픽은 내부 트래픽 제외와 다르게 별도의 설정이 필요 없다. 개발자 트래픽 제외는 '디버그(미리보기)' 환경에서 들어온 데이터 값을 자동적으로 'debug_mode', 'debug_event'로 분류해준다.
데이터 필터 이름을 설정하고, 필터 상태를 '테스트'로 놓은 다음에 필터가 잘 적용되었는 지 확인하자.
화면에서 보이는 것과 같이 디버그 관련 매개변수가 기록되어 있다. 저렇게 debug_mode에 숫자 '1'=true라고 값이 나오면 잘 적용된 것이다. 확인이 완료되면, 최종적으로 '활성'시키면 개발자 트래픽이 제외가 된다.
근데 이렇게 내부 및 개발자 트래픽을 싹 다 제외시켜버리면 의문점이 하나 생긴다. '데이터가 잘 쌓이는 지 내부에서 확인하고 싶을 때는 어..쩌라는 거지..?' 필자가 맨 위에서 내부 및 개발자 트래픽을 분리시키는 이유 중 하나로 '태깅 결과 체킹의 효율성'을 갖추기 위함이라고 했는데, 저렇게 다 제외시켜버리면 볼 수가 없기 때문이다.
이를 해결하기 위한 2가지 방식이 있다.
- 내부 및 개발자 트래픽을 활성시키지 않고 '테스트' 상태로 두기 (추후에 보고서에 traffic_type - internal만 빼서 활용하기)
- GA4 디버그 속성 별도로 생성 후, GTM 미리보기 데이터만 따로 분리시켜서 확인하기
2번째 방식은 설명이 필요한데, 간단하게만 집고 넘어가겠다. 일단 준비물은 GA4에 디버그 속성 하나를 새롭게 파기 및 GTM 로그인
LookupTable 변수를 활용하는 방법이다. true에 '디버그 속성', false에 '기존 속성'을 넣고
여기에 아까 생성한 변수를 넣어주고, 사진과 같이 활성화를 시키면 미리보기 모드의 트래픽이 GA4 디버그 속성에 쌓이게 된다. 이것에 대한 자세한 설명은... 넘기도록 하겠다.
이렇게 내부 및 개발자 IP에 필터를 걸면, 데이터 분석을 용이하게 할 수 있다.
'GA4 > GA4 설정 PART' 카테고리의 다른 글
| 레퍼럴이 뭐야? GA4 원치 않는 도메인 트래픽 제외하기, 원치 않는 추천 나열 (0) | 2023.02.01 |
|---|---|
| GA4 크로스 도메인 체킹, 누구나 쉽게 가능하다! (0) | 2023.02.01 |
| GA4 잠재고객이란? 누구나 쉽게 잠재고객 설정하기! (0) | 2023.01.31 |
| GA4의 기초적인 기본 구성 전부 살펴보기 - 관리 탭 (이벤트, 전환수, 맞춤 정의) (0) | 2023.01.31 |
| GA4의 기초적인 기본 구성 전부 살펴보기 - 관리 탭 (속성 설정, 데이터 스트림, 데이터 설정, 디버그뷰) (0) | 2023.01.31 |