GA4로의 이전 계획과 일정 어떻게 잡아야 할까?
구글 애널리틱스 4로 이전하기 1 - Migration plan
프롤로그.
GA4 migration이라는 표현을 한국어로 한참 생각했는데 마땅한 게 떠오르지 않았다. migration의 사전적 의미인 이동, 이주로는 표현이 적당하지 않고, 전환을 쓰는 곳도 있는데 해당 의미를 가진 영어단어(convert)를 생각하면 혼란이 있을 것 같다. 일단은 '이전'이라는 표현을 쓰기로 했지만 중간중간 계속 migration이라는 표현을 쓸 것 같아 미리 양해를 구한다.
이미 아시는 분도 있으시겠지만 일과 관련된 글을 쓸 때에는 실제 영국에서 일할 때 쓰는 용어를 쓰는 경우가 많다. 잘난 척 때문은 아니고, 나중에 해당된 내용을 영어로 찾아보실 때 미리 용어를 접해놓으면 훨씬 쉽기 때문이다. 아직 시작단계에 있는 한국보다 유럽이나 미국은 Digital Analytics의 역사도 오래됐고, 자료도 풍부하다. 바라기는 내가 쓰는 글들이 작은 도움이 되어 유럽과 미국에서 일하는 한국 분들이 더 많아졌으면 좋겠다.
여름휴가를 다녀오고 게으름과 바쁨 어느 중간 사이에 있다가 더 늦게 전에 이 주제에 대해 글을 써야겠다 생각했다. GA3에 해당하는 Universal Analytics (UA)의 종료가 내년 7월 1일로 잡혀있고, 이미 GA360 (프리미엄) client 중에는 계약 연장 시 UA로 360 계약을 올해부터 할 수 없다 (공식적으로는). 이 말은 360 feature에 해당하는 BQ linking, Hit threshold 등이 standard 기준으로 불가한 경우가 늘어났다는 의미이다. 동시에 GA4는 빠른(?) 속도로 매달 업그레이드를 내고 있다. 지난주를 기준으로 아래와 같이 Conversion rate을 default report에 포함할 수 있게 되는 등, 사용성이 좋아지고 있다. 이에 내년 초부터는 GA4를 메인 플랫폼으로 쓰는 회사들이 늘어나리라 생각한다.
Conversion rate은 Customize Report를 통해 metric으로 넣을 수 있습니다킥오프와 질문들.
GA4 migration을 고려하는 analyst 또는 담당자라면 전반적인 일정을 어떻게 계획해야 하나부터 고민하게 된다. 큰 틀에서 좋은 계획과 일정이 나와야 시간을 효율적으로 쓰고 구글 애널리틱스를 사용하는 다른 팀들과도 협업하기 용이하기 때문이다. 그 시작점은 프로젝트 킥오프 미팅이다. 미팅을 통해 일반적으로 아래의 질문들을 확인해야 한다.
어떤 제품을 이전해야 하는지? (Domain 또는 Mobile apps의 리스트)
본 프로젝트에서 이루고 싶은 목표나 우선순위가 있는지?
현재 UA에서의 데이터 수집과 활용에 대해 개선점이 필요한가?
현재 UA에서의 데이터 수집에 대한 documentation이 있는지?
GA4 이전 시에 고려되어야 할 주요 reporting이 있다면?
주요 사용자 journey가 어떻게 측정되고 있고 개선되어야 하는지?
다른 제품과의 integration이 있는지?
Dashboard에는 적용되고 있고 고려해야 할 점이 있는지?
특히 프로젝트에서의 목표나 우선순위는 간과하기가 쉽다. 흔히 이런 프로젝트에 무슨 목표가 있겠냐고 생각하기 쉽지만, 예산이나 목표 일정, 데이터의 품질 확보 등 회사 내부의 우선순위는 그때 그때 다를 수 있기 때문이다. 이를 킥오프 미팅을 통해 바로 정의하고 PM이나 Account manager들을 통해서 관리하도록 할 필요가 있다.
또한 현재 UA에서 데이터 수집과 활용에 대해 개선점을 확인하는 것 또한 중요하다. 심지어 consultancy를 두고 있다고 하더라도 그 점이 현재 UA에서 데이터 수집이 문제없이 잘 되고 있음을 보장하지 않는다. 해당 질문을 통해 스스로 또는 client에게 현재 UA에서의 데이터 수집 시 문제점들이 있을 수 있다는 것과 그것을 GA4로 고스란히 이전해서는 안된다는 것을 주요 이해관계자들에게 설득해야 한다. 이 점은 앞서 GA4로 이전 시 측정 전략을 리뷰할 수 있는 좋은 기회로 삼아야 한다는 Doug의 글과 일맥상통한다.
https://brunch.co.kr/@jaehoshindler/16
프로젝트 마일스톤과 일정.
킥오프 미팅을 통해 해당 프로젝트의 목표와 주요 마일스톤에 대해 이해관계자들의 동의를 얻었다면 실제 프로젝트의 일정을 tracker를 통해 구체화하고 관리해야 한다. 여기에는 각 회사나 팀에서 쓰는 template을 자유롭게 쓰면 되는데, 나의 경우는 아래와 같은 template을 쓰고 있다.
Blockers are everywhere주요 프로젝트 마일스톤은 아래와 같다.
1. 프로젝트 킥오프
2. GA4 MVP로 implementation (1시간 / 1 property)
GA4의 가장 주요한 특징은 Config tag 하나로 페이지뷰에서 몇 enhanced events들을 자동으로 수집할 수 있다는 것이다. 굳이 full migration이 끝나고 나서 데이터 수집을 시작할 이유가 없다.
The earlier the better.
3. 현재의 UA audit 하기 (1-2일 / 1 property)
현재 어떤 데이터를 어떻게 수집하고 있는지, 불필요하거나 필요한 데 없는 데이터는 없는지, 더 나은 수집 방법은 없는지에 대해 답하고 해결안을 내는 과정
방어적(?)이 되지 않을 준비를 해야 한다. 더 중요한 건 improvement.
4. Measurement requirement documentation (2일- / 1 property)
audit을 바탕으로 한번 정하면 바꾸기 어려운 account structure를 정리하는 일은 가장 먼저 해야 하는 작업이다. 특히 GA4는 UA와 account structure가 다르기 때문에 이를 business requirement를 고려해야 정하는 것이 중요하다.
기존 measurement document가 있든 아니든, 어떤 데이터를 어떻게 수집할 것인가를 정리하는 일은 지속적으로 중요하다.
개발팀을 위한 technical implentation documentation도 포함된다. 개발자의 언어를 이해하고 그들을 과소평가하거나 과대평가하지 않는 것이 참 중요하다.
5. Implementation (2일- / 1 property)
Google Tag Manager (GTM)을 자신감 있게 쓸 수 있다면 실제 implemenation은 매우 단순해질 수 있다.
Account structure를 반영해 GA4 property에서 기본적인 세팅을 하고, 이를 config tag에 반영해야 한다.
audit 결과를 바탕으로 dataLayer를 추가/수정하는 일도 필요하지만 되도록이면 줄이는 것이 좋다. dataLayer는 만능간장이 아니다.
6. GA4 property 세팅 (1일- / 1 property)
이 단계에서는 앞선 기본적인 작업이 아니라 Custom Dimension이나 conversion event 등 구체적인 measurement configuration에 집중해야 한다.
7. QA
8. Deployment
9. 확장
migration project를 진행했을 때 대체로 3주에서 4주 정도의 일정을 잡는다 (Full migration 여부와 documentation, client maturity, resource에 따라 일정은 가변적이다). 단위 당 소요시간보다 더 걸리는 이유는 우리가 이 프로젝트만 하는것이 아니기 때문이다. BAU (Business As Usual)이 있는 데서 진행하다 보면 사실 일정은 지연되면 지연되지, 당겨지지는 않는다. 따라서 적당한 프로젝트 일정 수립을 통해 이해관계자들의 기대치를 현실적으로 잡아놓을 필요가 있다.
다음 글에서는 GA4 MVP에 대해 다뤄볼 예정이다. 언제일지 장담할 순 없지만.
