GA4 Troubleshooting

GA4를 구성한 후 수집된 데이터를 보면서 분석을 시작했습니다. 물론 제가 하진 않고 A가 하고 있습니다..^^

GA4가 아무래도 외부 솔루션이고 (버그도 있다고 하고) GTM의 동작 구조상 이벤트가 100% 일치할 것이라고 기대하진 않았습니다만,
운영을 해본 분들이라면 꽤나 차이 나는 경우도 많이 보셨을 겁니다.

비디어스도 예외는 아니었죠.

이번 시간에는 놓칠 수 있는 이슈나, 비디어스를 구성하면서 겪은 문제와 해결 과정을 공유하려고 합니다.

1. page_view 이벤트에 대한 이해

GA4에서 page_view는 당연히 자동으로 발생시키는 이벤트라고 생각합니다.
하지만, 이는 GA4에서 설정을 활성화해야 합니다.

그림과 같이 페이지 뷰를 활성화하지 않으면 페이지 뷰 이벤트는 발생하지 않습니다.

간혹 GTM을 설치할 때 패키지를 활용하는 경우 패키지 계층에서 페이지 뷰를 자동으로 설정해 주는 경우가 있습니다.
예를 들어 Nuxt.js에서는 @nuxtjs/gtm이라는 패키지를 제공하고 있는데 (꽤 오래됐지만)
pageTracking 옵션과 pageViewEventName 옵션을 설정하여 페이지 뷰를 발생시킬 수 있습니다.

하지만, 이렇게 구성한 경우 GTM에서 이벤트 구성 시 사용되는 “페이지 뷰”에는 잡히지 않습니다.

GTM에서 트리거 구성 시 사용되는 “페이지 뷰”는 GA4가 자동으로 발생시키는 이벤트만 잡게 되고,
만약 위처럼 코드 레벨에서 페이지 뷰를 발생시킨다면 이는 “커스텀 이벤트”로 정의해 줘야 합니다.

“페이지 뷰”라는 용어가 여기저기서 사용되다 보니 혼동될 뿐만 아니라,
GA4에서 자동으로 발생시키는 이벤트만 잡을 수 있습니다.
사실 개발자라면 자동으로 발생시키는 이벤트보다 직접 맞춤 이벤트를 발생시키는 것이 좀 더 명확한 것 같기도 합니다.
(그렇다면 모든 이벤트 구성&수정 때마다 개발자가 작업해야 하는 단점이 있긴 하지만요..)

2. (not set)으로 설정되는 OS/브라우저 정보

이 부분은 해결은 못했으나, 문제점은 파악하여 공유하고자 합니다.

GA4는 단순히 스크립트만 추가하면 이벤트를 발생시킵니다.
GTM의 미리보기나 GA4의 디버그를 통해 이 이벤트를 확인할 수 있지만, 브라우저의 개발자 도구를 이용해서도 할 수 있습니다.

이처럼 네트워크 탭에서 collect로 필터를 하게 되면 GA 스크립트가 자동으로 보내는 웹 요청을 확인할 수 있습니다.
각 필드를 전부 알 수는 없지만.. 전달되는 값으로 어느 정도 유추가 가능하죠.

자, 그러면 사파리 브라우저를 확인해 볼까요?

사파리 브라우저에서는 어쩐지 전달되는 값이 더 적은 것 같습니다.
확인해 보면 “ua”로 시작하는 필드가 없는 것 같습니다. 이 값은 User-Agent 값으로, 접속한 사용자의 운영체제나 브라우저 정보를 가지고 있는 값입니다.

확인해 본 결과 모바일 사파리 브라우저에서도 동일하게 전달되지 않는 경우가 발생합니다.

사파리에서 전달되지 않는 이슈로 문제가 좁혀졌으니, 차차 해결해보려고 합니다..

3. page_view를 못 믿겠다면..?

page_view 이벤트가 자동으로 보내지지만, 누락되는 것 같고 구성이 잘 안되는 것 같은 경우에는 다음 방법을 써볼 수 있습니다.
바로 History change 트리거를 사용하는 방법입니다.

History change 트리거는 URL 경로가 변경되는 시점에 발생되는 트리거입니다.

사실, 개인적으로 History change라고 하면 직관적으로 알 수 있는데 번역된 이름이 “기록 변경”이다보니 최근에 알게 되었습니다.

주소가 변경될 때 호출되기 때문에, page_view의 대체로 활용할 수도 있습니다.
다만 주의해야 할 점은 “변경”이벤트이기 때문에 첫 진입시는 잡히지 않기 때문에, 대체라기보다 함께 사용하길 권장합니다.

조만간 not set 이슈를 해결해서 돌아오겠습니다~~ 😀

---