내 GA 이벤트가 사라지고 있다?!(아니면 복사되던가)

"일단은" 편리한 Google Analytics4

Google Analytics는 이벤트 수집과 분석을 위해 비용을 투자할 여력이 없는 소규모 스타트업은 물론이고, 자체적인 BI 구축이 가능한 대규모 서비스에서도 두루두루 활용되고 있는 서비스입니다.

물론, 레딧같은 초대규모 서비스에서는 자체적인 이벤트 분석 툴이 존재하지만, 구글 애즈와의 연동을 위해 일부 사용한다고 합니다.

서너줄의 JavaScript 코드를 index.html 헤더에 삽입하는 것만으로도 기본적인 페이지 뷰, 클릭, 스크롤 등의 이벤트를 수집해주며, 수집된 데이터들을 애널리틱스 대시보드에서 쉽게(어디까지나 구축의 과정이지, 지표 해석과 거지같은 GA 대시보드 UI는 개발자의 혈압을 올려주는 역할을 합니다.) 확인이 가능합니다.

무엇보다, 이러한 데이터를 일단은 구글이 무상으로 적재합니다.

즉, 이벤트 데이터를 적재하기 위한 별도의 데이터베이스나 스토리지가 필요하지 않다는 의미입니다.

물론, 구글은 이렇게 가져간 데이터를 통해 구글 ADS의 광고 타겟팅 최적화 같은 내부 서비스 강화 목적으로 사용할 것이므로, 무료 데이터 수집을 위해 풀어놓은 것이죠.

(실제로 약관 상에서는 수집된 데이터를 어떻게 활용하는지는 적혀있지 않지만, 그 많은 데이터로 무엇을 할지는 너무나 뻔할 것 같습니다.)

다만, 누구에게나 무료로 열려있는만큼, 성능이 좋지 않다는 평가가 대부분입니다.

특히, 가장 큰 문제는 레딧이나 스택 오버 플로우 등지의 개발자 커뮤니티에서 확인할 수 있는 밈에서 찾을 수 있습니​다.

1. GA4의 구현은 어렵다. 특히 UA -> GA4의 마이그레이션이 대단히 어렵다.
2. 이벤트의 수가 불어난다 (또는 줄어든다)
3. 기존의 세션 기반 수집에서, 이벤트 기반 수집으로 변경되었다.

여러가지 어려움이 있지만, 기존의 UA(Universal Analytics)와 사실상 근본부터가 다르다는 문제가 있습니다.

이것은 세션 기반 행동 파악에서 이벤트기반 행동 파악으로, 기반 패러다임 자체가 완전히 변했기 때문입니다. 이런 상황에서 당연히 마이그레이션이 쉬울 수는 없습니다.

물론, 이러한 변화는 모바일 환경에서는 세션의 경계가 모호하다는 사실과 CCPA/ GDPR처럼 보다 강화된 개인정보 수집 관련 법률에 대응하기 위한 것으로, 어쩔 수 없었을 것으로 생각됩니다.

문제는 Events 이 녀석이다

제목에서도 말했듯, 이 분석 단위인 이벤트에 여러모로 문제가 많습니다.

GA4의 대시보드는 매우 불편합니다. 제가 만나봤던 데이터 분석가나 GA를 사용했던 개발자들 모두 똑같이 생각했던 부분입니다. GA4 대시보드는 정말 구립니다.

그렇기 때문에 보통은 BigQuery로 GA의 데이터를 가져와 직접 BI툴을 붙이거나, 시각화하여 사용하게 되는데

이 경우 비용 최적화를 위해서는 SQL을 수준급으로 다룰 수 있어야 한다는 장벽이 존재합니다. 프로그래밍을 배우지 않은 마케터는 사실상 접근 자체가 불가능한 영역이 되는 것입니다.

물론 BigQuery 자체가 워낙 잘 만들어진 서비스이기 때문에(저는 GCP 최고의 서비스 세 개를 뽑는다면 반드시 빅쿼리가 들어간다고 생각합니다.) SQL 개발이 가능하다면, 큰 문제가 되지 않습니다.

이벤트만 잘 쌓인다면 말이죠.

똑같은 이벤트가 중복으로 쌓이거나, 아예 누락되는 경우가 꽤나 많습니다.

중복 이벤트는 유저가 새로고침이나 뒤로가기 등으로 다량 발생하여 어쩔 수 없겠지만, 일단 쌓인 데이터는 어떻게든 정제가 가능하므로 큰 문제는 아닙니다.

진짜 문제는 데이터가 안 쌓이는 것이죠.

데이터 누락에는 여러 이유가 있습니다만, 대표적인 건 다음과 같이 뽑아볼 수 있겠습니다.

1. ADBlock 등의 광고 차단 서비스
2. 특수 브라우저 사용 (Brave, Tor, Sarfari 등)
3. 써드파티라는 한계

광고 차단 서비스?

보통 브라우저 확장 프로그램으로 설치하는 경우가 많은데, 이 경우에는 GA 스크립트의 동작 자체가 막히게 됩니다.

어째서 애드블록이 GA를 막는 건데?

일단 GA 스크립트가 어떻게 동작하는지를 설명해야 합니다.

GA 스크립트를 웹사이트에 삽입할 경우, 해당 스크립트는 써드파티 쿠키를 유저의 브라우저에 삽입하고, GA 데이터를 받는 구글측 서버로 전송합니다.

해당 웹페이지는 제가 근무하는 회사의 서비스에서 발생하는 트래픽으로, GA가 자동으로 이벤트 데이터를 쿼리파라미터로 변경하여 위의 https://analytics.google.com/collect?v=2~
와 같은 구글측 도메인으로 데이터를 전송합니다.

즉, 이 스크립트의 행동 자체가 우리 서비스의 제어를 받지 않게 됩니다.

그리고 애드블록 서비스는 해당 행위 자체를 유저 추적 및 외부 서비스의 광고 데이터 수집과 관련된 행위로 파악하고 막아버립니다.

이것은 비단 GA4만의 문제가 아니라, 메타의 픽셀, 믹스패널, MS Clarity처럼 잘 알려진 데이터 수집 도메인 자체가 블록리스트로 등록되므로, 대부분의 써드파티 데이터 수집기가 무력화되는 문제입니다.

해결을 위해서는 구글측 도메인으로 데이터를 보내기 전, 우리 도메인 서버로 먼저 데이터를 경유시키고 보내는 서버사이드 태깅(sGTM)이 있는데, 이는 다음에 적용 과정과 함께 다시 설명하겠습니다.

특수 브라우저 사용

Chrome, Edge 등의 일반적인 브라우저에서는 애드블록 서비스를 쓰지 않는 이상, GA 같은 데이터 수집기를 차단하거나 무력화시키진 않습니다.
(애초에 이 브라우저를 만든 회사가 만든 수집기들이 데이터를 수집해야 하는데 막을리가 없죠. 단, 시크릿 모드를 사용한다면 이야기가 좀 다르긴 합니다.)

문제는 Brave, Tor, Safari 등의 비 크로미움 브라우저들입니다.

해당 브라우저들은 기본적으로 유저의 프라이버시를 보호하기 위해 써드파티의 데이터 수집을 허락하지 않고, 가능한한 훼방을 놓습니다.

Safari는 잘 수집 되던데?

물론, Safari는 원천 봉쇄까지는 하지 않습니다. 애플도 데이터로 먹고 살아야하는 마당에 그러긴 쉽지 않죠.

단지 쿠키의 수명을 극단적으로 제한시켜버립니다.

GA 쿠키는 최장 2년까지도 브라우저에 남아있지만, 사파리는 이를 2주 정도로 낮춰버립니다.

로그인한 유저라 쿠키에 유저를 식별할 정보가 존재한다면 괜찮겠지만, 비 로그인한 유저가 2주마다 방문한다면, 리텐션이 아닌 새로운 방문자로 인식한다는 문제가 발생하므로, 장기 추적에 애로사항이 생기는 것이죠.

진짜 문제는 Brave, Tor입니다. 브라우저 자체에 애드블록 기능이 기본적으로 탑재되어 있고, 다양한 방식으로 데이터를 왜곡하므로, 오히려 억지로 데이터를 수집하는 게 데이터의 품질을 저해시킬 수도 있습니다.

GA에 전송되는 데이터 자체에 해당 유저에 대한 식별자가 존재하지만, 그게 불가능하다면 핑거프린팅(브라우저 정보, 접속 위치 등으로 식별)하는 방식이라도 사용하지만, 위 두 브라우저는 핑거프린팅마저 불가능하도록 브라우저 정보를 미세하게 틀어놓는 방식을 사용합니다.

그리고 극한의 프라이버시를 보장하는 Tor는 애드블록 + 시크릿 모드 + 핑거프린팅 왜곡 + 네트워크 왜곡이 기본적으로 탑재되어, 모든 수단을 동원해 유저 트래킹을 막습니다.

(그런데 일반적인 서비스에 Brave, Tor로 접근하는 유저의 데이터를 과연 모아야 할까요..?)

써드파티라는 한계

GA 스크립트는 기본적으로 써드파티입니다. gtag()로 호출 위치와 전송할 데이터 파라미터, 이벤트를 정할 수는 있지만, 써드 파티 쿠키를 통해, 외부 서비스로 전송되는 데이터입니다.

한 번 네트워크를 태워 보내면 그 이후는 제어가 어렵습니다. 또한 기본적으로, 실패하더라도 재전송을 하진 않기 때문에, 한번 전송이 실패하면 데이터는 누락됩니다.

물론, 유실이 그렇게 많지는 않습니다만, 하필이면 "결제 버튼 클릭", "결제 완료 후 홈페이지 리다이렉트" 같은 중요한 이벤트가 누락되면 분명 귀찮은 일이 될 것입니다.

"왜 결제 기록은 10건인데, 결제 완료 이벤트는 8건 밖에 안 보여!?"

같은 일이 발생하면, 데이터 보완을 위해 서비스의 DB 결제 관련 데이터를 가져와 덧붙여야 하는 그런 일들이 생기는 것이죠... (제 경험입니다.)

이런 경우, BI 서비스를 위한 컨테이너를 Private Subnet 내부에 위치시켜 Cloud SQL(또는 RDS)와 연동하거나, 외부에 두고 별도의 VPC 커넥터 연결이 필요해집니다. 보안상이나, 비용 최적화 면에서나 절대 좋은 선택이 아니죠.

또는 Cloud DB의 데이터를 BigQuery에 주기적으로 업로드 시켜줘야 하는데, 이것 또한 ETL 공수가 생기고, 데이터 삭제/수정이 여러모로 어려운 BigQuery에는 적합하지 않은 작업입니다.

그렇기에, 차라리 중복으로 쌓이는 편이 안 쌓이는 것보다는 훨씬 나은 편이죠.

그렇다면 어떻게 이 문제들을 해결할 수 있을까?

그리고 위의 문제를 해결할 수 있는 가장 좋은 방식은 서버사이드 태깅(sGTM)입니다.

클라이언트(FE) -> analytics.google.com 로 즉시 보내지 않고,

클라이언트 -> 데이터 수집 전용 서버 -> analytics.google.com 으로 흐름을 변경시키는 것입니다.

자체적으로 관리하는 데이터 수집 전용 서버를 통해 써드 파티 쿠키가 아닌 퍼스트 파티 쿠키를 발급하고, 먼저 우리 서비스 도메인으로 데이터를 보내는 것이죠.

클라이언트 측에서 데이터 전송에 실패할 경우 재시도 로직을 만들 수 있고, 데이터 수집 서버에서 별도의 정제 과정을 거쳐 데이터를 수집할 수 있기 때문에, 보다 품질 좋은 유저 이벤트 데이터를 쌓을 수 있습니다.

물론, 해당 서버를 구축/관리하는 데에 당연히 공수와 비용이 발생합니다만, 장기적으로 높은 품질의 데이터를 쌓아서 이를 비즈니스에 활용해 서비스 품질을 올릴 수 있다면, 당연히 필요한 투자입니다.

다음 포스팅에서는 이 서버사이드 태깅을 직접 저희 블로그에 구현하는 과정을 적어보도록 하겠습니다.