이 글은 Google Analytics를 사용하는 법에 대한 정의가 아닙니다. 개발과 기획간의 Google Analytics를 효율적으로 관리할 수 있는법을 정리한 것이고, GA를 사용하는 법은 저보다 훨씬 많은 분들이 더 잘 설명하고 있으니 그분들의 글을 읽어보세요!

우선 알고나 씁시다

Google Analytics가 뭐할때 쓰는거라구요?

“구글 애널리틱스(앞으론 GA라고 하겠습니다.)”는 이제는 너무나 많은 회사 및 개인들이 사용하는 유저 행동 분석 툴 입니다. GA를 사용함으로서, 서비스 제공자들은 유저들의 행동(User Behavior)파악을 통해,

1. 지금 구현되어 있는 서비스가 서비스 제공자의 의도에 맞게 맵핑(Mapping)되었는지
2. 혹시나 길을 잃은 어린양들이 고객들이 있는지.
3. 또 어느부분에서 가장 많이 이탈을 하는지.
4. 유저들은 어떤 디바이스를 사용하는지, 또는 어느나이대, 어느 국가에서 해당 서비스를 사용하고 있는지.
5. 커머스 같은 경우엔, 유저가 어떤 물건에 가장 큰 관심을 가지는지. 등 분석을 통해 다양한 정보를 확인할 수 있습니다.

이글을 읽으면 GA 짱짱맨이 되는건가요?

아닙니다(단호). 저도 GA를 잘 활용하는 법에 대해선 잘 몰라 열심히 공부하는 중입니다.

그럼 이글은 뭔가요?

GA는 기획자 또는 PM분이 잘 하신다고, 100% 효과를 얻을 수 없어요(Google Tag Manager등을 통해서는 어느정도 도움이 되지만,) 제가 알려드리려는 건, GA를 개발자님들과 기획자님들이 효율적으로 관리하고 이해할 수 있도록 하는 일에 대해서 설명드리려고 합니다.

GA 시작하기

우선 제가 설명드리는 건 무료계정의 케이스 입니다! 하나하나 천천히 설명드릴게요!

기획에서 할 일!

GA 계정 생성하기

GA를 시작하기 위해선, 해당 서비스를 위한 Analytics계정이 필요합니다. 한명의 Google 계정 당 100개의 GA 계정을 제작할 수 있고, “새계정 만들기”를 통해 새 계정을 만들 수 있습니다.

계정 ID, 사용자 관리하기

Analytics계정을 생성하고 나면, 9개의 숫자로 되어있는 계정 ID가 생성됩니다. 그리고 일단 계정을 생성하고 나면, 사용자를 관리할 수 있습니다. 사용자 같은 경우에는 회사나 개인에 따라 다르겠지만, 해당 서비스를 트레킹할때 반드시 필요한 사람들이 가장 최우선 이겠지만, 침해 받지 않는선에서 라면 저는 개발자 분들도 같이 봐 줬으면 좋겠다는 생각이 듭니다. 이유는, 아물논 볼시간이 없으시다는건 알지만 기획측면에서 놓치게 되는 것들이 있거나, 개발자분이 보았을때, 필요한 또는 필요치 않은 부분에 걸려있는것들이 있는 등, 한 파트에서 미처 해결하지 못한 부분들에 대해서 공유하고, 수정할 시간이 있다는 것 자체는 좋은 강점이라고 생각합니다!

추적 ID 확인 및 전달

서비스를 트레킹 할 Main URL을 작성하고 나면,

Google Analytics를 위한 Google Spreadsheet를 제작, 개발과 기획간의 로그에 대한 현황파악 대시보드를 제작합니다.

Spreadsheet를 기반으로 한 워크시트 작성

여기서부터가 진짜 시작입니다. 우선 GA를 사용하는 진짜 목적인 Event Tracking(행동 추적)을 위한 Tracker를 생성하는 가장 처음 작업 입니다. Event를 설정하는 방법은 각 서비스가 지향하는 부분에 따라 전부 다를 수 있으니, 제가 한 방식이 옳지 않다고 생각하시는 분은 다르게 하셔도 무관합니다! 들어가기 전에! 우린 Event라는 것에 대해 깊게 생각해 볼 필요가 있습니다!

Event가 뭥미?!

GA에서 Event란, 해당 서비스에서 이뤄지는 행동을 모두 포함한 내용 입니다! 이러한 Event는

• Category: 서비스 제공자가 추적하기를 원하는 하나의 그룹 오브젝트입니다. 저는 각각의 페이지에 대해 유저가 어떻게 움직이는지 알고싶어 “각각의 페이지”로 생각하고 작업합니다.
• Action: 해당 Category 안에서 유저가 행동할 수 있는 부분들에 대한 집합입니다. 저는 처음에 “페이지에서 눌리는 모든것들”로 생각하고 작업합니다.
• Label: 해당 Event가 단순히 “키값”만 있게 되었을때 생기는 오류들을 없애기 위해 만들어 놓은 부가적인 설명입니다. 모든 Event에 적게 되면, 코드수가 상당수 늘어날 것이니, 상단에 있는 워크시트에 작성하는것도 좋은 방법이라고 생각됩니다(전 그렇게 하거든요ㅎㅎ 이유는 우리가 트레킹을 하는 이유는 유저가 잘 쓰게 하기 위한것인데, 트레킹을 위해 유저가 서비스를 접하는 시간이 조금이라도 늘어나는건 좋지 않겠죠?). 이방법 외에도 Action에서 해결되지 않은 분기나 댑스등을 처리할때도 사용합니다. 다시한번, 서비스에 맞게끔, 내가 필요한 상태로 쓰는게 최고 입니다.
• Value: 위 내용과는 조금 다른 부분들 일텐데요, 예를들어 다운로드가 있는 링크에서, 유저가 몇개를 다운로드 했는지 등을 수치적으로 파악할 수 있는 태그라고 합니다. 저는 사용해 본적이 없어서 정확히 말씀드리진 못하겠네요. 이런식으로 GA는 이벤트를 정의하고, 개발자분들은 해당 Event가 Category인지, Action인지 등을 확인하고 트레커를 붙이는 작업을 진행합니다.

  걍 JIRA나 테스크 툴로 하지 굳이 워크시트를 만드는 이유가 뭐죠?

  하셔도 됩니다. 다만, GA를 보다 확실하고 정확하게 적용하기 위해선, GA를 테스팅하고, 보다 디테일하게 Event에 대해서 확인할 시간과 로깅을 해놓을 공간이 필요합니다.

1. 작업을 시작하기 전에 정확하게 해당 이벤트에 대한 정의가 확실한지

   정의가 확실치 않으면 개발쪽에서 작업을 진행할때, 오류가 생기고 오류가 생긴것을 파악하지 못하면, 잘못된 정보를 파악하게 됩니다. 작업전에 반드시 협의가 필요합니다.

2. 해당 Event를 위해서 필요한 일들이 생기는지/ 그 Event가 반드시 확인해야 하는 Event 인지

   상단에는 “눌릴 수 있는 모든것들” 이라고 했지만, 유저가 굳이 틀릭을 하지 않아도, 또는 클릭하는 버튼 자체도 그 컴퍼넌트 자체가 Tracking이 가능하지 않은 부분들이 존재합니다. 해당 Event를 트래킹 하기 위해선 Event를 위한 작업이 필요할 때가 생기는데, 불필요한 코드등이 생길 수 있으니 해당 부분에 대해서도 반드시 필요한지를 고려하고 작업해야 합니다.

3. 해당 Event Tracker가 언제 들어가고 언제 문제가 있어서 수정했는지

   지라등으로 따로 테이블을 만들어 수정하다 보면, 피쳐 단위에서 필요한 Event Tracker가 변경될 수 있고, 특정 Tracker만 작동이 안되는 등 세세하게 작업해야 하는 상황에선 확인이 힘듭니다. 그리고 각 피쳐가 언제 들어갔는지, 언제 들어갈 예정인지를 안다면 해당 기능에 대한 행동 파악에 더 용이합니다.

등등 워크시트를 만드는 이유는 더 많이 있습니다만, 글이 더 길어지면, 안읽으실것이란것을 알기에 생략하겠습니다.

Spreadsheet 구조 짜기

저는 모바일 플랫폼에서 GA를 사용했기 때문에 전에 사용했던 방식으로 기입하겠습니다. 이후 파이어베이스를 기반으로 한다든지, GTM을 기반으로 하는작업을 하게 된다면 이후에 리뷰를 적도록 할게요!

시트구조 파악하기

• GA all: 각각의 플랫폼이 다 잘 적용이 되었는지 한눈에 파악할 수 있는 대시보드 입니다. (관리자 or 기획자가 많이 보겠죠?)
• GA Android: Android의 GA 적용여부를 파악하는 시트 입니다.(Andrid 개발자와 기획자, 그리고 QA가 확인하겠죠?)
• GA iOS: iOS의 GA 적용여부를 파악하는 시트 입니다. (iOS 개발자와 기획자, 그리고 QA가 확인하겠죠?)

  Column 파악하기

  Column은 이벤트의 나열 입니다. 이벤트역시 각각의

  Row 파악하기

  Row가 매우 중요합니다!(잘 안댓으면 누구 책임인지 알 수 있거든요…)각각의 Row는 어느기간에 해당 업무를 진행할 것인지, 언제까지 진행할 것인지, 그리고 가장 중요한 얼만큼 진행이 되었는지를 소통할 수 있도록 구성합니다.

• Event: 이젠 친근하시죠? GA가장 핵심인 Event에 대한 카테고리 입니다.
  • Category: 페이지로 생각하시면 됩니다.
  • Action: 해당 페이지에서 할 수 있는 행동 이라고 생각하시면 됩니다.
  • Label(Description): Category와 Action만 봐도 알수 있으면 좋지만, 그렇지 못할경우를 대비해 적는 Label 또는 설명 입니다.
  • (Value): 저는 써본적이 없어서… 패스…
• Status: 해당 Event의 현황 여부를 파악하는 상태 입니다!
  • Open: 아직 개발이 되지 않는 상태 입니다!
  • In Progress: 개발자 분들이 작업을 시작한 상황입니다!
  • Done: 해당 로그작업이 완료 된 상태 입니다!
  • Reopen: 로그작업이 테스팅 중 정확하게 잡히지 않을 때, 테스팅 단에서 다시 오픈을 시킨 상황 입니다.
  • Resolved: 테스팅을 통해 확실하게 로그작업이 완료되었을 때 입니다!
• Target Release: 해당 로그를 업로드 해야하는 시점입니다! 각각의 회사나 개인이 사용하시는 개발 주기를 사용하시면 될 것 같네요 (이터레이션 이라든지, 스프린트 라든지, 아니면 마일스톤 날짜도 상관없겠죠?)

마지막에 예시로 만든 Google Spreadsheet를 작성해 놓았습니다. 여기다 링크를 올려두면 안읽으실 것 같아서 마지막에 놓았어요 왜냐면 다음부터가 진짜 중요한 거거든요

자 그렇다면, 이제 어떤식으로 진행하는지를 봅시다.

항상 말씀 드리는 내용인데,우리가 소통을 하는 이유는, 서로 말만 들으려고하는게 아니에요, 결국은 소통을 통해 이해를 하고, 업무든 관계든 발전된 상태가 되는것이 우리가 진짜 소통을 하는 이유 입니다. 그리고 잘 소통하려면 어떤식으로 사용하는지에 대해 아는게 중요해요. 으으 설명충 극혐

그림으로 설명하자면 이렇습니다!

단계로 보시면 4단계 라고 이야기 할 수 있습니다.

• 스팩 브리핑: 기능 개발 또는, 개선 과정 중에서 나오는 Event들을 정의하고 정리하는 과정입니다. Android, iOS는 각각의 너무나도 다른 플랫폼이고, 개발자 분이 어떤식으로 구현하느냐에 따라서 어플리케이션 안에서의 속성도 매우 다르기 때문에, 한개의 액션에도 각 개발자가 서로 다른 포인트가 있을 수 있고, 정말 필요한 로깅 Event인지도 다시한번 이야기 할 내용들이 있기 때문에, 개발자에게 “이거 해주세요”라고 툭 던지기 보다는 “이런걸 하고 있고 이걸 넣었으면 해요”를 이야기 하고, “이건 이런거 때문에 힘들것 같아요”,”이건 로깅을 위한 개발일정을 더 넣어주셔야 해요” 등 어떤식으로 구현되고 있는지, 무엇을 구현했는지에 대해 이야기 할 시간이 반드시 필요합니다. (이 과정에서 기획을 하는 입장에선 서비스를 어떻게 구현하고 있구나를 파악할 수 있으므로 정말 스스로에게는 유익한 시간이 될거에요. 이 시간을 허투로 쓰지 마세요.)
• 스팩 리뷰: 우리의 기획서는 항상 똥망이듯이(음…?) 분명히 GA에서도 기능에 문제가 발생할 수 있는 상황이 있을 수 있어요. 그래서 브리핑 때 나온 이슈들을 정리하고(1),
• 개발:
• GA 검수:

개발자님들에게 전달드려야 하는 SDK Documentation - 어플리케이션

• Android: GA-Android
• iOS - Swift : GA-iOS