커뮤니티2
-
속초-3.2
북춘천-6.5
철원-7.9동두천-5.9파주-5.1대관령-9.7춘천-5.3
백령도-5.1북강릉-1.3강릉0.1동해0.7서울-6.4인천-6.0원주-5.3울릉도-0.6수원-5.4영월-5.1충주-5.0서산-4.7울진2.0청주-4.0대전-3.1추풍령-4.9안동-3.0상주-3.0포항1.0군산-3.2대구-0.8전주-2.5울산0.1창원0.7광주-1.3부산0.9통영2.3목포-1.9여수-0.3흑산도-0.6
완도-1.0고창-2.9순천-2.9홍성-3.3서청주(예)-5.4제주1.7고산3.2성산1.4서귀포2.2진주1.6강화-5.2양평-4.3이천-4.8인제-6.2홍천-5.3태백-6.3정선군-4.1제천-6.0보은-4.0천안-4.7보령-3.3부여-2.0금산-3.3세종-4.3부안-1.7임실-2.7정읍-3.2남원-3.4장수-5.1고창군-2.5영광군-2.8김해시0.7순창군-3.4북창원0.2양산시2.0보성군-0.3강진군-1.1장흥-1.6해남-1.0고흥-1.2의령군2.0함양군-1.2광양시-0.2진도군-0.7봉화-2.9영주-5.5문경-4.1청송군-3.0영덕-1.2의성-1.8구미-0.9영천-0.8경주시0.0거창-2.0합천1.0밀양1.7산청-0.9거제2.1남해1.1북부산1.3 - 2023.01.27(금)
페이스북
트위터
카카오스토리
네이버밴드
URL복사
구글애널리틱스[Google Analytics]구글애널리틱스 커뮤니티입니다.
Conversions – Path Length 보고서: 구매까지 경유채널 수 확인
Conversions – Path Length 보고서: 구매까지 경유채널 수 확인
상품을 구매하기까지 몇번의 유입이 있었는지를 확인하는 레포트 입니다.
Top Conversion Path와 비슷한 레포트며, 저는 Path Length보다 Top Conversion Path 레포트를 선호합니다.
몇번 들어왔을때 가장 높은 전환을 보이는지도 중요하지만, Assist(First Interaction)에 좋은 채널과 Conversion(Last Interaction)에 좋은 채널을 확인하고, 그에 맞는 마케팅 전략을 수립하는게 더 중요하다고 생각하기 때문에, Path Length보다 Top Conversion Path 레포트를 선호합니다.
다만 Path Length 레포트는 직관적으로 몇번정도 유입한 유저가 구매를 하는지 현황파악에 도움을 주며,
리타겟팅 기간설정에 참고자료로 사용합니다.
이 레포트를 볼때 가장먼저 확인해야 할 항목은
좌측상단에 있는 Conversion에서 1가지의 Goal을 선택해야 그 Goal 달성까지 몇번의 유입이 있는지 확인할 수 있습니다. 여러가지 Goal을 선택하면, Goal 이 섞이기 때문에, 성과측정이 어려워 집니다.
구매까지 얼마나 많은 채널을 경유했는지 보여주는 보고서. 경유한 수에 따라 전환을 증가시키기 위한 전략 수립에 도움
-
구글애널리틱스 UTM을 통한 마케팅 채널 성과 분석
구글애널리틱스에서 마케팅 채널 혹은 특정 캠페인의 성과를 측정하기 위해 UTM 파라미터를 생성하는 방법, 왜 UTM 사용이 필요한 지, 구글애널리틱스 (GA) 보고서 상에서 UTM을 활용 방법에 대한 내용을 소개합니다. 1. 구글애널리틱스 UTM 이란? 구글애널리틱스에서 자주 사용되는 ‘UTM’은 Urchin Tracking Module의 약자로, 특정 캠페인 성과를 측정하기 위해 URL 끝에 파라미터를 추가하는 것을 뜻합니다. 사이트로 유입시키는 링크에 달린 UTM을 통해, 해당 트래픽이 어떠한 소스, 매체, 캠페인, 콘텐츠, 키워드 정보를 가지고 있는 지 수집할 수 있고, 이러한 UTM 정보를 바탕으로 마케팅 채널 및 캠페인 별 성과를 분리하여 측정할 수 있습니다. 2. UTM 파라미터 예시 UTM 파라미터는 집행하는 광고의 링크를 트래킹할 때 주로 사용됩니다. 네이버 브랜드 검색을 예시로 들겠습니다. 네이버 검색창에 ‘네이버 아디다스’라는 검색어를 입력하면, 브랜드 검색 광고가 나오게 되고, 해당 브랜드 광고의 콘텐츠 중 울트라부스트를 클릭했을 때, 아래와 같은 URL을 확인할 수 있습니다. https://shop.adidas.co.kr/PF070801.action?pageNo=1324&utm_medium=paidsearch&utm_source=naverbs &utm_campaign=2020_performance_xcategory_ecom&utm_content=울부 해당 URL에 포함되어 있는 UTM 파라미터들을 통해 paid search 형태의 네이버 브랜드검색을 통해 유입되었음을 알 수 있습니다. 추가적으로, 해당 유입은 ‘2020ecom’ 캠페인이고, 콘텐츠는 ‘울부’임을 알 수 있습니다. 이 때, utm_medium, utm_source, utm_campaign, utm_content 등을 UTM 파라미터의 key 이며, ‘=’ 다음으로 오는 것은 value 입니다. 3. 구글 애널리틱스(GA) 보고서에서의 UTM 활용 구글 애널리틱스(GA) 보고서에서 UTM에서 수집된 정보들이 어떻게 활용되는지에 대해 설명해드리겠습니다. 첫 번째, 구글애널리틱스(GA) 보고서의 세그먼트 기능을 통해 특정 캠페인 추적할 수 있습니다. UTM 파라미터로 수집된 정보는 구글애널리틱스(GA) 세그먼트 기능을 통해 특정 캠페인을 추적하여 캠페인 성과를 확인할 수 있습니다. 구글 애널리틱스(GA) 세그먼트 > 새 세그먼트 > 트래픽 소스 에서 세그먼트 설정이 가능합니다. 두 번째, 구글 애널리틱스 보고서에서 필터기능을 통해 소스에 따른 캠페인의 결과를 확인할 수 있습니다. Secondary dimension 검색창에 캠페인(Campaign)을 검색하여 필터를 적용시키면 소스에 따른 캠페인 성과 측정항목들을 한눈에 확인할 수 있습니다. 예를 들어, 네이버 웹툰 광고 배너에 UTM 파라미터들을 추가하면 아래와 같은 URL이 생성되고 https://music.naver.com/buy/indexVibePromotion.nhn?type=npay201901&utm_source=naver_webtoon&utm_medium=display&utm_campaign=jan_promotion 해당 UTM 파라미터를 통해 구글 애널리틱스 보고서에서 캠페인 소스가 naver_webtoon 캠페인의 성과측정을 손쉽게 할 수 있습니다. 4. 채널 분석을 위한 UTM 파라미터의 필요성 올바른 유입분류와 목표설정을 통해 채널별 성과분석을 하기 위해 UTM 파라미터는 꼭 필요합니다. 만약, 광고 소재의 Landing URL에 UTM 파라미터를 붙이지 않는다면, Organic 트래픽과 Paid 트래픽 등 유입채널을 구분할 수 없게 됩니다. 내가 집행 한 캠페인(광고)을 통해 유입한 Traffic이 (Other)로 분류되면 채널 별 성과 확인이 어려움으로, Display, Paid Search, Social 등 적합한 GA 채널로 분류될 수 있도록 UTM 설정을 해 주어야 합니다. 예를 들어, 네이버 검색창에 ‘네이버 바이브＇를 검색하였을 때, 검색결과로 나오는 사이트 영역을 클릭하여 유입될 경우, 구글 애널리틱스(GA)에서 Organic 트래픽으로 구분되지만, 네이버 브랜드검색 상품의 광고소재를 클릭하여 유입될 경우, GA에서 UTM 설정을 통해 Paid 트래픽으로 구분되어집니다. 만약 브랜드 검색 소재 URL에 UTM 파라미터가 없을 경우, GA에서 naver/organic으로 집계되고 올바른 유입분류를 할 수 없게 되어 캠페인 성과 또한 제대로 분석 할 수 없게 됩니다. 5. UTM 생성 방법 UTM 작성도구로 손쉽게 UTM을 생성하실 수 있습니다. Website URL는 랜딩페이지 주소입니다. Campaign Source는 트래픽 출처입니다. Campaign Medium은 트래픽 유형입니다. Campaign Name은 캠페인 명입니다. Campaign Term (Optional)은 유입키워드로, GA dimension에서 keyword로 확인이 가능합니다. 검색광고에서만 사용하는 걸 권장합니다. Campaign Content (Optional)는 소재 세부 정보입니다. 이때, Website URL,Campaign Source, Campaign Medium, Campaign Name은 필수로 작성해야 하며, Campaign Term,Campaign Content는 선택적으로 사용을 하시면 됩니다. *UTM 파라미터 작성 시, 주의사항* UTM 파라미터는 ?값으로 시작되며, 각 key & value pair는 &로 연결됩니다. 이미 URL에 ?가 있을 경우, 파라미터 시작은 &로 됩니다. URL에 # (부위지정자)가 포함될 경우, 파라미터의 맨 끝으로 이동해야 합니다. 알파벳이 아닌 문자는 UTF-8 로 인코딩이 되어야 합니다. 6. UTM 가이드 채널은 매체에 따라 구분되며, 주요 유입경로에 따른 UTM 소스와 UTM 매체는 위의 표와 같습니다. 플러스제로는 Google Analytics UTM 제작과 Shorten URL을 한번에 제작하 수있는 UTM Builder를 제공합니다. 플러스제로 UTM 태그 + 단축URL 생성기 https://pluszero.co.kr/utm-builder/
-
구글애널리틱스 UTM + 단축URL 12초만에 셋팅하기
구글 애널리틱스 UTM + 단축URL 12초만에 셋팅하기 우리 고객사들이 하도 틀리게 써서 빡쳐서 직접 만들어 쓰는거 공유. UTM 틀려서 Other로 분류되거나 Direct로 쌓이게 하지말고,, 데이터 분석하기 어렵게 만들지말고,, 영어로 된 UTM 빌드 사이트에서 뭐 넣어야할지 구민하지말고 UTM사이트갔다가 단축URL 사이트 갔다가 하지말고... 그냥 이거써서 구글 애널리틱스에서 데이터 깔끔하게 보시길 바랍니다. 제발....!!! 1. https://pluszero.co.kr/utm-builder/ 접속 2. 랜딩페이지 붙여넣기 3. 매체 선택 4. 캠페인/컨텐츠/텀 알아서 넣기 5. Shorten URL 누르고 Copy누르기 Google Analytics UTM 구글애널리틱스 광고 UTM 플러스제로 장점 1. UTM + 단축URL 12초 걸림. 2. GA 채널 레포트에서 (Other)생길일 없음. 3. UTM 틀려서 데이터 안쌓일 일 없음 평소 구글애널리틱스에서 (Other)나 Direct가 많이 잡혀 source/medium 레포트에서 데이터 봐야하고, 전체 채널 성과 확인을 포기했다면, 이 구글애널리틱스 광고 UTM + 단축URL 생성기로 해결을 했으면 한다. 괜히 UTM 공부한다고 검증되지 않은 블로그들 돌악다니지 말고, 구글 공식 프리미엄 파트너가 잘 정리되고 셋팅둔 정석 UTM 빌더를 쓰는게 옳다. 거기에 단축URL도 있으니.. 굳이 안쓸이유가 없다. 좋으니까 쓰세요.. 제발!!
-
구글애널리틱스 무한로딩이 싫은 문돌이가 쓰는 GA API는?
구글애널리틱스 무한로딩이 싫은 문돌이가 쓰는 GA API는? 난 문돌인데, GA 무한로딩 열받아서 우리 개발자한테 만들어달라 함 7초면 문돌이도 API써서 구글애널리틱스 무한로딩없이 데이터 뽑는다. 레포팅 시간이 보통 30분정도 걸렸는데 이제 딱 2분걸린다 기존: 구글 애널리틱스 접속 > 커스텀 레포트 선택 > 데이터 기간 설정 및 다운 x 3 > 엑셀 합치기 API: GA API 접속(자동로그인) > 원하는 Dimension, Metrics, Segment, 날짜 체크 > 조회&다운 Dimension, Metrics, Segment를 제한없이 쓸 수 있어서 한번에 다운받고 엑셀로 피벗돌림 1. https://pluszero.co.kr/ga-workspace/ 접속 2. 로그인 클릭 3. 어카운드 > 프로퍼티 > 뷰 클릭 4. 원하는 Dimension, Metrics, Segment 날짜 체크 5. 조회 장점 1. GA 로딩 안봐도 된다. 2. Dimension, Metrics, Segment 무한이다. (이게 뭘 의미하는지 아는사람이 있을까..?) 일단 플러스제로 공식 사이트에 들어가서 GA API 레포트 쓰는것은 아주 간단하다 그냥 구글 로그인만 누르면 평소 반복적인 레포팅에 쓰이던 항목(Dimension, Metric, 기간)만 클릭하고 '조회' '다운로드' 누르면 된다. 이 GA API 레포트를 한번도 안 쓴사람은 있어도, 한번만 쓴 사람은 없는 툴일것이다. (레포트의 속도와 데이터 합치기의 귀차니즘을 한번에 해결할 수 있다)
-
구글애널리틱스 Not set, Not provided 오류 해결하기
Google analytics를 활용하다보면 데이터가 Not set, Not provided로 뜨는 경우가 있습니다. 이러한 값이 나타나는 이유와 이를 해결하는 방법에 대해서 간략히 살펴보겠습니다. 1. Not set 값 측정기준 관련해서 애널리틱스로 들어온 정보가 없을 시 표시되는 값입니다. 다양한 원인이 있지만, 리포트 별로 해당 값이 나타나는 몇가지 케이스를 살펴보겠습니다. [트래픽 소스 리포트] 채널의 (not set) 값: 캠페인/광고 서비스의 UTM 태그 파라미터 값에 오류가 있을 경우 → UTM 파라미터 값 수정 필요 [캠페인 리포트] 키워드의 (not set) 값: 어떤 키워드로 유입이 되는지 인식할 수 없는 경우 예) Direct visit/ Referral과 같이 키워드 없이 유입(직접 입력, 북마크 등), 배너/카페 등에 삽입된 링크 클릭을 통한 유입 [구글 애즈 리포트] 구글 애즈 리포트에 이러한 값이 나타나는 여러 원인이 있습니다. 캠페인/ 캠페인 ID의 (not set) 값: - 연동 문제: 1) 구글애즈와 GA와 연동이 잘 되어있지 않은 경우 2) 원하는 GA 뷰와 Google Ads 계정이 잘 연결되지 않은 경우 → 연동이 잘 되었는지 여부 확인 필요 - 구글 애즈의 자동 태그 기능 문제: 1) 자동 태그 기능이 꺼져있는 경우 2) 자동 태그 기능과 수동 태그 기능이 동시에 사용되고 있는 경우 → 구글 애즈에서 확인 필요 - 무효 트래픽인 경우 - 리디랙션: 리디랙션 될 시, Google 클릭 식별자(GCLID)가 사라질 수 있음 - Syntax와 Glicid 문제: 웹페이지 구문을 변경했거나, glicid 파라미터에 100개 이상의 symbol이 포함되어 있어서 웹사이트가 이를 잘랐을 경우 → 스크립트 확인 필요 [행동 리포트] 방문 페이지의 (not set) 값: - 세션이 자정에 끝났거나 30분 후 종료된 경우: 30분 이후 취한 액션이 있을 경우, 새로운 세션으로 카운트 되며 랜딩페이지는 (not set)으로 표기됨 - 두가지 트래킹 코드를 사용했을 경우 → 필요없는 코드는 삭제하고 한가지 코드만 사용해야함 2. not provided 값 [트래픽 소스 리포트] 키워드 (not provided) 값: 연관검색 중 구글 계정 사용자가 로그인 상태에서 검색하는 경우, 개인정보보호를 위해서 검색어가 암호화된 키워드 → 이러한 키워드를 잡기 위해서는 구글애널리틱스와 서치콘솔 연동이 필요 이처럼 not set/not provided 값이 나타나는 원인은 다양합니다. 그리고 추가 작업을 통해 해결이 가능한 케이스가 있습니다. 이러한 케이스의 경우, 빠르게 원인을 파악한 후 정정하면 보다 더 정확한 데이터 분류를 할 수 있습니다.
-
GA GA360 GA4 차이점. 구글애널리틱스 구글 공식 프리미엄파트너 플러스제로.
GA, GA360, GA4 차이점 정리하는 글 입니다. GA GA360 GA4 차이점 (구글애널리틱스 비교) 플러스제로 GA vs GA360 vs GA4 비교. GA(Google Analytics, 구글애널리틱스 스텐다드) : 구글애널리틱스 무료버전으로 보통 WEB에 많이 사용하고 있습니다. APP은 파이어베이스(Firebase)를 통해 데이터를 수집합니다. GA360(Google Analytics360, 구글애널리틱스 프리미엄) : 구글애널리틱스 유료버전으로, 무료버전과 가장 큰 차이점은 '데이터 소유권' 입니다. 데이터 소유권이 '구글'인 무료버전에 비해, GA360은 데이터 소유권이 '나' 입니다. 때문에, 데이터 샘플링이 없고, BigQuery를 통해 Raw Data를 이용할 수 있습니다. 다만, GA360은 유료인 만큼, 연간 약 1.5억의 사용료를 지불해야 합니다. APP은 파이어베이스(Firebase)를 통해 데이터를 수집합니다. GA4(Google Analytics v4, 구글애널리틱스4) : 2019년 새로생긴 새로운 구글애널리틱스로, WEB과 APP을 심리스(구글피셜)하게 보기위한(광고를 더 팔아먹기위한) GA 입니다. GA360처럼 유료버전을 쓰지 않아도 BigQuery로 데이터를 보내주기때문에, RawData를 쿼리비용만 내고 사용할 수 있습니다. GA4 UI에선 속도가 매우 빠릅니다만, GAUI에 비해 GA4 UI에서는 많을것을 보여주지 않고, 데이터 분석을 위해 제대로 사용하기 위해선, BugQuery에 익숙해야 합니다. (마케팅하시는분들 화이팅!) (플러스제로는 고객이 BigQuery를 쉽게 쓰실 수 있도록, 내부 개발자에게 요청하여 만든 BigQuery Generator를 제공합니다 ㅎㅎ) GA4는 Session, PageView, Event Category, Action, Lable 개념이 모두 EVENT로 바뀌어서 GA4 Event 수집구조를 GA에서 사용하던 Dimension, Metric, Event 형태로 수집하는것 을 권장드립니다. (저희 플러스제로는 GA to GA4 마이그레이션 툴을 제작하여 GA와 같은 구조로 GA4를 구축합니다ㅎㅎ) 저희는 구글애널리틱스 공식 프리미엄 파트너이긴 하지만, GA4가 BigQuery로 데이터를 연결해줌으로써, 앞으로 GA360고객들이 굳이 GA360을 사용할지가 의문이네요 (앞으로 GA4에서 BigQuery로 일정 구간까지만 보내주고, GA4 프리미엄을 서비스 한다는 이야기가 있긴 합니다) 다음 글은, GA360을 활용하여 비즈니스를 성장시킨 마케팅 사례에 대해 이야기 할 예정입니다. GA GA360 GA4 차이점. 구글애널리틱스 구글 공식 프리미엄파트너 플러스제로. 끝.
-
구글 애널리틱스 – Measurement Protocol을 활용한 정확한 매출 데이터 수집
구글 애널리틱스 – Measurement Protocol을 활용한 정확한 매출 데이터 수집 1. 서론 GA나 GTM을 다뤄봤다면 Measurement Protocol(MP)라는 용어에 대해서 한번쯤은 들어본 적 있을 것이다. Measurement Protocol이 개발쪽 영역과 가깝기 때문에 되게 어렵다고 인식이 되어 있는 것 같다. 하지만, 사실 조금만 뜯어보면 그렇게 어려운 내용은 아니다. 물론 Measurement Protocol 개발을 직접 모두 다 진행해야 한다면 조금 상황이 다르겠지만, 마케터들은 거기까지 알 필요는 없다고 생각한다. 이번 글을 통해서 “마케터” 입장에서 알고 있어야 하는 MP 지식에 대해서 설명해보겠다. 한국에는 아주 특별한 결제 수단이 있다. 바로, “무통장 입금”이다. 이 결제 수단은 Google Analytics의 매출 정확도를 포기할 수 밖에 없게 만드는 불편한 존재이기도 하다. 그렇기 때문에 많은 한국 GTM 유저들은 무통장 입금을 그냥 단순하게 “버튼 클릭”을 기준으로 잡는 경우가 대다수라고 들었다. 하지만, Measurement Protocol와 개발자의 도움만 있으면 무통장 입금 뿐만이 아니라 다른 결제수단까지 완벽하게 처리할 수 있다. 자랑 한번 하자면, 필자는 과거에 Measurement Protocol를 통해 GA 매출 정확도를 98%까지 올려본 경험이 있다. 서론이 길었다. 한번 그 대단한 Measurement Protocol에 대해서 알아보자. 2. Measurement Protocol? Measurement Protocol은 Raw Data를 GA에 직접 전송하기 위해 지켜야 하는 하나의 약속이다. 물론, 이렇게 정의만 딱 내려주고 끝내 버리면 마케터 분들은 이걸 절대 이해하지 못할 것이다. 자, 한번 깊게 파보자. 아마 이 글을 읽고 있다면 대부분이 적어도 한번쯤은 GA나 GTM을 사용해본 경험은 있을 것이다. GA 하드코딩으로 데이터를 수집하던, GTM으로 수집하던 gtag로 수집을 하던, 그 어떤 방법으로 수집을 하던 모든 데이터는 Measurement Protocol 형태(HTTP Request, 추후 더 설명)로 GA에 보내진다. 예시를 들어보겠다. 설명하기 편하게 여러분들이 GTM으로 어떤 페이지에 페이지뷰 태그를 설정했다고 하자. 자 그리고 그 설정된 웹사이트에 들어가보자. 그런 다음에 개발자 도구를 실행시키고, “Network” 탭을 누른다. 네트워크 창에 보면 좌측 상단에 조그맣게 검색창이 보일 것이다. 거기에 “/collect”를 쳐보자. <개발자 도구 -> Network -> /collect 검색> 검색 결과가 여러 개가 나올 수 있다. 당황하지 말고 “Request URL”이라고 나온 부분의 값이 “https://www.google-analytics.com/collect?” 이렇게 적혀 있는 걸 클릭해보자. 결론부터 말해주자면, 그게 바로 여러분들이 설정한 GTM 태그가 GA에서 인식할 수 있는 데이터로 변형되어 넘어가는 결과 값이다. “엥? 무슨 알아보지도 못하는 문자들로 가득한데.. 이게 무슨 말이야?” 라는 생각이 들 수도 있다. 하지만, 네트워크 창에서 조금만 스크롤을 내려보면, “Query String Parameters”라는 부분이 있을 것이다. 이 파라미터 값들을 확인해보면, 우리와 조금 친숙한 값들이 몇 개 보인다. 예를 들어서 “pageview”, “page path”, “page title” 등을 이곳에서 확인할 수 있다. 그렇다, 이 Query String Parameter가 여러분이 설정한 태그의 결과물이며, 페이지뷰 태그는 아래와 같은 값들을 페이지 조회와 동시에 같이 수집한다. <Query String Parameters 예시> Query Parameter들을 뜯어보자. GTM을 통해 우리는 단순히 페이지 조회 태그만 만들었지만, 실제로 Google Analytics에서 수집하는 값은 페이지 조회를 포함한 추가적인 값(우리의 의도와 상관없이)들을 같이 수집하는 것을 알 수 있다. 예를 들면 Screen Resolution이나 Client ID 등이 있겠다. 이렇기 때문에 나는 GTM이 참 편리하고 좋다. 이 글과는 논외의 이야기지만, 이 값들을 유심히 보고 기억해두는 것을 추천한다. 나중에 GA에 Secondary Dimension이나 Custom Report의 Flat Table로 데이터를 볼 때 어떤 데이터들이 동시에 수집이 되는 지 인지하고 있으면 분석의 다양성에 큰 도움이 될 것이다. 자, 이제 우리는 GA가 모든 데이터를 Measurement Protocol형태로 수집한다는 것을 알아냈다. 즉, 이 뜻은 우리도 우리가 원하는 데이터를 Measurement Protocol형태로만 GA에 보낼 수 있다는 뜻이다. 이게 일반적으로 이야기하는 Measurement Protocol 활용 방법이다. 3. 측정 프로토콜(Measurement Protocol) 심화 필자는 측정 프로토콜이 약속이라고 정의했었다. 그럼 Measurement Protocol는 왜 약속인가? GA 서버에 Measurement Protocol형태로 Raw Data를 보내려면 구글에서 요구한 포맷에 맞추어 HTTP Request를 보내야 하기 때문이다. 쉽게 이야기 하면, 구글이“너희들 GA에 데이터 Measurement Protocol로 보내고 싶으면, 우리가 말한 포맷에 맞춰서 보내! 그럼 그 데이터 받아줄게” 라고 약속한 것이라 생각하면 편하다. dataLayer를 써서 구글이 제공한 Enhanced E-Commerce 템플릿에 맞추어 매출 데이터를 수집하는 것과 동일하다고 볼 수 있겠다. Measurement Protocol을 사용해서 GA에 데이터를 전송할 땐 총 3가지 삼위일체 조건이 만족이 되어야 하는데, 이는 User Agent, Transport, Payload Data로 구성된다. 4. User Agent User Agent는 브라우저가 자신의 정보를 나타내는 주민등록증? 과 같은 존재라고 보면 된다. 참고로 Google Analytics는 이 User Agent값을 통해서 Device / Browser / OS 등의 리포트와 데이터를 결정 짓는다. 따라서, Measurement Protocol로 데이터를 보내주려면 현재 활성화된 유저의 사용자 에이전트를 추출하여 사용해야 한다. 웹페이지에서 자신의 User Agent값 확인 하는 방법은 개발자 도구에서 “window.navigator.userAgent”라고 치면 된다. <User Agent값 출력하는 방법 예시> 이 User Agent 값은 아마 마케터인 우리가 정확하게 알아들을 수 있는 정보는 아니긴 하지만, 어쨌든 개발자 분들께 “Measurement Protocol 호출할 때 User Agent 값도 같이 넣어 주셔야 합니다!” 라고 말씀드리면 잘 알아들을 것이다. 참고로 쉽게 하고 싶어서Random User Agent값으로 마구잡이로 채워 넣고 Measurement Protocol 전송하면 대참사가 일어날 수도 있다. 물론 여러분들이 Device / OS / Browser Report를 포기한다면 뭐.. 큰 상관은 없겠지만 5. Transport Transport는 GA에 데이터를 보내는 위치와 방법을 의미한다. 원래 사실 여기서 HTTP Method의 5가지 방법과 URL Endpoint 개념을 설명할까 고민했지만, 오히려 혼란만 야기할 것 같아서 과감하게 스킵한다. 그냥 우리는 개발자님께 “HTTP Request POST” 형태로 호출 넣어 주시고, URL Endpoint는 “https://www.google-analytics.com/collect” 입니다! 라고 말씀드리자. 그게 제일 속편하고 굳이 되지도 않는 프로그래밍을 이해할 필요도 없을 것이다. 그래도 간단하게 설명을 하자면, HTTP Request라는 웹 표준 통신 방식이다. 여기에 GET / POST / DELETE 등등 호출하는 방법이 다른데, 우리는 그 중 POST(업로드)방식을 사용하는 것이다, Measurement Protocol는 GA에 데이터를 업로드 하는 방식이니까. 그럼 URL Endpoint는 무엇일까? 리소스에 접근할 수 있도록 가능케하는 URL이다. 즉, 호출의 정확한 위치를 나타낼 때 사용된다고 보면 되겠다. MP 같은 경우에는 항상 “https://www.google-analytics.com/collect”로 고정이니 큰 걱정을 할 필요는 없다. 6. Payload Data 자 Measurement Protocol 삼위일체 중 마지막 단계이다. 사실 3가지 필수 요소 중에서 2가지는 거의 개발자님에게 부탁해야 하는 방법 밖에는 없다. 우리는 개발을 모르니, 직접 구글에 HTTP Request를 보낼 수 있는 상황은 아니지 않는가.. 하지만 Payload Data영역 만큼은 마케터들의 역량이 중요하다. 데이터를 전송하는 것은 개발자가 하더라도, 어떤 데이터를 보낼지는 우리가 정하니까. 자 Payload Data는 무엇인가? 혹시 위에 필자가 예시로 보여줬던 Query String Parameter를 기억하는가? 그게 바로 Payload Data이다. Payload Data는 GA에 어떤 데이터를 보낼 지 결정 짓는 제일 중요한 부분이며URL Parameter 형태로 표현된다. 즉, ‘Key = Value’ 쌍으로 표현되고, 각 ‘Key = Value’쌍은 ‘&’문자로 구분된다. 이때 유의해야 될 점은 URL 파라미터 시작은 “?” 문자로 표현된다는 것이다. 그리고, 모든 URL 파라미터는 URL Encode가 되어야 한다. 한국어 데이터를 쌓고 있는 웹사이트라면 진짜 꼭 필수로 encoding 해주어야 한다. 우리가 직접 Encode 할 필요는 없다, 하지만 개발자에게 Payload 데이터를 전달할 때 꼭 “Measurement Protocol의 Payload data는 URL Encode해주셔야 작동합니다!” 라고 말하자. 자세한 Measurement Protocol Parameter 값들은 아래 링크를 확인해보면 좋을 것 같다. 읽으면서 GA에 나오는 데이터가 실제로 MP에선 어떻게 표현되는지를 비교해가면서 보면 더 도움이 될 것 같다. https://developers.google.com/analytics/devguides/collection/protocol/v1/parameters?hl=en 6.1. Measurement Protocol 데이터 타입 위의 문서를 읽으면 데이터 타입이라는 것이 존재하는데, 이 부분은 여러분들이 꼭 숙지를 해야 하는 부분 중 하나이다. 프로그래밍 환경에서는 문자열 “1”과 숫자 1은 엄연한 다른 값이다. 그렇기 때문에 데이터 타입이라는 개념이 존재하는데, MP에 데이터를 보낼 때도 이 데이터 타입을 고려해서 꼭 보내주어야 한다. <Measurement Protocol 데이터 타입 예시> 위의 예시는 Value Type 즉, 데이터 타입이 Text라고 한다. 그러므로 “dr”(referrer) 이라는 parameter를 MP를 통해 보내줄 땐 꼭 문자열 형태(Text)로 보내주어야 한다. MP의 페이로드 데이터는 하기의 데이터 타입을 지원한다. (1) Integer: 숫자 데이터를 표현 (2) Text: 문자 데이터를 표현 (3) Boolean: 논리형 데이터를 표현 (4) Currency: 통화(Currency) 가치를 표현. 총 6개 소수점까지 가능 명시된 데이터 타입과 다른 타입으로 보내주면 GA에서 인식을 못할 수도 있으니 참고하길 바란다. 6.2. Measurement Protocol 필수 파라미터 Payload Data는 여러 개의 파라미터로 이루어져 있다. 이때, 각 페이로드 데이터에 필수로 들어가야 하는 파라미터가 존재한다는 점을 꼭 고려해서 Payload Data를 생성해야 한다. 필수로 들어가야 하는 파라미터는 아래와 같다. (1) Measurement Protocol 버전: ‘v’는 측정 프로토콜 버전을 나타내는 파라미터 Key값이다. 이때, Value는 1이 되어야 한다. ※ Example:v=1&tid=UA-123456-1&cid=abcdefg&t=pageview&dp=chrome (2) Tracking ID: ‘tid’는 구글 애널리틱스 Tracking ID를 나타내는 파라미터 Key값이다. 이때, Value는 데이터를 보내고자 하는 GA Property ID를 넣어야 한다. ※ Example: v=1&tid=UA-123456-1&cid=abcdefg&t=pageview&dp=chrome (3) Client ID or User ID: ‘cid’ 혹은 ‘uid’는 한 유저를 식별할 수 있는 고유의 값이다. 이때, cid의 Value는 First-Party Cookie 값을 사용하여 하며, uid의 Value는 고유한 유저 넘버를 사용해야한다. ※ Example: v=1&tid=UA-123456-1&cid=abcdefg&t=pageview&dp=chrome ※ Example: v=1&tid=UA-123456-1&uid=user1234&t=pageview&dp=chrome 참고로 Google Analytics가 설치되었을 때, GA가 사용하는 Client ID를 뽑아내는 방법은 아래와 같다. 한 가지 매우 중요한 팁을 주자면, User ID를 기준으로 데이터를 쌓고 싶더라도, Client ID를 빼고 MP를 전송하면 데이터가 GA에 안 쌓인다. 이거 때문에 얼마나 삽질을 했는지 모르겠다. 실제 구글 공식 MP 문서를 읽어보면 “Optional”이라고 적혀 있지만, Client ID는 절대로 선택지가 아니다. 이건 필수 값이다. 꼭 기억하길 바란다. (4) Hit Type: ‘t’는 GA 히트 타입을 나타내는 파라미터 Key 값이다. 이때, Value는 ‘pageview’, ‘event’, ‘social’, ‘transaction’, ‘item’, ‘exception’, ‘appview’, ‘timing’ 중 하나가 되어야 한다. ※ Example: v=1&tid=UA-123456-1&cid=abcdefg&t=pageview&dp=chrome 참고로, Enhanced E-Commerce 기능을 사용하려면 히트 타입이 ‘transaction’ 이나 ‘item’이 될 필요가 없다. EEC는 그냥 ‘pageview’ 혹은 ‘event’ 히트와 같이 보내주기만 하면 되기 때문이다. GTM으로 EEC를 구현해봤으면 무슨 말인지 대충 이해가 될 것이다. GTM에서 EEC 기능을 키는 방법은 Pageview나 Event 태그에 “Enable Enhanced Ecommerce Feature”의 값을 True로 넣기만 하면 된다. 즉, 이 EEC 히트는 이벤트나 페이지 히트와 같이 전송된다고 이해하면 되겠다. 자세한 것이 궁금하다면, EEC가 발동되는 태그를 개발자 도구 Network 탭에서 한번 확인해봐라. 분명히 t 값은 event나 pageview로 처리가 되어 있을 것이다. <GTM Enhanced E-Commerce 예시> 아래는 MP에서 꽤 중요하고 자주 사용된다고 생각되는 Parameter들을 정리해둔 표이다. 참고하길 바란다. 구글 공식 MP 문서나 내 글을 읽으면서 Payload 데이터를 한번 생성 해보길 바란다. User Agent / Transport / Payload Data, 이 삼위일체들을 한 곳에 합치면 아래와 같다. 이게 처음에 Payload Data를 형성하다 보면, 조금 헷갈리고 어려울 수 있다. 무엇보다도 “이렇게 하면 되는건가..?” 라는 생각이 들 것이다. 혹시라도 틀린 Payload Data를 개발자한테 보내주고 나중에 자신의 실수로 인해 작동에 실패한 사실이 밝혀진다면.. 으으.. 좀 아찔하긴 하다. 이를 방지하기 위해서 구글에서는 아주 친절하게도 우리에게 “Hit Builder”라는 것을 제공한다. 필자의 글을 읽던 구글 문서를 참고하던가 해서 Payload Data를 만들었다고 하자, 그럼 이 방식이 맞는지 안 맞는지 확인하는 방법은 바로 아래 링크에서 확인하면 된다. https://ga-dev-tools.appspot.com/hit-builder/ <GA Hit Builder 예시> 여기에 나와있는 “Hit payload”에 직접 완성된 파라미터 값들을 채워 넣거나, 아니면 아래에 보이는 곳에 하나씩 채워보자. 그런 다음에 “Validate Hit”이라는 버튼을 클릭하면 자신이 적은 Parameter 값들이 실제로 올바른 포맷을 가지고 있는지 구글이 직접 알려준다. <GA Hit Builder 틀린 경우> <GA Hit Builder 맞은 경우> “Hit is valid!”라고 나왔다면 일단 Payload Data를 잘 생성한 것이 맞다. 여기서 “Send hit to Google Analytics” CTA를 누르게 되면 실제 그 값이 GA로 보내지니 한번 GA에 데이터가 어떻게 쌓이는지도 확인해보는 것을 권장한다. 7. Measurement Protocol 개발자에게 요청하자 자 이제 MP의 삼위일체 User Agent / Transport / Payload Data가 준비가 완료가 되었다. 그럼 우리는 개발자에게 어떻게 요청을 해야 할까? 사실 나도 이 부분은 개발자 성향마다 다르기 때문에 정확히 뭘 어떻게 요청해야 제일 효율적인지는 모르겠다. 어쨌든 나는 아래와 같이 요청을 했다. 1) 개발자에게 자신이 필요한 시점에서 필요한 데이터를 가져올 수 있는 프로그램 개발이 가능한지 물어본다. 어쨌든 MP도 내가 원하는 시점에 데이터를 전송해야 한다. 즉, GTM의 Trigger와 같은 존재가 필요하다는 것이다. 그래서 그 시점을 명확하게 개발자에게 전달하고, 자신이 만들어 놓은 Payload Data를 보여주면서 “해당 시점에 이 데이터를 수집해서 HTTP Request를 User Agent와 함께 보낼 수 있는지”에 대한 가능 여부를 물어봐야 한다. 2) Payload Data로 변환할 때 필수 조건과 참고사항을 전달한다. MP를 사용할 때, 필수 파라미터 값 + URL Encode + Data Type 참고 사항을 개발자에게 꼭 전달하자. 아무리 코드를 잘 짜더라도, 구글과의 “약속”에서 조금이라도 어긋나면 GA에 데이터는 절대로 쌓이지 않는다. 3) User Agent / Client ID는 실제 내 웹 사이트 사용자의 정보로 사용하자. 개발자분들은 이 부분이 조금 까다롭게 생각하는 경우가 있다. 왜냐하면 주로 MP는 주로 오프라인 전환과 같은 특수한 상황에서 사용이 된다. 실제로 GA에 보낼 필요한 데이터를 가져오는 것은 큰 문제가 되지 않으나, 특정 사용자를 식별할 수 있는 값을 따로 저장해서 그 사용자의 User Agent와 Client ID를 다시 불러오는 작업이 쉽지 않다고 들었다. 하지만, 어렵다고 해서 포기할 수 없는 부분이다. GA의 Session 정보는 Client ID를 기준으로 병합된다. 그렇기 때문에 아무리 멋지고 Fancy한 Payload Data를 생성하더라도, 그 데이터가 내가 기대했던 대로 GA에 철썩 달라붙지 못하면 무용지물이다. User Agent와 Client ID를 다시 불러와서 재활용하는 부분은 마케터가 할 수 있는 영역은 아니지만, 개발자에게 강조를 하여 이 중요성을 반영하길 바란다. 8. 마무리 Measurement Protocol을 완벽하게 이해하면 정말 새로운 세계가 열린다고 장담한다. MP는 단순히 내가 원하는 데이터를 보내는 역할만 하는 것이 아니다. MP에는 GA에 데이터를 전송하는 원론적인 방식이 담겨져 있으며, 이를 완벽하게 이해하게 된다면 GTM에서 Tagging 하는 방법과 GA Report를 보는 방법이 많이 달라질 것이다. Hit Builder라는 구글에서 제공하는 아주 좋은 툴이 있으니 이를 활용해서 많은 분들이 MP와 친해졌으면 좋겠다. 요즘 GA에 관심있는 퍼포먼스 마케터들이 있는 톡방에 들어와 있는데, 다들 네이버 페이나 무통장 입금은 당연히 추적할 수 없다고 생각하는 것이 조금 아쉽더라.. 이 글을 기회로 삼아서 여러분들도 MP를 마스터하고 보다 다양하고 정확한 데이터들을 수집할 수 있는 마케터가 되면 좋겠다.
-
[성공사례 Measurement Protocol] Offline 데이터 병합을 통한 GA 매출정확도 99%달성
[성공사례 Measurement Protocol] Offline 데이터 병합을 통한 GA 매출정확도 99%달성 PlusZero는 국내 최대 규모를 자랑하는 E-Commerce 클라이언트 웹사이트 구축을 담당하였고, 그 이커머스 업체의 목표인 구글 애널리틱스(GA. Google Analytics)의 매출데이터와 내부 실제 매출정확도 100% 일치 프로젝트를 진행하였습니다. 구글 애널리틱스의 Measurement Protocol 을 통해 실제 결제시, 구글애널리틱스로 결제데이터를 송출해주고, 환불 역시 Measurement Protocol을 통해 구글애널리틱스의 Refund 데이터를 송출하여 실제 매출과 99%일치하게 되었습니다. Project Objective 한국은 특히 3rd Party Payment Gateway가 많은 나라입니다. 대표적으로 네이버 페이 / 카카오 페이 / 무통장 입금 등이 있습니다. 이 중, 무통장 입금과 같이 Offline에서도 결제할 수 있으면서 자동 취소율이 높은 결제수단은 Google Analytics로 정확하게 수집하기가 어렵습니다. 하지만, 저희 클라이언트는 GMP를 도입함과 동시에 거의 모든 내부 보고를 Google Analytics로 대체하기를 희망했습니다. 때문에 정확한 매출 데이터가 필수적으로 필요했습니다. How PlusZero Handled It? PlusZero는 정확한 매출 데이터 수집을 위해 Measurement Protocol을 사용하기로 했습니다. 저희는 저희 클라이언트 웹사이트에서 사용하는 3rd Party Payment Gateway들의 API를 활용하여, “실결제”가 완료 될 경우에만 Google Analytics로 매출 데이터를 보내주는 API를 개발했습니다. 환불 같은 경우에는 Google Analytics Management API의 Custom Upload를 활용하여, 전화 취소 혹은 대면 취소와 같은 Google Analytics로 잡을 수 없는 환불 데이터까지 Google Analytics에 업로드 시켜 데이터 정확도를 향상시켰습니다. 다만, 이 이커머스 업체는, 별도 개발조직과 서버를 가지고 있었기 때문에, 결제에 대한 데이터를 구글애널리틱스로 송출 해 줄 수 있는 환경이었습니다. 구글 애널리틱스에서 매출 정확도를 100% 일치하기 위해선, 결제와 환불 정보를 직접 처리할 수 있는 개발자와 환경 조성이 선행되어야 합니다. Project Outcome PlusZero는 성공적으로 매출 데이터 정확도를 약 10% 가량 향상시킬 수 있었습니다. 이전에 dataLayer를 사용하여 데이터를 수집했을 때 클라이언트의 매출과 PlusZero가 수집한 Google Analytics 매출 데이터 정확도가 약 89%였으며, 현재 데이터 정확도는 약 99%입니다. 그 결과, 클라이언트는 모든 내부 보고를 Google Analytics 데이터로 대체할 수 있었고, 정확한 데이터를 기반으로 마케팅 활동을 이어 나가고 있습니다.
-
Customization – Custom Reports: 원하는 보고서 제작
Customization – Custom Reports: 원하는 보고서 제작 GA에서 제공하는 레포트 이외에, 필요한 데이터(Dimension, Metric)를 모을 수 있는 레포트 입니다. 매체, 디바이스, 캠페인별 성과를 보는 등, 3개 이상의 Dimension이 필요한 경우 Custom Report를 사용합니다. 또한, 정기적으로 필요한 데이터를 쉽게 추출하기위한 용도로도 많이 사용됩니다. 커스텀레포트를 만드는 가장 쉬운 방법은, GA에서 제공하는 레포트의 우측 상단의 Edit을 누르면 생성되는 커스텀 레포트의 Dimension과 Metric을 추가/삭제를 하여 사용하는것 을 권장합니다. 커스텀레포트는 Filter 기능이 있기때문에, 특정 데이터 소스만 확인할 수 있다. 예를들어, 자연검색을 통한 유입만 확인하고자 할땐, Filter >(includ) Default Channel Grouping > (exact)Organic Search를 셋팅하면, Organic Search를 통해 유입한 데이터만 확인할 수 있습니다. 이렇게, 커스텀레포트는 자신이 원하는 데이터를 여러가지 Dimension과 Metric을 조합하여 쓸 수 있기 때문에, 매우 자주 사용되는 레포트입니다. 다만, 시각화 대시보드 툴 DataStudio가 나오면서, 사용빈도가 낮아졌지만, 아직 많이 사용되고 있고, 재미있는 레포트 입니다.
-
Conversions – Path Length 보고서: 구매까지 경유채널 수 확인
Conversions – Path Length 보고서: 구매까지 경유채널 수 확인 상품을 구매하기까지 몇번의 유입이 있었는지를 확인하는 레포트 입니다. Top Conversion Path와 비슷한 레포트며, 저는 Path Length보다 Top Conversion Path 레포트를 선호합니다. 몇번 들어왔을때 가장 높은 전환을 보이는지도 중요하지만, Assist(First Interaction)에 좋은 채널과 Conversion(Last Interaction)에 좋은 채널을 확인하고, 그에 맞는 마케팅 전략을 수립하는게 더 중요하다고 생각하기 때문에, Path Length보다 Top Conversion Path 레포트를 선호합니다. 다만 Path Length 레포트는 직관적으로 몇번정도 유입한 유저가 구매를 하는지 현황파악에 도움을 주며, 리타겟팅 기간설정에 참고자료로 사용합니다. 이 레포트를 볼때 가장먼저 확인해야 할 항목은 좌측상단에 있는 Conversion에서 1가지의 Goal을 선택해야 그 Goal 달성까지 몇번의 유입이 있는지 확인할 수 있습니다. 여러가지 Goal을 선택하면, Goal 이 섞이기 때문에, 성과측정이 어려워 집니다. 구매까지 얼마나 많은 채널을 경유했는지 보여주는 보고서. 경유한 수에 따라 전환을 증가시키기 위한 전략 수립에 도움
-
Conversions – Time Lag 보고서: 구매까지 걸린 시간 확인
Conversions – Time Lag 보고서: 구매까지 걸린 시간 확인 최초 접속부터 구매완료까지 걸린 시간과 전환수를 보여주는 시각화 보고서로, 고객들이 평균적으로 며칠 이내 구매하는지 파악할 수 있는 레포트 입니다. 보통 당일이 압도적으로 높은 비율을 차지하는 레포트이지만, 특정 유저(Segment) 등, 보다 의미있는 데이터를 보기 위해선 몇가지 확인해야 할 것이 있습니다. 1. Segment: 다들 Conversion에 있는 레포트들은 Segment가 안된다고 알고있지만, 아래 이미지 처럼, 간단한 Segment를 제공하니, 꼭 써보시길 권장드립니다. 2. Goal 선택: 전체선택이 아닌, 1개를 선택하고 보시는 것 을 권장드립니다. 3. Lookback Window: 이 레포트만큼은 90일을 지정하고 보는것 을 권장드립니다.
-
Conversions – Sales Performance 보고서: 매출 성과 확인
Conversions – Sales Performance 보고서: 매출 성과 확인 GA매출 데이터와 실제 판매 데이터 비교에 좋은 레포트 입니다. Google Analytics는 CRM이나 Web Admin이 아닌, 유저 행동패턴을 분석하기 위한 웹로그분석 툴 입니다. 실제 매출 데이터와 GA 데이터가 얼마나 일치하는지 알 수 없기때문에, 데이터 정확도를 확인하기 위해선, GA와 실제매출 데이터의 Key값이 있어야 합니다. 보통 그 키값을 상품주문번호로 사용하기때문에, 동일한 기간동안 발생한 Transaction을 비교하면 데이터 정확도를 확인할 수 있습니다. 보통 95%정도의 정확도를 보이며, 좀 더 고도화 된 셋팅을 통해 99%일치시킬 수 도 있습니다. (http://googleanalytics360.com/board/view.php?bo_table=googleanalytics&wr_id=32&page=) 그 외에, 리펀드(구매취소)는 구매할때 발생한 Transaction ID를 기준으로, 리펀드 금액이 발생하기 때문에, GA상에서 총 매출이 리펀드에 의해 낮아지는 일은 없습니다. (Revenue와 Refund 데이터는 차감이 없으며, 오직 누적) 때문에, 1월 1일 구매한 사람이 2월 1일에 리펀드 한 경우, 1월 한달간 데이터엔 리펀드가 0인 경우가 발생합니다. 데이터 정확도 검수나 이상한 거래ID를 찾을때 빼곤, 딱히 쓸일은 없는 레포트이지만, GA 셋팅 초기엔 꼭 필요한 레포트 입니다. 아! GA Ecommerce 데이터 정확도 개선을 위한 방법은 다들 꼭 한번씩 찾아보시길 바랍니다. 새로고침, 리다이렉트, 알럿창, 네이버페이, 레퍼러, 무통장 등 다양한 이유가 있습니다. 거래 ID 기준, 매출 관련 정보 파악 가능. 내부 거래ID와 매칭하여 GA Ecommerce 정확도 계산 가능.
-
Conversions – Product Performance 보고서: 상품별 성과 확인
Conversions – Product Performance 보고서: 상품별 성과 확인 판매상품의 주문, 수량, 매출, 객단가 등 데이터를 확인하기 위한 레포트 입니다. 상품 분석을 위해 가장 많이 사용하는 레포트 중 하나입니다. 보통 매출현황 파악과 상품 분석을 위해 사용되는데, 내 사이트에서 가장 잘 팔리는 상품에 대한 정보를 확인하거나, 캠페인 진행기간동안, 특정 상품이 얼마나 판매되었는지, 특정 카테고리 안에서 어떤 상품이 가장 인기가 좋았는지 확인하는데 사용됩니다. 광고 담당자는, 성별/연령/매체 별 잘 팔리는 상품을 확인하여, 해당 상품을 소재로 한 광고를 배포하고, 상품 기획 담당자는, 반응률 높은 상품의 가격, 상품명, 상품설명, 이미지를 기반으로 상품을 기획하며, 사이트 담당자는, 잘 팔리는 상품의 노출을 높여 매출을 극대화 하는 작업을 할 수 있습니다. 다양한 브랜드나, 카테고리를 보유 한 사이트의 경우, GA E-commerce 셋팅을 잘 하면 하나의 레포트에서 다양한 데이터를 한눈에 볼 수 있습니다. 웹사이트에서 판매중인 상품 혹은 서비스별 매출 성과 보고서 상품판매 성과 분석에 가장 적합한 레포트 입니다. 각 상품 별 구매 횟수, 판매수량, 평균 구매당 판매수량, 평균구매금액, 총매출, 리펀드에 대한 데이터를 확인할 수 있기 때문에, 판매전략 수립에 좋은 아이디어를 제공할 수 있습니다. 예를들어, 평균 구매당 판매수량이 1.1정도 되는 사이트에서, A라는 상품의 평균 구매당 판매수량이 1.7인 경우, 사람들이 이 상품은 2개씩 주문하는 빈도가 높으니, 2개 셋트상품을 기획하거나 광고소재로 활용할 수 있습니다. 좀 더 깊이 들어가면 2nd dimension을 Gender, Age로 하여, 어떤 고객들이 한번에 2개 이상씩 주문하는지 확인하여 성별, 연령에 맞는 2개 묶음상품 제작과 타겟팅 광고를 할 수 도 있습니다. (Custom Dimension을 사용하셨다면, 구매시 선택한 옵션등을 확인하고 기획에 참고할 수 있습니다.) 더 들어가면, 2개를 사는 사람들을 segment 하여, 함께 구매하는 상품과 유입경로(매체)를 확인하여 성과가 높은곳에 집중 노출하는것 도 좋겠네요 :)
-
Conversions – Shopping Behavior & Checkout Behavior 보고서: 쇼핑 과정 확인
Conversions – Shopping Behavior & Checkout Behavior보고서: 쇼핑 과정 확인 구매의사가 있다고 판단할 수 있는 단계인, 장바구니부터 구매완료에 대한 이탈지점을 확인할 수 있는 레포트 입니다. 이미 많이 보고 들은 이야기 이지만, 브랜딩과 상품 구매까지 많은 비용과 시간, 에너지가 필요하기때문에, 일단 구매단계를 시작하면, 구매완료까지 이탈을 최소화 해야합니다. 아무생각없이 구매완료까지 보내야 하는게 우리의 역할이죠. 이때 어느 단계에서 이탈하는지 확인할 수 있는 레포트가 Conversions – Shopping Behavior 입니다. 아래 이미지처럼, 장바구니부터 구매완료까지의 단계를 직관적인 그래프로 시각화 하기때문에, 어느 단계에서 유저가 이탈하는지 확인할 수 있습니다. 구매단계의 이탈을 최소화 하는 방법은 크게 3가지가 있습니다. 1. Conversions – Shopping Behavior 에서 이탈이 많은 페이지확인 2. 해당 페이지에 가서 왜 이탈이 많은지 확인, 경쟁사 밴치마킹, 선진화 사례 확인 및 가설 수립 3. Google Optimize 등, A B Test를 통해 가설 검증 후, 실서버 적용 가장 기본적이면서도 고객경험을 최적화 하는 기본적인 단계이니, 꼭 기억하시길 바랍니다. 추가 팁을 드리자면, 이탈원인을 좀 더 자세히 확인하기 위해선 크게 3개정도 항목을 고려해야합니다. 1. Device Category, Operate System, Browser 등 시스템 별 이탈률 확인 2. 구매단계의 form event(click, change) 수집을 통해, 이벤트가 크게 감소하는 지점 확인 3. Check out 단계 GA설치 확인 위에서 말씀드린 구매단계 이탈 최소화 및 이탈원인을 파악하기 위한 3가지 방법은 꼭 사용해보길 권장합니다. 세션을 기준으로, 유입부터 최종구매까지 각 단계별 이동 및 이탈 시각화 래포트 세션을 기준으로, 장바구니 부터 최종구매까지(Check Out) 각 단계별 이동 및 이탈 시각화 래포트
-
Conversions – Ecommerce Overview 보고서: 이커머스 전체현황 파악
Conversions – Ecommerce Overview 보고서: 이커머스 전체현황 파악 매출에 대한 주요 정보를 모아놓은 레포트 입니다. 내가 지정한 기간동안의 총 매출과 구매량, 평균 구매금액, 주요상품에 대한 정보를 확인할 수 있습니다. 별 다른 기능은 없으며, 보통 마케터들이 개발자분들께 매출을 뽑아달라고 하기보단, 퀵하게 특정 기간동안 대략적인 매출과 주요 상품 판매현황을 파악하기 위해 사용합니다. Overview 레포트 답게, 분석보단 현황파악에 사용이며, 분석을 위해선 Ecommerce - Product Performance 레포트가 많이 사용됩니다.
-
Conversions – Goal Flow 보고서: 방문자 Goal 경로 확인
Conversions – Goal Flow 보고서: 방문자 Goal 경로 확인 Conversions – Funnel Visualization 보고서와 동일한 레포트 이지만, 좀 더 직관적인 레포트입니다. 각 단계에서 얼마나 이탈했는지 보여주는 것 은 동일하지만, 이탈해서 어느페이지로 이동하는지까지 시각화 해 주기때문에, 좀 더 직관적으로 문제점을 파악할 수 있습니다. Conversions – Funnel Visualization 보고서와 동일하게, Destination Type의 Goal Step을 설정해야 이 레포트를 활용할 수 있으며, 동일한 기능을 제공합니다. 1. 시스템 이슈 확인 : 디바이스, OS, Browser 별 이탈률을 확인하여 특정 환경에서 이탈률이 높은지 확인 및 개선 가능 --> 시스템 이슈 개선 2. 이탈률이 높은 단계 확인 : 이탈률이 높은 단계를 직관적으로 확인할 수 있기 때문에, 어느 페이지를 개선해야할 지 확인. 나아가 form 작성 페이지의 경우, Event 수집을 통해 어느 form 입력단계에서 이탈하는지 확인 및 개선 가능. --> 이탈률 높은 페이지 개선 3. 이동 페이지 확인 : 각 단계 별 어느페이지로 이탈하는지 확인할 수 있기 때문에, 이탈 요소를 소거 할 수 있습니다. --> 이탈을 유도하는 버튼(link) 최소화 (Funnel Visualization과 다른점이라면, 최초 시작하는 Dimension을 정할 수 있다는 것 정도인데, 음.. 저는 잘 사용하진 않습니다.) 개인차가 있지만, 저는 Goal Flow 레포트를 더 좋아하고, 여러분도 이 레포트를 더 잘 활요하길 바랍니다. 방문자의 Goal(상품구매, 예약, 구독 등) 달성까지 행동패턴(이전, 다음 페이지 경로, 이탈) 시각화
-
Conversions – Funnel Visualization 보고서: Goal 현황 파악
Conversions – Funnel Visualization 보고서: Goal 현황 파악 사이트 방문부터 구매완료까지 각 스텝 별 이탈률을 확인하기 위해 사용하는 레포트입니다. 이 레포트는 골 달성까지의(보통 구매완료) 각 스텝 별 이탈을 확인할 수 있기 때문에, 아래와 같은 인사이트를 얻을 수 있습니다. 1. 시스템 이슈 확인 : 디바이스, OS, Browser 별 이탈률을 확인하여 특정 환경에서 이탈률이 높은지 확인 및 개선 가능 --> 시스템 이슈 개선 2. 이탈률이 높은 단계 확인 : 이탈률이 높은 단계를 직관적으로 확인할 수 있기 때문에, 어느 페이지를 개선해야할 지 확인. 나아가 form 작성 페이지의 경우, Event 수집을 통해 어느 form 입력단계에서 이탈하는지 확인 및 개선 가능. --> 이탈률 높은 페이지 개선 3. 이동 페이지 확인 : 각 단계 별 어느페이지로 이탈하는지 확인할 수 있기 때문에, 이탈 요소를 소거 할 수 있습니다. --> 이탈을 유도하는 버튼(link) 최소화 이 Funnel Visualization 레포트는 Destination Type + Funnel을 셋팅 한 골을 생성해야 확인할 수 있습니다. 구매완료와 같이, 목표달성까지 단계가 있는 사이트는 반드시 사용해야 하는 레포트 입니다. 방문자의 Goal(상품구매, 예약, 구독 등) 달성까지 행동패턴(이전, 다음 페이지 경로, 이탈) 시각화
-
Behavior – Top Events 보고서: 이벤트 현황 파악
Behavior – Top Events 보고서: 이벤트 현황 파악 내 사이트에서 어떤 버튼을 얼마나 클릭했는지 확인하기 위한 레포트 입니다. 메인배너를 얼마나 클릭했는지, 장바구니를 가장 많이 클릭하는 상품이 뭔지, 어느 페이지에서 채팅상담을 누르는지와 같이, 기본 GA가 제공하는 Pageview가 아닌, Click 에 대한 데이터가 쌓이는 레포트 입니다. 물론, GA 설치 후, 내가 필요한 Event 수집을 위한 별도 셋팅이 필요한데, 이 Event 수집에 대한 내용은 Google Tag Manager 카테고리의 글을 참조하길 바랍니다. (보통 GTM으로 이벤트를 수집합니다.) 이벤트가 발생할때, Event Category, Action, Lable, Value에 내가 원하는 값을 넣어줄 수 있기 때문에, 체계적인 naming convention 기반 Event를 수집해야 원하는 데이터를 쉽게 찾아볼 수 있다. 예를 들어 내 사이트의 모든 링크클릭(버튼)을 수집하고자 할때, 아래와 같이 셋팅하면, 어느페이지에서 어떤 버튼이 많을 많이 클릭하는지 확인하기 편할 것 이다. 이벤트 발생조건 :모든 페이지에서 링크가 있는텍스트를 클릭한 경우, 이벤트 발생 Naming convention Event Category : All Link Click // 이 이벤트가 발생한 경우 모두 All Link Click으로 지정 Event Action : {{Page Path}} // 이벤트가 발생한 페이지 주소 Event Lable : {{Click Text}} // 클릭한 버튼 이름 Event Value : 미지정 // 지정하지 않음 이런식으로, Click, Scroll Depth, Video, E-commerce, Duration 등 원하는 형태의 Event를 수집하면, 기본 GA로 도출하기 어려운 인사이트를 얻을 수 있습니다. 본인의 지식과 커리어 성장을 위해, 이 커뮤니티에서 GA를 활용하는 다양한 방법과 사례를 확인하고, 도움이 될만한 사례를 내 사이트에 적용하기 위해 어떤 데이터(Event)를 어떻게 쌓아야 할지 생각해보는것 을 권장합니다. 웹사이트 내 특정 이벤트를 얼마나 달성했는지를 보여주는 리포트. 영상시청, 스크롤, 문서다운로드 등.
-
Behavior – Content Drilldown: 사이트 폴더별 성과 확인
Behavior – Content Drilldown: 사이트 폴더별 성과 확인 내 사이트에 들어온 유저들이 어떤 컨텐츠, 상품, 카테고리에 관심이 있는지 확인하기 위해 사용되는 레포트입니다. 사이트 URL의 Path Level을 기준으로 3 Level(Depth)까지 컨텐츠를 얼마나 소비하는지 확인할 수 있습니다. 이 레포트 크게 2가지를 파악하기위해 사용됩니다. 1. 상품 카테고리 인기도 비교 : 경차, 세단, SUV, 스포츠카 등 각 카테고리별 총 페이지뷰, 체류시간, 이탈률을 확인하여 유저가 내 사이트의 어떤 카테고리에 관심을 가지는지 확인할 수 있으며, Level을 낮추면, 경차 안에서 스파크, 모닝, 레이 등 상품 별 비교도 가능합니다. 2. 카테고리 별 주요 타겟층 확인 : 경차-남성/25-34 // 세단-여성/35-44 등 Secondary Dimension의 Gender나 Age를 통해 각 카테고리 별 주요 연령/성별을 확인할 수있습니다. 위의 내용과 같이, Level을 낮추면 상세 상품 별 관심도가 높은 고객특징을 확인할 수 있습니다. 내 사이트에 유입한 유저가 각 카테고리 별 어떤 컨텐츠에 관심이 있는지 확인하기 위해선 Behavior – Content Drilldown 레포트를 활용하는것 을 권장드립니다. 웹 사이트 내의 폴더별 수치를 집계한 리포트로 사이트 카테고리 레벨 컨텐츠 소비량 파악 가능
-
Behavior – All Pages 보고서: 페이지별 성과 확인
Behavior – All Pages 보고서: 페이지별 성과 확인 사이트에서 어떤 페이지가 가장 많이 소비가 되는지 확인하기 위해선 Behavior – All Pages 레포트 확인해야합니다. 이 All Pages 레포트는 항상 Segment를 잘 활용해야 의미있는 정보를 알 수 있습니다. - 구매완료유저 Segment: 구매한 유저가 많이 보는 컨텐츠 확인 - 연령/성별 Segment: 각 연령/성별의 선호 컨텐츠 확인 - 특정 매체 Segment: 해당 매체의 목적(컨텐츠 소비, 정보획득, 구매 등) 확인 - 단어 Segment: URL에 특정 값이 들어간 페이지 리스트 확인 등등 Segment를 통해 다양한 인사이트를 얻을 수 있습니다. 또한 페이지의 퀄리티를 확인하기 위해선 아래와 같은 지표를 확인해야 합니다. - 페이지소비(빈도수): Pageviews와 unique pageviews 비교 - 컨텐츠 소비시간(매력도): Avg. Time on Page - 페이지 이탈위치: Bounce Rate와 Exit. (각 Metric은 스스로 자료를 찾아보시는 것 을 강력히 권장드립니다.) All Pages 레포트엔 기본 Explorer 말고도 Navigation summary라는 레포트가 있는데, 이 레포트를 통해 특정 페이지 전 후의 이동을 확인할 수 있습니다. 아주 매력적인 레포트이죠! 아래 이미지는 /naver-related-keyword/ 페이지를 중심으로, keyword search volume에서 가장많이 유입하기도, 이동하기도 한다는 것 을 알 수 있습니다. (두개 페이지를 왔다갔다 하네요 ^^) 이처럼 방문자의 컨텐츠 소비량을 보여줌으로써 사이트 내 어떤 컨텐츠가 인기가 있는지 그 효과는 어떠한지 파악 가능하며, 이를 통해 방문자의 웹사이트 경험 최적화에 도움을 줄 수 있습니다.
-
Audience – User Flow: 웹사이트 내 방문자 이동경로 확인
Audience – User Flow: 웹사이트 내 방문자 이동경로 확인 방문자가 어떤 채널을 통해 들어와 어떤 페이지들을 거쳐 어떤 페이지에서 나갔는지 파악하기 위해 사용되는 User Flow 레포트 입니다. 다만, 보통은 파악이 되지 않는다는게 문제입니다. 사이트 방문자는 일정한 패턴을 보이기보단, 여기저기 둘러보다 이탈하기때문에, 패턴을 찾기 어렵습니다. 저는 유저의 패턴을 찾기 위한 차선책으로, 내가 원하는 유저를 Segment 한 뒤, Behavior - All Pages 레포트에서 많이 본 페이지 내림차순 데이터를 참조합니다. 예를들어 상품을 구매한 사람을 Segment 한 뒤, All Pages 레포트로 가면, 메인페이지와 Checkout 1,2,3 페이지를 제외하면, 상품 구매한 사람들이 소비한 컨텐츠를 확인할 수 있습니다. 이 매력적인 컨텐츠를 기반으로, 마케팅활동(소재 제작 및 랜딩페이지)을 한다면 구매전환율이 높아질 가능성이 높아지는 것 입니다. 다시 본론으로 넘어가면, User Flow를 통해 패턴을 확인하긴 어렵지만, Dimension을 잘 활용하면, 어디서 유입하는 유저가 이탈이 높은지 확인하는데 활용할 수 있습니다. 예를들어, source/medium 을 하게 되면, 각 매체별 렌딩페이지의 이탈률을 직관적으로 확인할 수 있는것이죠, (직접 해보시면 이 글이 더 잘 이해될 것 같네요 ^^) 그럴싸 해보이지만, 큰 인사이트를 뽑긴 어렵다는 것과, 차선책을 알려드리기 위해 쓴 글입니다. 도움이 되었으면 좋겠네요! :) 한눈에 쉽게 파악가능한 시각화 보고서로, 이를 통해 페이지 퀄리티 관련 인사이트 도출 가능
전체댓글1
자세한 설명 감사합니다. path length로 현황파악 후에 top conversion path로 자세히 살펴보는게 좋겠군요