구글 애널리틱스4 101

내 관점의 GA4 핵심 요점 정리 (1)

임신, 출산, 육아 관련 글들만 쓰다 보니 일은 하지 않는 것처럼 보이겠지만, 사실 복직한 지도 네 달이 지났고 나름 바쁜 나날들을 보내고 있다. 최근 내가 맡고 있는 클라이언트들을 대상으로 GA4 training(교육)을 시작했는데, 성격이 별난 탓인지 기존 회사 자료를 다 뜯어 고치고 있다. 요즘처럼 조직이 profitability를 강조하는 타이밍에 내 시간을 써가면서 이렇게 하는 것이 의미가 있는 지는 모르겠지만, 이상하게 회사의 기존 자료는 뭘 말하고 싶은 지 모르겠더라. 그래서 내가 하고 싶은 말 위주로 싸악 갈아엎었다. 그런 불필요한 작업을 하고 나니, 누군가에게 내가 생각하는 핵심이 도움이 될 수 있겠다는 생각이 들었다. 

1. 어쨌든 게임은 계속된다 (Continual Improvements)

UA가 사라지면서 많은 사람들이 패닉에 빠졌다. 아마 maturity가 낮은 회사의 경우, 갑자기 데이터가 프로세싱 되지 않아 놀란 곳도 있지 않을까 싶다. 그런 사람들을 위해 이런 재미있는 패러디 영상도 나왔다지. 

Sunset @YouTube https://www.youtube.com/watch?v=_nAtC2Ps_x4

구글의 내부적 이유 때문이든 시대의 변화 때문이든, 어쨌든 새로운 시대가 되었다. 하지만 그렇다고 해서 본질이 변하는 것은 아니다. Avinash Kaushik이 이야기 했듯이 Digital Analytics의 목적은 data analysis를 통해 Customer journey와 business outcome의 지속적인 개선 작업(continual improvement)을 이뤄내는 것이다. 

간혹 digital analytics를 one-off project로 생각하는 회사나 조직을 만나게 된다. 거금을 투입해서 우리 같은 컨설팅 회사를 써서 밑그림을 다시 그리고 색칠도 열심히 해놓았다. 그러고는 어디 다락방에 처넣고 쳐다보지도 않는다. 그림을 산화되고 변색되어 점점 예전의 그림을 상상할 수 없게 된다. 심지어 감상용인 그림마저 그런데, 살아있는 데이터는 어떨까. 고객과 사용자가 변화하는 만큼 데이터도 끊임없이 사용하고 수정하고 개선해야 하는 작업이 동반되어야 한다. 안타깝게도 많은 회사가 이 지속적인 작업에 돈을 쓰지는 않는다. 결국 처음 투자한 돈을 버리는 일이다. 

2. GA4를 소수가 좋아합니다. 

구글에서 강조하는 GA4의 가장 큰 selling point는 cross-platform journey measurement에 최적화 되어있다는 것이다. UA의 analytics.js library가 웹사이트를 기반했고, Firebase가 애초에 분석툴이 아니라 모바일앱용 서버와 지원툴이어서 모바일앱 에코시스템에 기반했다면, GA4는 그 어디 중간 지점 즈음에 있다. 데이터 구조나 인터페이스는 Firebase와 유사하지만, 데이터의 dimension/metric 들은 UA와 유사한 점이 많다. 덕분에 웹과 모바일앱을 번갈아 가며 쓰는 사용자들의 행동을 분석하는데 장점이 있고, reporting identity 등 많은 feature들이 이를 지원하기 위해 존재한다. 

뒤집어 생각해보면 얼마나 많은 회사들이 모바일앱과 웹사이트를 오가는 사용자들을 가지고 있을까. 개별 플랫폼 사용자들을 가지고 있을 수는 있겠지만, 이 플랫폼들을 오가는 다수의 사용자를 지닌 제품은 시장에서 많지 않다. 사용자층이 폭넓고 유달리 cross-platform journey를 보이는 회사들 - 한국의 경우 소수의 커머스 회사 제품들이 그렇겠고, 포털이 해당된다. 그 외 웹사이트 또는 모바일앱만 갖고 있는 회사는 이전 버전에 비해 GA4의 매력이 다소 감소할 수 있다.

더 나아가 유연하고 customisable한 인터페이스는 호불호가 강하게 갈린다. customisable 하다는 것은 user-friendly라는 말과 대척점에 있다. 대중은 대충 쓰기에 좋은 제품을 편하게 여긴다. 뭔가 내가 쓰기 편하게 손을 대야 한다? 불편하다. 따라서 뭔가 우리 회사의 business language에 맞춰 left-sided navigation을 바꾸는 것은 좀 '별난' 소수에 해당된다. 

GDPR과 같은 개인정보나 privacy 관련 규제에 대응하기 위한 제품 특징을 강조하는 것도 그렇다. 사실 GDPR이 미국 캘리포니아 주의 CCPA 같은 개인정보 보호추세와 관련된 트렌드를 야기한 것은 맞지만, 유럽 밖을 제외하면 이 부분에 대한 적극적 대응이 필요한 곳이 얼마나 될까. 확실히 유럽 안에서는 너무 중요한 이슈이고 정말 시장을 가끔 혼란하게 만드는 문제이지만, 가끔 유럽 밖의 사람들에게 GA4가 이 부분을 잘 대응하고 있다고 홍보하는 것이 어떤 느낌일까 생각하게 된다. 

이에 GA4가 굉장히 보편적인 제품이라기 보다는 소수의 사용자 집단과 그들의 context에 필요한 제품으로서의 강점을 가진 제품이라는 생각을 하게 된다. 

3. UA vs GA4

그렇다면 GA4, UA보다 무엇이 어떻게 다를까. 

1) Account Structure - View가 없다

Account나 Property는 같지만 view가 없다는 것은 account structure를 설계하는 입장에서는 매우 난처하다. 1 property 당 25개까지 만들 수 있었던 view는, 데이터를 수집하고 테스트하고 필터링하고 별도의 리포팅을 하는데 큰 도움이 되었다. 때로는 너무 남발하는 것이 문제가 되긴 했지만. 

그래서 GA4에서 subproperty가 등장하는데, 이를 view와 같은 기능으로 교육하는 곳이 있다면 무조건 도망가시길 바란다. 또는 data stream이 그런 역할이라고 교육하는 곳도 피하시길 바란다. 둘 다 전혀 다른 목적을 갖고 있는 제품 feature들이다. subproperty는 구글에서 강조하듯, data governance 목적이다. 다국적 기업의 경우 지역별 access가 민감한 이슈일 수밖에 없고, 이 때문에 별도의 데이터와 access가 필요한 경우 유료인 subproperty의 사용이 권장된다. subproperty는 billable events를 50% 더하기 때문에 무료도 아니다. 360 라이센스를 쓰더라도 25개씩 쓰는 남발은 절대 허용될 수 없다. 

Data stream은 말 그대로 데이터의 출처라고 보는 것이 타당하다. Web, iOS, Android 3가지 중에 만들 수 있고, Cross-domain/sub-domain tracking을 위해서라면 심지어 한 data stream을 써야 한다. 

그렇다면 view와 같은 별도의 리포팅은 어디에서 해결해야 할까. 답은 Explore이다. 

2) 새 data model - Event

 널리 알려져 있듯이, GA4는 기존의 hit이라고 불리던 데이터가 event로 정리된다. 모든 것은 event이다. 심지어 page_view도 event이고, new user나 new session이 시작되는 것도 event로 수집한다. 그리고 각 event에게 더 자세한 정보들은 parameter로 수집된다. 이 parameter는 기존 dimension으로 수집되기도 하고 (예: page_location), custom dimension/metric으로 수집해야 하기도 한다. 그리고 event category, action, label이 모두 사라졌기 때문에 대신 event name 을 어떻게 정의하느냐가 중요해졌다. 어떻게 보면 단순해진 거고, 어떻게 보면 event_name 하나 안에 다른 event들과 차이를 어떻게 둬야할 지 naming convention이 중요해진다. 

처음 GA4가 소개될 시에 꽤 중요한 개념으로 다뤄졌던 event type은 요즘은 상대적으로 중요도가 떨어진다. 처음엔 custom event가 500개까지만 가능했기에, 기존에 구글이 정의해놓은 event type 안에서 수집하는 것이 매우 중요했다. 물론 이 caveat은 여전히 모바일앱 데이터 수집시 유효하다. 다만 웹에서는 적용되지 않기 때문에, 상대적으로 유연해진 상황이다. 

그럼에도 불구하고, enhanced measurement를 통해 어느 정도 자동으로 수집될 수 있는 event들이 있다는 점에서, 어떤 event를 enhanced measurement로 자동으로 수집할 지 아님 GTM으로 수동으로 수집할 지에 대해서는 고민이 필요하다. 답은 enhanced measurement보다 더 customisation이 필요하다면 GTM으로 하고, 아니라면 enhanced measurement를 사용하면 된다. 예로, scroll event의 경우 enhanced measurement를 사용하면 90% scroll depth만 자동으로 측정하게 되어있으나, 25%/50%/75%도 수집하기 원한다면 GTM으로 따로 수집해야 하는 것이다. 

더 나아가 구글에서 정해놓은 naming convention을 따라가는 것은 GA4에서 강화된 예측 모델링과 관련이 있다. Predictive audience로 대표되는 GA4의 ML을 기반으로 한 예측 모델은 당연히 데이터의 standardisation에 기초할 수 밖에 없다. 예를 들어 구매 완료 데이터의 경우 A회사는 'purchase'라는 evnet name으로 수집하고, B회사는 'transaction'이라는 event name으로 수집한다고 하자. 구글이 이를 바탕으로 모델링을 할 수 있을까? 할 수는 있지만 예외조건들을 계속 넣어야 하니 data cleansing에 더 많은 수고가 들어갈 것이다. 이에 어느 정도 데이터의 standardisation이 필요한데 여기에 event name과 거기에 필요한 parameter 정리가 필수라 할 수 있다. 따라서 구글의 predictive modelling에 도움을 받고 싶다면 이 naming convention을 잘 따라가는 게 중요하다 할 수 있다. 

할 말이 더 많지만 더 쓰면 보는 분들이 부담스러울 수 있으므로, 나머지는 2주 뒤에 쓰는 걸로 :-)

궁금한 점들이 있으면 댓글 남겨주세요.