GA 기본구조를 부탁해
야, 너도 GA 할 수 있어 ②
구글 애널리틱스(이하 GA)에 대한 스터디를 진행할 때면 생각보다, 더 기초적인 부분부터 헤매기 시작하시는 분들이 많곤 합니다. 특히 처음 접속하는 것부터 어려워하시는 분들이 은근히 많습니다. 마치 스마트폰이 처음 나오던 시절, 전화를 받지 못하는 분들이 많았던 것처럼 말입니다.
더욱이 GA는 그냥 로그인한다고 무작정 쓸 수 있는 솔루션이 아닙니다. 알맞은 속성이나 보기를 찾아 들어가야 합니다. 선택하는 것에 따라 완전히 다른 데이터가 나오기 때문입니다. 그래서 보통 바로 실무에 적용하기 위한 스터디에서는 언젠가부터 '00 보기로 그냥 들어가셔서 보시면 됩니다'라고 말해버립니다. 오히려 계정 - 속성 - 보기로 이어지는 GA의 기본 구조를 설명하면 더 헷갈려하시기 때문입니다.
하지만 그렇다 하더라도, 이왕이면 GA의 기본구조에 대해 이해하고 사용하는 것이 당연히 더 좋습니다. 모르고 쓸 때보다 더 효과적으로 활용할 수 있기 때문입니다. 특히 기본구조는 GA 구축 프로젝트를 진행하거나, 고도화를 꾀할 때는 꼭 이해하고 넘어가야 합니다. 그래서 내가 GA 계정 관리 담당자라고 하면 이를 완벽히 파악하고 있어야 합니다. 처음에는 낯설어서 어렵지만, 알고 나면 간단한 GA의 기본구조, 지금부터 한번 배워보도록 하겠습니다.
01 GA 기본구조가 헷갈릴 땐 냉부해를 떠올려 보세요-
지금은 추억이 되어버린 프로그램이지만, 한때 인기가 대단했습니다 (출처: JTBC) GA의 기본구조를 설명할 때, 저는 예전에 유행했던 예능 프로그램 '냉장고를 부탁해'를 빗대곤 합니다. 상당히 비슷한 구조를 가지고 있기 때문입니다. 이제는 종영을 한지 꽤 오랜 시간이 지난 터라, 프로그램에 대해 간략히 설명을 드리면, 초대된 게스트들의 냉장고 안 재료만을 사용하여 유명 셰프들이 요리 대결을 펼치는 겁니다. 여기서 포인트는, 오직 냉장고 안에 있는 재료들만 사용 가능하다는 점이고요. 본격적인 조리를 하기 전에 셰프들은 본인이 사용할 재료들을 담아 가져옵니다.
GA의 기본구조는 여기 나오는 셰프 - 냉장고 - 재료의 관계와 매우 유사합니다. GA의 기본구조는 계정 - 속성 - 보기로 이루어져 있는데요. 계정은 우리가 하나쯤 가지고 있는 구글 아이디이고, 속성은 데이터를 담은 저장공간, 보기는 이러한 속성 기반의 보고서를 말합니다. 따라서 계정은 셰프와 같습니다. 사람을 의미하고, 셰프 별로 당일에 사용 가능한 게스트들의 냉장고가 정해져 있듯이, 속성에 대한 권한을 부여 받을 수 있습니다.
냉장고에 아무리 재료가 없어도, 오직 그것만 사용해서 요리해야 합니다 (출처: JTBC) 계정은 우리가 흔히 접하는 개념이니 쉽게 이해가 되시죠? 하지만 속성부터는 조금 혼동되기 시작하실 텐데요. 속성은 데이터를 담은 통을 뜻합니다. 음식 재료들이 모인 냉장고 같은 개념이죠. 우리가 기억해야 할 포인트는 냉장고 밖에 있는 재료를 요리에 사용할 수 없듯이, 속성에 쌓인 데이터만 분석 시 활용 가능하다는 점입니다. GA에 데이터를 남기기 위해서는 우리는 태깅 작업을 해야 합니다. 하지만 새로 태깅 작업을 했을 때, 적용되는 건 작업 이후 시점의 수집되는 데이터뿐입니다. 따라서 상당한 제약 안에서 우리는 데이터 분석을 할 수밖에 없습니다. 마치 냉장고 안에 있는 재료만 사용 가능한 셰프의 상황처럼 말입니다. 물론 이 둘이 다른 점도 있습니다. 냉장고 안에 무슨 재료가 있을지는 셰프들이 미리 알 수 없지만, GA의 속성에 어떤 데이터가 쌓일지는 예측 가능하다는 점입니다. 여기에 어떤 데이터를 쌓을지 기획하고 설정할 수도 있습니다. 따라서 속성을 정의하는 것은 GA 구축에 있어서 가장 주요한 의사결정이기도 합니다.
마지막으로, 보기는 개별 보고서 단위라고 보면 됩니다. 물론 보고서라고 해서, 정형화된 리포트는 아닙니다. 앞서 셰프들이 본격적인 조리를 시작하기 전 냉장고에서 미리 재료를 담아온다고 했던 거 기억하시나요? 셰프들은 어떤 요리를 할지 레시피를 정리한 후, 냉장고에서 필요한 재료들을 선별하여 담아온 뒤, 그것만 사용해야 합니다. 보기도 이와 같은 똑같습니다. 속성에 담긴 수많은 데이터들을 일정 필터 기준에 따라 보기로 가져옵니다. 우리는 보기에서 확인 가능한 데이터를 가지고 생각한 레시피대로 분석을 진행하고 적용점을 도출하게 됩니다. 그리고 보기도 속성과 동일한 제약 요건을 가집니다. 보기를 생성한 시점 이후의 데이터부터 확인 가능하다는 점인데요. 요리 재료를 한번 가져오면 추가적으로 가져오지 못하고, 꼭 그 안에서만 조리를 해야 하는 셰프들의 고충을 우리도 겪어야 한다는 걸 의미합니다. 이렇게 되돌릴 수 없는 특성을 가진 GA이기 때문에 우리는 무엇보다 처음부터 잘 관리할 수 있는 체계를 구축해야 합니다. 그렇다면 계정, 속성, 보기를 잘 관리하기 위한 팁들에는 무엇이 있을까요?
02 귀찮지만 꼭 해야 할 계정 관리
계정은 솔직히 기본구조 3대 요소 중 가장 쉬운 개념이긴 합니다. 하지만 은근 손이 많이 가고 귀찮은 것이기도 한데요. GA라는 도구 특성상 우리가 지속적으로 신경 써줘야 하기 때문입니다. 보통 GA를 1명이 혼자 쓰는 경우는 흔치 않습니다. 물론 개인 홈페이지에 적용할 때도 있지만, 회사에서 사용하는 경우 여러 명이 동시에 GA를 필요로 합니다.
제가 일하는 이커머스 만 하더라도, 마케터, 개발자, MD, 서비스 기획자 등 거의 대부분의 직군에서 GA를 필요로 합니다. 이렇게 GA를 활용하려면 접근 권한을 가진 계정이 필요합니다. 계정을 공유하는 방법은 크게 2가지가 있습니다.
접근 권한을 가진 계정 자체를 공유
가장 쉽게 떠올릴 수 있는 방법은 하나의 아이디를 돌려 쓰는 겁니다. 이 방법의 장점은 소수의 계정으로 운영 가능해서, 관리가 용이하다는 것과 맞춤 보고서 등 개인화된 설정 등을 바로 공유 가능하다는 겁니다. 하지만 단점도 있으니, 개개인 별로 맞춤 설정 기능을 구현하기엔 너무 메뉴가 복잡해지고요. 아이디와 비밀번호를 공유하면 보안 상의 이슈가 생길 수밖에 없습니다.
구글 계정에 권한을 부여
그래서 구글은 계정을 추가할 수 있는 기능을 제공합니다. 계정에 부여하는 권한 자체가 세분화되어 있고요. 방법도 매우 손쉽습니다. 메일 주소를 넣고, 해당하는 권한을 체크한 후 확인 버튼을 클릭하면 끝이거든요. 이렇게 하면 개인 별로 맞춤 설정도 가능하고요. 또한 기존에 생성한 보고서나 대시보드 등을 공유하는 기능 또한 강력하기 때문에 솔직히 이 방법을 보통 많이들 사용합니다.
다만 여기서 우리는 계정 관리에 주의를 기울일 필요가 생깁니다. 특히 회사에서 직원 개개인 계정에 권한을 부여하는 경우, 부서 이동이나, 보직 변경, 퇴사 등의 이유로 지속적으로 리스트 관리를 해줘야 합니다. 또한 신규로 권한을 부여해야 하는 경우도 매우 자주 생깁니다. 은근히 이 부분을 간과했다가, 나중에 크게 문제 생기는 경우가 간혹 있는데요. 혹시나 권한 리스트를 수시로 관리하고 있지 않으시다면, 지금이라도 바로 체크하시기를 꼭 추천합니다.
03 속성은 GA의 시작이자, 끝입니다!
앞서 계정 관리의 중요성에 대해 말씀드린 바 있는데요. 사실 가장 우리가 중요하게 챙겨야 할 요소는 역시 속성입니다. 속성은 앞서 냉장고 같이 데이터를 저장하는 통이라고 말씀드렸는데요. 속성은 오로지 그 안에 쌓인 데이터 만을 이용할 수 있고, 처음부터 수집하지 않은 데이터는 결국 영원히 쓰지 못합니다. 따라서 최초 설정 시 가장 주의를 기울여 살펴봐야 하고요. 보통 맞닿뜨리게 되는 몇 가지 딜레마에 관해 설명드릴 테니, 한번 내가 관리하는 GA 계정에 해당되는 내용이 없나 확인해보시면 좋을 것 같습니다.
매체별로 한 바구니에 담을 것인가 vs. 나눠 담을 것인가
가장 쉽게 부딪히는 문제는 매체 별로 속성을 생성할 것인가, 아니면 하나로 합칠 것인가의 문제입니다. 과거 PC만 있던 시기에는 사실 이와 같은 고민 자체가 필요가 없었습니다. 하지만 스마트폰의 등장 이후 모바일과 APP이라는 새로운 매체가 등장하면서, 우리는 데이터를 어떻게 쌓아야 할지 고민이 생기게 되었습니다. 물론 일장일단이 있지만, 일단 하나의 속성에 쌓는 것을 일반적으론 추천드립니다.
매체 별로 속성을 따로 생성하여 데이터를 쌓으면, 각각을 명확히 측정하여 비교할 수 있다는 장점은 분명 있습니다. APP 사용자와 모바일 사용자, PC 사용자를 명확하게 구분할 수 있고, 개별 매체 별 특성을 확인 가능합니다. 하지만 하나로 합치는 경우, 이를 분리해서 보는 건 상당한 에너지가 필요합니다. 더욱이 GA는 기본적으로 디바이스 별로 볼 수 있는 기능은 제공하지만, APP을 별도로 분리하여 보려면 개발자의 도움을 받아서 구분할 수 있는 요소를 넣어서 따로 구축해야 합니다. 또한 이 부분은 해결하더라도, 매번 데이터를 볼 때마다 분리해서 봐야 하고, 그러면 샘플링도 더 쉽게 되기 마련입니다.
여러 디바이스를 쓰더라도 하나의 사용자일 수 있기에, 정확한 분석을 위해선 한 곳에 데이터를 쌓아야 합니다 (출처: Econsultancy) 하지만 그럼에도 불구하고 우리가 하나의 속성에 데이터를 쌓아야 하는 이유는 명확합니다. 바로 크로스 디바이스 분석을 해야 하기 때문입니다. 속성을 각기 따로 생성하면, 하나하나는 자세히 볼 수 있는 반면, 이들을 묶어 분석하는 건 불가능합니다. 하나의 서비스, 플랫폼인 특성은 갖고 다만 접속하는 매체가 다른 것이기 때문에 이들의 행동을 묶어 분석할 수 있어야 합니다. 물론 단지 하나의 속성에 데이터를 쌓는다고 이러한 분석이 가능한 건 아닙니다. 고객의 로그인 ID를 수집하는 등, 묶을 수 있는 기준은 따로 만들어야 합니다. 하지만 일단 이 부분도 구축만 한다면, 우리는 더 상세한 인사이트를 얻을 수 있습니다. 특히 요즘은 하나의 매체에 접속하는 경우는 거의 없고, 여러 매체들을 가지고 번갈아 접속하는 성향을 보이는 경우가 많기 때문에, 꼭 크로스 디바이스 분석은 가능한 구조를 만드셔야 합니다.
여러 도메인을 가진 경우, 어디까지 담아야 할 것인가?
매체는 일단 묻지도 따지지도 말고, 하나의 속성에 담는 것이 대체로 좋다고 말씀드렸습니다. 이와 비슷한 딜레마가 복수의 도메인을 가진 경우입니다. 도메인 별로 다른 속성을 만들 것인지, 아니면 하나의 속성에 모든 도메인 데이터를 쌓을 것인지의 문제인데요. 다만 이때는 꼭 무조건 하나의 속성에 데이터를 쌓을 필요는 없습니다.
먼저 물론 하나의 속성에 쌓으면 장점이 많습니다. 교차 도메인 분석이 가능하고요. 각각의 도메인들이 상호 어떤 영향을 끼치는 지도 쉽게 볼 수 있습니다. 특히 사용자 별로 여러 도메인을 사용하는 경우와 단일 도메인만 이용하는 경우를 비교해보는 건 매우 의미가 있을 겁니다.
하지만 도메인 별로도 여러 매체가 있을 테니, 너무 많은 것들을 하나의 속성에 담으면 아무리 보기로 분리하더라도, 구조가 너무 복잡해지게 됩니다. 또한 교차 분석 자체를 정합성 있게 하지 못할 가능성도 큽니다. 따라서 적정선에서 하나로 모을 도메인과 분리해서 비교할 도메인을 분류하는 것이 필요합니다. 즉 연관도가 높고, 상호작용이 활발한 도메인들은 하나의 속성으로 쌓고, 공통점이 적거나 분리되어 존재하는 도메인을 아예 별도의 속성으로 분리해야 합니다.
맞춤 측정 기준과 맞춤 측정 항목을 적절히 활용하자
이렇게 큰 단의 데이터 수집 범위를 정했다면, 마지막으로 속성의 꽃이라 할 수 있는 맞춤 측정 기준과 항목만 정리하면 어느 정도 속성은 마스터했다고 보셔도 됩니다. GA는 분석 기능이 탁월하고, 매우 방대한 기본 측정 기준과 항목을 제공하지만, 당연히 이걸로는 우리가 필요한 모든 정보들을 얻기 어렵습니다. 따라서 GA는 개별 사용자가 필요한 내용을 추가로 개인화하여 수집할 수 있도록 여지를 제공하고 있습니다. 그래서 처음 속성을 설계할 때부터 이러한 맞춤 측정 기준과 항목을 함께 고려해야 합니다.
솔직히 이 부분은 개발자의 도움을 받아야 하긴 합니다. 그래서 기획자나 마케터라면 어려울 수밖에 없는 부분이지요. 다만 확실히 하나는 꼭 챙겨서 미리 세팅하시기를 추천드리는데, 바로 고객의 로그인 ID를 수집하는 겁니다. 이를 User ID의 약자인 UID로 보통 표현하는데요. 이러한 ID를 수집해야 교차 디바이스나 교차 도메인 분석이 가능하니 꼭 챙기시길 바랍니다. 또한 APP을 보유한 서비스면 광고 ID도 수집을 하시는 걸 추천드리고요. 만약 여유가 되신다면 고객의 인구통계학적 정보 등도 같이 수집하시면 더 양질의 데이터 분석이 가능하다는 걸 잊지 마시길 바랍니다.
04 보기는 다다익선이지만, 개수는 제한되어 있답니다
마지막으로 보기에 대해 이야기를 나눠보려 하는데요. 보기는 속성에 쌓인 데이터들을 일정 기준에 따라 가져와서 보여주는 일종의 보고서입니다. 보기 또한 속성과 동일하게 한번 설정하면 그 이후부터 쌓인 데이터만 유효하기 때문에, 초기 세팅에 주의를 기울여야 합니다. 다만 기본적으로 속성에 쌓인 데이터를 일정 조건에 따라 필터링하여 보여주는 개념이므로, 일단 속성만 잘 설정했다면, 반전의 기회가 있긴 하답니다. 중요한 세팅 몇 가지만 놓치지 않았다면 말입니다.
로데이터, 마스터, 테스트 보기 생성은 필수입니다
심지어 구글의 데모 계정도 3개의 보기로 이루어져 있습니다 (출처: google)보기에서 가장 중요한 것은 로데이터, 마스터, 테스트 보기 3가지는 꼭 만드셔야 한다는 겁니다. 보기는 처음 말씀드렸듯이, 속성에 쌓인 데이터를 일정 기준에 따라 필터링하여 보여주는 개념인데요. 전체 속성을 그대로 보여주는 로데이터 보기를 하나 만드신다면 추후에 잘못된 필터 기준을 세우셨다고 하더라도, 만회 가능합니다. 혹시 모를 백업용 보기인 겁니다.
마스터 보기는 실제 분석을 진행하는 보기입니다. 전체 데이터가 쌓여 있으면서, 분석을 진행할 때 사용하는 보기인 겁니다. 가장 자주 접속하는 보기일 거고, 제가 보통 스터디 때 요거 하나만 꼭 기억하라고 강조하는 보기이기도 합니다. 다만 로데이터와 달리 필요에 따라 일부 필터는 적용할 수도 있습니다. 데이터를 원본 그대로 기록하는 목적이 아니라 실사용을 위한 보기이니 말입니다.
그렇다면 테스트 보기는 왜 필요할까요? 보기도 일단 세팅하면 다시 세팅하기 전의 데이터는 잘못된 설정이라 하더라도 수정이 안됩니다. 그렇기 때문에 설정하기 전에 테스트를 할 필요가 있습니다. 실수를 하면 안 되니까요. 이러한 때 테스트 보기는 유용하게 쓰일 수 있습니다. 보통 하루, 이틀 정도 데이터 쌓이는 것만 확인하면 필터가 제대로 작동하는지 확인 가능하니 말입니다.
25개 제한이 있다는 걸 기억해야 합니다.
이렇게 2개의 필수 보기를 제외하면 나머지 보기는 마음껏 세팅하셔도 무방합니다. 일반적으론 전체 데이터를 확인 가능한 주 사용 보기를 하나 세팅하고요, 디바이스 별, 혹은 도메인 별 등 운영하시는 플랫폼 특성에 맞춰 다양하게 세팅하시면 됩니다. 당연히 필요에 따라 나눈 뒤에 보시는 걸 추천드리고요. 분석은 나눠서 볼수록 더 풍부한 인사이트를 얻을 수 있으니 말입니다.
다만 기억하셔야 할 점은 보기의 개수를 무한정 늘릴 수 없다는 겁니다. 유료 버전인 GA360을 쓰시는 경우는 상관없지만, 무료 버전을 사용할 경우, 25개라는 개수 제한이 걸려 있습니다. 때문에 초기 정교하게 보기 구조를 짜서, 누락되는 것 없이 20개 내외로 설계하시는 걸 추천드립니다. 그리고 더 필요한 내용이 있더라도 혹시 모르니 나머지는 여유 분으로 남겨 두시는 게 좋고요. 특히나 대부분은 전체 데이터를 볼 수 있는 마스터 보기 위주로 조회하는 경우가 많습니다. 그래서 무분별하게 보기를 생성할 필요도 없지만, 적절하게 사용하는 보기를 정해주시는 센스도 필요합니다. 물론 전체 데이터를 확인 가능한 보기에서 세그먼트 기능을 활용하면 모든 필요한 결과를 얻을 수 있긴 하지만, 그럴 경우 샘플링에 걸릴 확률이 올라가기 때문입니다.
오늘은 GA의 기본구조의 정의와 우리가 실제 활용 시 주의해야 할 점에 대해 이야기 나눠 보았습니다. 최대한 쉽게, 그리고 필요한 부분만 간결하게 전달해 드리려 노력했는데 어떠셨을지 모르겠습니다. 다만 이번 글을 통해 처음 GA 세팅의 중요성을 확실히 깨달으셨으면 하고요, 이 기회에 한번 속성과 보기 구조에 대해 점검해보시는 계기가 되셨으면 좋겠습니다.
이제 다음번 글에는 본격적인 GA 활용법에 대해 슬슬 진도를 나가보려 합니다. 구글이 어떤 이론적 배경을 가지고 보고서를 설계하였고, 이에 따라 우리는 GA를 어떻게 활용하면 될지 이야기를 나눠볼 예정이고요. 이를 통해 조금이라도 더 GA가 친숙하게 느껴지시길 바랍니다.
*위 글은 위시켓으로부터 소정의 원고료를 받고 작성되었습니다.
*위 글은 쉽고 재미있게 읽을 수 있는 IT 이야기를 전하는 요즘IT에서도 보실 수 있습니다.
