당신의 데이터는 생각보다 별로일 수 있다
구글 애널리틱스 4로 이전하기 3 - Audit
글을 쓰기 시작한 것은 연초였는데, 개인적인 사정으로 속도가 느려져 UA의 운명의 날이 100일 안으로 떨어지고서야 글을 마무리 짓는다. 시의적절한 글인 지는 모르겠지만, GA360를 쓰는 분들에게는 시간이 아직 남았기에 약간의 도움이 되었으면 좋겠다.
Universal Analytics (UA)가 세상에 나온 지 10년이 넘었다. library도 ga.js에서 analytics.js, 그리고 현재의 gtag.js로 변화한 만큼 각 UA property에 저장된 데이터는 한 회사와 그 회사와 고객 간의 10년에 걸친 대화의 목록이다. 그만큼 제각각이며, 훌륭한 인사이트를 담고 있기도 하지만, 불필요하며 오히려 해가 되는 대화를 담고 있기도 하다. 따라서 GA4로의 이전은 버튼 하나 클릭해서 하면 안 된다. 그 모든 것, 또는 필요한 것들을 놓칠 수 있기 때문이다.
실제로 구글은 GA4 property가 있지 않은 경우, setup assistant를 통해 자동으로 GA4를 기존 UA property 바탕으로 만들겠다 발표했다. 혹시 이 글을 보는 분들 중 "아하, 나도 이 복잡하고 단계적인 GA4 이전 대신 그냥 그렇게 하나 만들면 되겠다" 생각하시는 분들이 계시다면 아래의 이유로 재고해 보시면 좋겠다.
GTM을 통한 데이터 수집은 예외다
setup assistance는 gtag.js를 통해 inline으로 데이터를 수집해 온 경우, 자동으로 데이터를 GA4 data schema에 맞춰 수집할 수 있다. 즉, GTM을 통해 UA에 데이터를 수집해 온 경우는 예외다. GTM의 GA tag이 어느 library를 쓰는 지를 생각하면 이해가 쉽다.
Messy account structure will be messier
다들 사용하지 않은 standard property, view가 있을 것이다. 이런 경우, opt-out을 하지 않는다면 쓰지 않은 property가 하나 더 느는 셈이 된다. 여기에 default view의 쓰지 않는 goal과 같은 설정도 그대로. 악화가 양화 되는 것을 좋아하지 않는다면 추천하고 싶지 않은 옵션이다.
현재 당신의 데이터가 생각보다 별로일 수 있다
현재 데이터가 알게 모르게 PII를 갖고 있거나, 분석이 불가능한 naming convention을 갖고 있거나, 유럽의 경우 사용자의 동의 없이 수집된 정보일 수 있다. 이사할 때 버릴 짐을 버리지 않아 쓰레기도 같이 그대로 GA4라는 새로운 집에 옮겨가는 것이다.
따라서 앞서 설명했듯이 MVP로 GA4를 시작했고 Full migration을 염두에 둔다면, 다음 단계는 Audit이다.
각 회사마다 GA/GTM audit은 다른 목적과 template이 있겠지만, 나는 팀원들에게 아래의 내용을 강조하는 편이다.
1. Audit은 setup 또는 cofiguration에 대한 리스트가 아니다
흔히 audit이라 했을 때 GA나 GTM에서 어떤 설정을 했는지 아닌 지만 체크하고자 하는 경우가 있다. 물론 경우에 따라 어떤 설정을 했는지가 중요할 수 있다. Bot filtering을 view에서 했느냐 아니냐 (GA4에서는 자동으로 적용이 되지만), Data retention period를 어떻게 설정했는지 등 중요한 context가 되는 내용들이 있다.
하지만 설정값은 굳이 사람이 체크하지 않아도 된다. 우리 팀에는 GA Admin/Management API를 통해 5초면 한 property의 세팅을 거의 알 수 있다. 굳이 사람이 하지 않아도 되는 일이라는 것이다.
더 중요한 것은 그래서 무엇이 개선되어야 하고, 왜 그렇냐는 점이다. 예를 들어, scroll depth를 10% 단위로 측정하는 웹사이트가 있다 하자. 그리고 여기에 전체 월별 hit의 30%가 쓰인다고 하자. audit 시에는 이런 데이터 수집이 어떤 효용가치를 가지고 있는지 리뷰해야 한다. 이런 scroll depth tracking 때문에 샘플링 지점이나 daily hit 또는 event count가 1m을 넘어간다면, 금전적으로 이런 데이터 수집이 가진 의미를 리뷰할 수 있을 것이다.
2. Audit은 데이터 측정 전략 로드맵을 위한 사전 작업이다.
사실 어떤 웹사이트나 모바일앱이 잘못하고 있는 일만 찾자면 끝도 없이 찾을 수 있다. 그러나 이것은 진정한 audit의 효용이 아니다. 이렇게 잘못된 것만 찾자면 audit은 GA를 통계 툴로 쓰는 것과 다를 것이 없다. 따라서 audit은 어떻게 더 actionable insight를 효율적으로 얻을 수 있을까라는 답을 찾아가는 과정이다.
마찬가지로 audit 결과에 대해 방어적일 필요가 없다. 모든 조직은 maturity를 갖고 있고 그에 맞는 데이터 측정전략을 갖고 있기 때문이다. 오히려-
"우리 웹사이트는 dataLayer로 데이터를 수집하고 있어서 잘못된 게 없어"
이런 개발자 만능주의로 데이터를 수집하고 있는 곳일수록, 그 dataLayer가 일관성 없이, 잘못된 때와 장소에 아무렇게나 데이터를 밀어 넣고 있을 가능성이 높다. 안타깝게도 개발자들은 데이터 분석가가 아니다.
따라서 audit을 통해 잘못된 것만 찾는 것이 아니라 dataLayer를 꼭 써야 하는 곳에만 사용하고, 데이터 수집 시 사용자와 세션 데이터가 어떻게 수집이 될 것이며, 추후 데이터 분석을 위해 어떤 custom dimension들을 추가로 수집할 것인지 생각할 수 있어야 한다. 더 나아가, 이 GA 데이터가 다른 CRM이나 martech stack과 어떻게 연결되어 통합적인 인사이트를 만들 수 있을지 생각해야 한다.
그래서 개인적으로는 일전에 썼듯이 audit은 digital maturity 안에서 해석하고, 수정하며 개선해야 한다고 생각한다.
https://brunch.co.kr/@jaehoshindler/24
3. Automate audits as much as possible
Chat-GPT를 일에 쓰면서 더욱 느끼는 것은 결국 우리의 어떤 일들도 더 자동화되고 툴들을 통해 효율성이 재고될 수밖에 없다는 것이다. 특히 API가 있고 반복적인 작업들이라면 더욱 자동화하는 것이 맞고 그렇게 되어야 한다. 그래야 우리는 더 사람이 잘할 수 있는 일에 집중할 수 있다.
4. Practical questions
그렇다면 실제 audit을 할 때 어떤 질문들에 답을 하면 좋을까? 몇 가지 내가 주로 체크하는 포인트들을 정리해봤다.
KPI는 바르게 측정되고 있는가?
GA가 GTM으로 측정되고 있는가? 그렇다면 GTM snippet의 위치와 script는 정확하게 쓰이고 있는가?
Consent banner가 있는가? 그렇다면 consent가 데이터 수집에 compliant하게 적용되고 있는가?
Google Consent Mode가 있는가? 그렇다면 정확하게 Google tag에 적용되고 있는가?
PII가 존재하는가?
여러 domain을 사용 중에 있다면 사용자의 Client ID가 어떻게 기록되고 있는가?
여러 domain을 사용 중에 있다면 사용자의 session은 어떻게 기록되고 있는가?
Business goal이 conversion event, transaction, 또는 goal의 형태로 정확한 때와 장소에서 잘 수집되고 있는가? (i.e. product revenue vs total revenue)
20% 이상의 트래픽이 'Others' 같은 불투명한 채널로 기록되고 있지 않은가?
(not set) landing page가 20%의 session을 차지하지 않는가?
중복으로 수집하고 있는 이벤트가 있지 않은가?
육아휴직 전에 정말 하고 싶었던 일은 위의 지점들을 종합한 audit template을 새로 GA4와 GTM을 위해 만드는 것이었다. 안타깝게 시간을 내지는 못했지만, 육아휴직 중에라도 일을 마무리해야겠다는 생각이 든다.
