[Google Analytics] 구글애널리틱스 커뮤니티입니다. 구글애널리틱스관련 정보를 공유 해 주세요! 안녕하세요 도치쀼 입니다 :) 이전 글에서 '엑셀 시트와 빅쿼리를 연결하는 방법' 에 대해서 공유 드렸었는데 이번에는 제가 그 연동 이후에 위클리 리포팅을 위해 작업한 쿼리를 공유드리려 합니다. 이 글을 조회하는 분들이 저와 동일한 리포팅 폼을 활용할 가능성은 낮더라도 비슷한 고충이 있으시다면 참고하시길 바라며 이어서 적어보겠습니다 :) (쿼리 초보인데 좀 더 효율성을 높히는 방법이 보이신다면 언제든 피드백 부탁드려요~! ) 우선 쿼리를 공유드리기 앞서 제가 왜 위클리 리포팅에 쿼리를 활용하려 했고, 또 구체적으로 어떤 값들을 나오게 만드려는지 공유드리겠습니다. 아래의 포맷은 제가 리포팅하는 캠페인의 유입 세션수, 캠페인 내 이벤트 수, 캠페인 외의 구매 관련 행동 등에 대해 트렌드를 파악하는 리포트의 형식 입니다. 원래는 엑셀의 함수를 이것 저것 써가며 계산해오고 있었는데 빅쿼리에서 실행 버튼 클릭 한번으로 10개 국가의 세션수의 누적값 / 2초 이상 체류한 세션의 비율 / 금주 세션수 / 전주 대비 증감률을 구할 수 있다면...? 시도해 볼만 한 과정이죠 :) 기존에 제가 위의 리포팅을 작성할 때는 대시보드로 만든 테이블에서 값을 확인한 후, 그 값을 엑셀로 옮겨와 가공하여, 궁극적으로 저 형태로 ppt 를 만들어야 했는데, 값을 옮기는 과정에서 오류가 있을 경우 재작업을 한 적도 잦고, 함수를 복사/붙여넣기하는 과정에서 값이 누락되는 상황도 종종 있었습니다. 허나 이전 글에서 공유드린 '구글 시트와 빅쿼리를 연동' 하게 되면 실시간 연동을 통해 데이터를 빠르고, 정확하게 리포팅 할 수 있게 됩니다. 엑셀 함수 필요 없이 클릭 한 번 만으로요...! 즉 ,이렇게 아래처럼 구글 시트만 있으면 <구글 시트 업데이트 예시 -- 1월 15-21일 (1월 3주차) 데이터 업데이트> 뿅 하고 원하는 결과값들을 한번에 얻을 수 있답니다 <실행 후 예시 결과값 : 1월 3주차까지의 누적 세션수, 유효 세션수의 비중 , 이번주 총 세션수, 전주 대비 세션 증감률> [Let's Query!] 그럼 위의 리포팅에서 왼쪽 하단에 있는 Visit 항목들을 계산한 쿼리를 하나씩 파보겠습니다 :) Step 1 기존의 피벗 테이블 형식을 Unpivot 함수를 통해 풀어주고, sum () 윈도우 함수로 누적 세션수 값을 구해주는 테이블을 with 절로 만들어줍니다. SELECT PARSE_DATE('%Y-%m-%d',date)asdate, country, sessions, sum(sessions)over(partitionbycountryorderbydaterowsbetweenunboundedprecedingandcurrentrow)cumulated_sessions, FROM`lifesgood-test.lifesgood_weekly_reprot_format.organic_and_paid sessions_table` unpivot(sessions forcountry in(GLOBAL,KR,US,AU,DE,INDIA,SA,SAEN,SA_SAEN,AE,AEAR,AE_AEAR,VN,BR,daily_total)) Unpivot 함수를 통해 아래처럼 country 라는 컬럼에 국가코드값이 넣어지면서 피벗테이블 형식이 풀렸죠? 누적값을 구할때는 국가별로 partition by 를해주고, 날짜 순서대로 누적할 것 이기 때문에 order by date 를 해줍니다 이 테이블을 unpivot_sessions 라고정의하고 with 절로묶어줍니다. <+> window 함수 sum 의 특성상 위의 쿼리식과 sum(sessions)over(partitionbycountryorderbydate) 아래의 식은 같은 결과를 보여줍니다. sum(sessions)over(partitionbycountryorderbydate rows between unbounded preceding and current row ) Step 2 2초 이상 체류한 세그먼트의 세션수(valid_sessions) 테이블도 위와 동일하게 unpivot 해 준 다음 누적값을 구하고, unpivot_sessions의 date, country 를 키 값으로 조인해줍니다. Step 3 전주 대비 이주의 증감룰을구하기위해 lag 함수를통해 일주일전의값과이번주의값을같은행에서계산할수있도록만들어 줍니다. # LAG (sessions, 7) > sessions 의 7 번째 이전에 있는 값을 가져온다 ifnull(lag(sessions,7)over(partitionbycountryorderbydate),0)aslag_one_week #이때 null 값이 있으면 이후에 계산 시 오류가 발생하므로 ifnull 로 null 값들은 0 으로 만들어 줍니다. 이어서별도로생성해뒀던 regular_time 테이블과 between join 을하여 7일마다다른주차별기준점값을설정해줍니다. #Start_week 과 end_of_Week 를 7일간격으로설정한 regular_time table ‘between join’ <1월 1-7일은 1월 1주차 (24.Jan_first_weeK) 1월 8일-14일은 1월 2주차 (24.Jan_second_weeK) 으로 구분되어 regular_time 열이 생긴다> SELECT a.date, a. country, b.regular_time, a.sessionssessions, a. cumulated_sessionscumulated_sessions, ifnull(lag(sessions,7)over(partitionbycountryorderbydate),0)aslag_one_week a.cumulated_valid_sessionscumulated_valid_sessions, FROMbasica join `lifesgood-test.test.test_weekly_regular_week`bona.datebetweenb.start_week andb.end_of_week Step 4 위의 테이블에서 일반 세션과 지난주 세션에 대해 country, regulartime 으로 partition by 되고 날짜 순으로 누적값을 구합니다. select*, sum(sessions)over(partitionbycountry,regular_timeorderbydaterowsbetweenunboundedprecedingandunboundedfollowing) sum_this_week_sessions, sum(lag_one_week)over(partitionbycountry, regular_timeorderbydaterowsbetweenunboundedprecedingandunboundedfollowing)sum_last_week_sessions, frombase Step 5 이제 위클리에서 실제로 사용하는 포맷과 좀 더 유사한 형식으로 만들어 줍니다. 최종적으로 구하려는 값은 누적세션수 (유효 세션의 비율) | 1월 3주차 7일간의 총 세션수 | 1원 2주차 대비 1월 3주차 세션수의 증감률 입니다. *참고 STEP 4 에 있는 <예상 결과값> 테이블에서 Jan_third_week 에서 1월 21일 마지막 날짜 행의 값으로 확인 가능 cumulated_sessions 가 2,310 ------(누적 세션수, ) cumulated_valid_sessions 가 1,155 ------(유효 세션수) sum_this_week 이 1,260 ------(1월 3주차의 총 세션수) sum_last_week 이 770-------- (1월 2주차의 총 세션수) 하단 좌측의 계산식으로 우측의 결과 값을 구할 수 있게 됩니다. 이 계산식을 쿼리로 작성해주면 되겠죠! select country, regular_time, concat(cumulated_sessions,' (',round(cumulated_valid_sessions/cumulated_sessions*100,0),'%',')')ascumulated_sessions_and_valid_percentage, sum_this_week_sessions, concat(round(safe_divide((sum_this_week_sessions-sum_last_week_sessions),sum_last_week_sessions)*100,0),'%')aschange_percentage, row_number()over(partitionbycountryorderbydatedesc)asnumbering_cumulated_sessions frombase_table #safe_divide 를 쓰게 되면 분모가 0 이라 나눌 수가 없는 식이 나오더라도 무방 Step 6 일반적으로 리포팅은 가장 최근 7일을 기준으로 작성하지만 때때로 특정 기간에 대한 데이터를 고객사에 전달드려야 할 때도 있었는데요, 이를 위해서 각 주차별로 구분할 수 있는 값을 row_number 함수로 생성해주려 합니다. * row_number () 를 통해서 각 나라별로 누적 세션값에 date 를 내림차순으로 하여 순위를 만들어 줍니다. 해당 row_number () 값은 고정적인 값이 아니라, 새로운 데이터가 추가될 때마다 가장 최근 날짜의 값이 ‘1’ 로 설정되는 특징이 있습니다. 위와 같은 상태에서 select* fromdata_table where(numbering_cumulated_sessions-1)/7+1 = 1 orderbycountry >> where(numbering_cumulated_sessions-1)/7+1 값이 ‘1’ 이면가장최근의주차별값, 2라면 > 지난주 , 3이라면 지지난주 위와같이필터링할수도있고, 만약특정주차에상관없이특정날짜까지의 Vist 값들을원한다면 where date = '2024-01-21' 이렇게 where 절로 date 날짜를설정할수있습니다. FIN ---------------------------------------------------------- 이렇게 엑셀 작업으로 구해오던 값들을 쿼리로 표현해보았습니다 :) 리포팅이 워낙 케이스 바이 케이스지만 시간 절약과 정확성이 높아진 것들 경험하니 이후에도 비슷한 업무를 만나면 저는 쿼리를 쓰는 방법도 고민해볼 것 같아요 :) (이런 방법도 있다는것 자체를 인지를 못했어서 엑셀 노가다만 계속 했었다는 ㅜㅜ) 또 쿼리 초보에게는 증감률 계산을 위한 lag () 함수, 누적값 계산을 위한 윈도우 sum () 함수 를 직접 사용해 볼 수 있는 좋은 기회이기도 했답니다. 이 글 조회하시는 분도 저와 비슷한 고충이 있으셨다면 이런 선택지가 있다는게 도움이 되셨길 바라며 이번 글 마치도록 하겠습니다 :) 그럼 좋은 하루 보내세요~! ------------------------------------- *메모장이나 PDF 확장자 지원이 안되어서 ㅎㅎㅎ,,, JPG 로라도 총 쿼리 업로드 합니다
[Google Analytics] 구글애널리틱스 커뮤니티입니다. 구글애널리틱스관련 정보를 공유 해 주세요! 안녕하세요 ;) GA 데이터를 주로 활용하는 데이터 컨설턴트 입니다. GA 와 GA4 데이터로 10개 국가 리포팅 업무를 하던 중 빅쿼리와 엑셀 시트를 활용해서 업무 프로세스를 개선하게 되어 해당 경험을 공유 드리겠습니다 아래 글에서는 엑셀로 가공해오던 데이터를 빅쿼리에서 작업할 수 있도록 구글 시트와 연동하는 방법 및 연동시의 주의사항에 대해 말씀드릴게요 :) (다음 글: 연동된 데이터를 실제로 어떤 식으로 리포팅에 활용했는지 궁금하다면?) http://googleanalytics360.com/board/view.php?bo_table=googleanalytics&wr_id=73&page= ------------------------------------------------------------------------------------------------- [Problem has to be solved] 엑셀로 작업하는 단순 이벤트 구분 / 카운팅 업무의 속도와 정확성을 높혀야 할 필요성 인지 [Action to do] 구글 엑셀 시트에 작업해야 하는 엑셀 시트를 불러와, 해당 시트를 빅쿼리의 ‘드라이브 연동’ 기능을 통해 실시간으로 시트의 항목들이 빅쿼리에서 활용할 수 있도록 한다. (Process) 1. 쿼리로 활용할 기본 테이블을 엑셀 시트에 옮겨줍니다. (데이터는 예시값 입니다) >> 저같은 경우 피벗 테이블 형식의 각 국가별 일별 세션수 데이터인데요, 이 테이블 형태로 후에 쿼리 기본 작업이 들어갈 예정입니다 2.빅쿼리에서 프로젝트 > 세트를 생성하여 특정 세트 하위에 테이블을 만들어 주세요. '테이블을 만들 소스’ 중 드라이브를 선택합니다. 3. ‘Drive url 선택’ 에서는 구글 스프레드 시트의 url 을 넣어줍니다. >> 동일한 파일이더라도 각 시트마다 생성된 url 이 상이하며, 또 특정 시트를 지정해줄 때는 테이블에 기입한 url의 시트 이름을 넣어주면 됩니다. 4. 이어서 스키마를 설정합니다. 구글 시트에 있던 값들을 ‘순서대로’ , ‘데이터 유형’ 에 맞게 설정해줍니다. 이때 설정한 데이터 유형은 수정이 어렵기 때문에 String, Integer, Date 등을 잘 구분해줍니다. 이후에 구글 시트에 새로운 컬럼을 추가하게 된다면 가장 마지막 열의 뒤부터 추가 해야 합니다. 안그러면 스키마에서 설정한 순서와 달라져서 값들이 컬럼명과 매칭이 안 될수도 있어요 예를 들어 기존에 숫자형으로 등록했던 두 번째 열인 Global 열에 문자 형식 값을 가지고 있는 '안녕' 열을 추가하게 되면 기존에 빅쿼리 단에서 인식한 ‘두 번째 행’ 은 GLOBAL 처럼 Integer 형식이기 때문에 오류가 나고, <기존에 숫자형으로 등록했던 두 번째 열인 Global 열에 문자 형식 값을 가지고 있는 '안녕' 열 추가> <스키마 상 Integer 자리에 String 값이 있어 오류 발생> 만약 Integer 형식으로 값을 새로 넣었다고 하더라도, 빅쿼리에서는 ‘GLOBAL’ 컬럼 값을 구글 시트의 ‘안녕’ 컬럼으로 인식하게 됩니다. 의도했던 테이블이 완전 틀어질 수 있죠. <빅쿼리 상에서는 기존에 등록된 스키마 순서대로 GLOBAL 로 인식하여 '안녕' 열의 값들이 GLOBAL 로 조회되고 있음> 따라서 만약 테이블에 수정사항이 있다면 기존 가장 마지막 컬럼의 다음 컬럼에 생성을 해주고 빅쿼리의 해당 테이블에 ‘스키마 수정’ 을 클릭해서 해당 열만 추가해줄 수 있어요 <엑셀 시트 상에 새로 추가할 열을 입력> <빅쿼리의 해당 테이블에 대해 '스키마 수정' 클릭> <추가하려는 열을 필드 이름과 데이터 유형에 맞게 설정하여 저장> <빅쿼리 상에서 입력된 새로운 열 확인 가능> 위의 사항들을 고려해서 테이블을 생성해주었다면 엑셀 시트와 빅쿼리를 연결하는 방법은 끝입니다! 이처럼 구글 시트와 빅쿼리를 연동했을 때의 가장 큰 장점은 바로 엑셀 시트가 실시간으로 빅쿼리 상에 반영이 된다는 점 입니다. 예를 들어 제가 리포팅을 하다 보니 매주매주 새로운 값들이 업데이트 되는데, 해당 값들을 엑셀 시트에 추가해주기만 하면 빅쿼리에서 바로 인지할 수 있고 혹시나 데이터의 정합성을 체크하다가 틀린 값이 있더라도 그 부분만 수정해주면 빅쿼리 상에서 조회할 때 2중으로 수정해주는 수고를 하지 않아도 된다는 부분이죠 별 것 아닌 것 같지만 엑셀 시트 URL 로 빅쿼리에서 활용 가능할 수 있다는게 꽤나 유용했던 기능 이였습니다 :) 다음 글에서는 위의 연동 방식을 제가 어떻게 활용했는지 공유 드리겠습니다
GA360적용/가격/활용사례 공유. GA360 리셀러 플러스제로 Google Analytics 유료버전인 GA360을 이해하기 위해선, GA360이 무엇인지, 가격은 얼마인지, 타 업체는 어떻게 활용하고 있는지 알아야 합니다. 이번 글에선 GA360도입을 고려중이거나, GA360의 특징을 잘 모르시는분들이 GA360을 이해하고 사용할 수 있도록 GA360 적용방법, 가격, 실제 활용사례를 공유드릴 예정입니다. 글의 목차는 아래와 같습니다. 1. Google Analytics 360 Reseller 플러스제로 소개. 2. GA Standard vs GA360 특징, 가격/비용 및 적용방법 3. GA360을 써야하는 고객 + 활용사례 1. Google Analytics 360 Reseller 플러스제로 소개. 플러스제로(PLUS ZERO)는 Google Analytics 360을 제공할 수 있는 권한을 가진 GA360 Reseller이자, - GA구축: 기업 맞춤 Google Analytics 및 A/B Test, 데이터 시각화 대시보드 구축 지원 - GA Training: 구축 된 GA와 A/B Test, 대시보드를 잘 활용할 수 있도록 기업 맞춤 교육 지원 - Performance Ads: 광고+GA 데이터 기반, 광고비용 절감 및 ROAS 최적화 환경 구축 - SEO(Search Engine Optimization검색엔진최적화): 핵심 키워드의 검색결과 상위노출 가이드 - CRO(Conversion Rate Optimization구매전환율 최적화): 고객이탈 최소화 및 고객경험 최적화 - CRM 솔루션: 데이터레이크(ADs+Behavior+CRM) 구축 및 개인화메세지(popup, sms, push..) 제공 등 구축/컨설팅/솔루션을 제공하는 데이터 마케팅 에이전시입니다. 즉, 데이터를 활용하여 할 수 있는 성과높은 마케팅활동만을 중심으로 구축/컨설팅 서비스를 제공합니다. 기본 베이스가 컨설팅이다 보니, GA360고객에겐 추가 비용 없이 GA구축과 함께, Training, Q&A, SEO, Ads, CRM솔루션을 제공하고 있으며, 이 데이터마케팅 서비스와 CRM솔루션이 플러스제로의 차별화가 되었습니다. 2. GA Standard vs GA360 특징 및 적용방법 GA standard와 GA360의 가장 큰 특징은 데이터 소유권과 비용이다. 데이터 소유권에 대해 이야기 하기 전, 알아야 할 GA 기본개념이 있습니다. GA Standard는 '구글서버에 쌓인 내 사이트데이터'를 GA를 통해 view 하는 개념이고, GA 360은 구글이 'GA360 고객에게 고유한 서버를 열어주고, 거기에 내 사이트 데이터를 쌓는것' 입니다. 이것을 이해 하면, 데이터 소유권을 이해하기 쉽습니다. GA360은 rawdata를 다운받을 수 있기 때문에, GA와 Ads, CRM 등 다른 소스의 데이터와 맵핑할 수 있게 되고, 이것은 흔히 말하는 데이터웨어하우스, 데이터 레이크 등으로 사용할 수 있습니다. 궁극적으론 이 행동데이터와 고객데이터를 매칭하여 개인화 마케팅에 사용할 수 있게 되는 것 입니다. 고유 서버가 할당되기 때문에, 매우빠른 속도와 샘플링 이슈가 사라지는 것 도 큰 장점입니다. (GA 로딩.. 속터지죠... GA360 한번 사용하면 다시 Standard로 못돌아갑니다 ㅎㅎ) GA360은 보통 연간 1억 5000만원정도의 비용이 발생하는데, 그 비용만큼 GA360데이터를 잘 활용하는 업체는 드물기 때문에, 플러스제로가 데이터 기반 마케팅 최적화와 GA행동데이터+CRM데이터를 통합하여 개인화된 메세지를 보낼 수 있는 솔루션을 제공하고 있습니다. 불과 1~2년 전 까지만 해도, 샘플링 없는데이터, 빠른 데이터, User ID 데이터를 추출하는데 만족했던 고객들이, 데이터 마케팅이 성숙기에 접어들은 것인지, 데이터 '수집'이 아닌, '활용'에 집중을 하는 모습을 보이고 있습니다. 점진적으로 쿠키데이터가 사라짐에 따라, 1st Party 데이터를 활용하여 CDP(Customer Data Platform)를 구축하고 활용하는 고객이 늘어나는 것 을 채감하고 있습니다. 2014년부터 활동 해온, GA리셀러로서 이러한 성장. 변화는 너무나 긍정적이고 기쁜 현상입니다. GA360리셀러로서, 가장 많이 접하는 질문Top3는, GA360 가격, 기능, 사용방법이다. 생각보다 매우 간단하다. 1. GA360 가격 - Hit기준이며, 보통 연간 1억 5천만원정도이며, 매달 1250만원정도 청구가 된다. 2. GA360 주요기능 - 샘플링, 빠른속도, GA데이터 BigQuery연동, DFP 등이 있다. - 샘플링이 없기때문에, raw data 기반 레포팅, 데이터 추출, 쉬운 레포팅 가능. - 일반 GA대비 빠른 속도로, 원하는데이터를 빠르게 추출하고 분석 가능. - UserID(CRM과 Key값)를 포함안 raw data를 BigQuery와 연동가능하기때문에, CRM과 매칭하여 사용가능. (물론, CRM과 BigQuery 데이터 1:1로 매칭, Segment, Batch, Message등 활용개발은 별도이다) - DFA, DFP, SA360, DV360 등 다양한 솔루션과 함께 사용 가능. 3. 사용방법 - GA리셀러(플러스제로)에 GA360 사용요청 메일을 보내면, GA리셀러(플러스제로)에서 회신 한 견적서와 제공 서비스 확인 한 후, GA360계약 진행 - 플러스제로는 1주일 내 Google에게 계약한 고객의 계정을 GA Standard에서 GA360으로 업그레이드 요청 - 고객은 계약완료 1주일 이내 GA360을 사용 가능하며, 플러스제로로 매월 사용요금 지불 자세한 GA Standard vs GA360 차이점은 아래를 참조바랍니다. https://blog.naver.com/pluszeroinc/222213934187 3. GA360을 써야하는 고객+ 활용사례 GA360 전환 요청이 오는 고객의 니즈는 크게 2가지로 나뉩니다. 1. 자사 행동데이터 수집: GA 행동데이터를 자사 데이터와 통합하여 고객행동패턴 분석 2. 개인화 마케팅: 유저가 특정 행동을 한 경우, 문자, 메일, 푸시, 광고를 보내기 위한 데이터 소스 플러스제로는 아래 이미지와 같이 이 1,2번 니즈에 대한 정형화된 솔루션을 제공합니다. 1. 자사 행동데이터 수집:행동데이터+고객정보(GA360+CRM) 뿐 아니라, 광고데이터+행동데이터(Ads+GA360)솔루션을 제공하고있습니다. 아래 이미지처럼 별도 개발작업 없이, Ads 계정 공유만으로 가능한 Ads+GA 데이터 매칭을 할 수 있고, 데이터를 시각화 할 수 있습니다. 아래 이미지처럼, 데이터스튜디오에서 광고비용대비 매출 성과를 본다는것 은, 매일 반복되는 엑셀 레포팅과 분석시간을 획기적으로 줄일 수 있다는 것입니다. GA360_플러스제로 2. 개인화 마케팅: 플러스제로는 기존 Salesforce와 같은 대규모 개발작업과 비용이 발생하는 것 을 부담스러워 하는 고객을 위해 GA360 고객에게는 아래 이미지와 같이, 특정 조건을 달성한 고객(Target Audience)에게 일정 시간(Batch)마다 이메일, 문자, 카카오, 푸시 등 개인화 된 메세지를 전달하는 솔루션 Live Insight를 함께 제공하고 있습니다. GA360 데이터가 담긴 BigQuery를 Live Insight에 연동하고, 고객정보데이터를 엑셀형태로 업로드하면 자동으로 행동데이터와 고객정보가 매칭됩니다 :) BigQuery데이터, Ads, CRM 데이터가 매칭되어, 유저를 식별하고, 메세지를 보낼 수 있는 LIVE Insight(GA360고객만 사용가능, 별도 CRM 매칭을 위한 개발작업 없이 엑셀 형태로 CRM 데이터 업로드&매칭) 추가적으로, BigQuery활용을 어려워 하는 고객을 위한 Query Generator와, 만들어진 Query(Target Audience)에게 일정시간마다 메세지를 보내는 Queried (이미지 클릭하시면 크게보실 수 있습니다)를 함께 제공합니다. GA360_플러스제로 GA360_플러스제로 쓰다보니 3시간이 지났네요, 최대한 간단히 쓴다고 썼는데, 길어져버렸습니다. 이 글이 GA360 특징과 활용에 대한 이해를 높이고, GA360도입에 도움이 되었으면 좋겠네요! :) GA360이 나온지 벌써 8년이 넘었고, 이제서야 고객들이 GA행동데이터를 Ads와 CRM과 통합하여 개인화 마케팅에 활용하고자 하는 니즈를 느끼고, 실행하는 단계에 온 것 같아 기분이 매우 좋습니다. 만약 GA360을 사용하여 개인화 된 마케팅활동을 할 생각이 있다면, 이미 솔루션이 구현 된 플러스제로로 연락주세요 :) GA360 활용사례, 가격, 솔루션에 대한 내용을 공유드리겠습니다. 감사합니다. 플러스제로
빅쿼리(BigQuery) 활용 1. CRM+GA360 1st Party data lake 구축 :: Live Insight 데이터 중요도가 늘어남에 따라 빅쿼리를 사용하는 업체들이 많아지고 활용사례를 궁금해 하는분들이 많습니다. 때문에, 이번 글은 기업들이 어떻게 빅쿼리를 활용하고있는지 이야기 할 예정입니다. 목차는 아래와 같습니다. 1. 빅쿼리(BigQuery) 활용 산출물 2. CRM + GA360 데이터 통합 (1st Party Data Lake) 3. 1st Party Data Lake 기반 개인화 메세징 성과 재미있는 내용만 최대한 간단히 써보겠습니다! :) 1. 빅쿼리(BigQuery) 활용 산출물 결과물 먼저 보여드리자면 아래와 같다. 구글애널리틱스360 데이터와 고객정보를 빅쿼리에 모으고 User ID기준으로 맵핑을 하면 아래와 같이 누가 언제 어디서 들어와서 어떤 액션을 했는지 알 수 있다. GA와 고객정보가 맵핑(1st Party Data Lake)되었기 때문에, 이미지 처럼 특정 액션을 한 사람들을 필터링 한 뒤(Segment & Target Audience), 메세지를 보낼 수 있는 환경이 조성된다. (미리 자랑을 하자면, 특정기간 데이터 외에, 실시간으로도 데이터가 업데이트 되고, 메세지를 보낼 수 있다!) BigQuery+GA360=LIVE INSIGHT 빅쿼리+구글애널리틱스 라이브인사이트 2. CRM + GA360 데이터 통합 구글애널리틱스360은 빅쿼리와 연동되기 때문에, CRM 데이터만 빅쿼리에 넣고 맵핑할수 있으면 1st Party Data Lake가 만들어 집니다.(그게 문제긴 하죠.. 넣고 맵핑하는것..) 플러스제로 고객에게만 제공하는 LIVE INSIGHT는 아직은, 아래 이미지처럼 고객정보(CRM)는 아직은 엑셀파일로 업로드해야합니다. 엑셀 업로드의 장단점이 있는데, 장점은 개발작업 없이 GA360데이터와 CRM을 매칭시키고 개인화된 메세지를 보낼 수 있다는 것이고, 단점은 주기적으로 엑셀을 업로드 해야한다는 것입니다.(CRM API는 개발중에 있습니다.) 마케터 입장에선 오히려 엑셀로 올리는 것이 개발인력을 끼지 않고, 보안이슈도 없이, 빠르게 쓸 수 있어서 좋아하기도 합니다 :) BigQuery+GA360=LIVE INSIGHT 빅쿼리+구글애널리틱스 라이브인사이트 아래는 GA와 CRM 맵핑 이해를 돕기 위한 이미지이며, 행동데이터와 CRM이 맵핑되었기 때문에, 특정 액션(상품확인, 구매시도)을 한 고객이 누구인지 알고, 그에게 문자나 카카오톡, 메일을 보낼 수 있습니다. 1st party data lake GA360 + CRM 매칭 개념 이렇게 빅쿼리에 구글애널리틱스360과 CRM을 통합&매칭하면, 한단게 진화된 마케팅활동을 할 수 있게 됩니다. 이것이 1st Party DataLake를 빅쿼리로 활용하는 이유입니다. 물론 GA standard버전이 아닌 구글애널리틱스360을 사용하셔야 GA데이터를 빅쿼리에 가져올 수 있으니, 구글애널리틱스360을 쓰는 고객이라면 CRM과 연동하는것을 강력하게 권장합니다. 3. 1st Party Data Lake 기반 개인화 메세징 전송 실제 개인화메세지 발송 사례를 가지고 왔습니다. 아래 이미지와같이 VVIP만큼 Target Audience(GA타겟팅)의 오픈율/전환율이 높은것 을 확인할 수 있습니다. 큰 비용 없이 높은 전환율을 보이는 고객의 재방문을 유도하고, 장기적으로 VIP를 늘려나가는 효과적 활동 입니다. GA+CRM Target Audience Performance 최근 빅쿼리를 잘 사용하는 기업들은 이렇게 행동데이터와 개인정보를 맵핑하여 개인화된 메세지를 보내는 활동을 하고있고, 이를 자동화 하는 단계에 있습니다. 다음단계는 실시간(Batch Time 30분 이내)으로 메세지를 보내는 단계로 생각됩니다. (개발중에 있습니다 ㅎㅎ) 글을 쉽게 쓰려다보니, 쓰고 지우고 위치를 바꾸는 행동을 열번은 반복한것 같네요! 이 글이 빅쿼리를 이런식으로도 활용할 수 있다는것을 알리는데 도움이 되었으면 합니다! :) GA+CRM에 이어, Ads+GA를 통한 퍼포먼스 마케팅 최적화 및 시각화 대시보드에 대해 이야기 하겠습니다. 감사합니다. 플러스제로.
구글애널리틱스에서 마케팅 채널 혹은 특정 캠페인의 성과를 측정하기 위해 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 틀려서 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 무한로딩 열받아서 우리 개발자한테 만들어달라 함 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 레포트를 한번도 안 쓴사람은 있어도, 한번만 쓴 사람은 없는 툴일것이다. (레포트의 속도와 데이터 합치기의 귀차니즘을 한번에 해결할 수 있다)
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 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 차이점. 구글애널리틱스 구글 공식 프리미엄파트너 플러스제로. 끝.
구글 태그매니저(GTM. Google Tag Manager) – 이전 페이지 데이터 가져오기 최근에 프로젝트를 진행하다가, “사용자들이 특정 페이지까지 도달하기까지 약 몇 개의 페이지를 볼까?” 라는 생각이 들더군요. 이에 따라 “Pageview Counter”(페이지 조회기)를 만들어서 데이터를 쌓아봐야겠다는 생각을 했습니다. 하지만, 이를 구현하는 것이 말처럼 쉽지 않습니다. 특히, 비개발자라면 더욱 어려울 수 있습니다. 이유는 꽤 간단합니다. 바로 자바스크립트와 HTML의 특성 때문이죠. 자바스크립트와 HTML으로 이루어진 웹페이지에선 페이지가 로드될 때 마다 연관된 모든 변수, 함수, 객체, 데이터 등이 다시 정의됩니다. 즉, 내가 특정 데이터를 어딘가 저장을 하더라도 페이지가 다시 로드가 되면 그 값은 리셋이 되는 것이죠. 이런 특성 때문에 우리가 원하는 데이터를 보존하지 못하는 경우가 종종 있습니다. 특히, dataLayer를 활용해야만 하는 구글태그매니저(GTM. Google Tag Manager)는 페이지 이동에 따른 데이터 보존이 좋은 편은 아닙니다. 그 이유는 구글태그매니저의 dataLayer도 결국엔 객체를 담은 자바스크립트 Array이기 때문에, 페이지가 새롭게 로드되면 모든 값들이 리셋되기 때문이죠. 예를 들어서, 어떤 디지털 마케터가 Pageview Counter 구현을 위해 변수 “Count”라는 것을 만들고, 페이지가 매번 로드될 때 마다 dataLayer에 Push함으로써 총 페이지 소비량을 확인하고 싶다고 가정하겠습니다. 이 방식대로 진행하면, 페이지 A에서 값이 잘 들어가지만, 페이지 B로 이동하게 되면, Count 계속 페이지 카운트가 1에 머물게 됩니다. 자, 그러면 구현이 안되는 것 같으니 그냥 포기를 하는 것이 나을까요? 전혀 아닙니다! 사실 Web Storage를 활용할 줄만 알면, 페이지 이동 중에 특정 값을 보존하는 것은 그렇게 어려운 일이 아닙니다. 그리고 Web Storage는 특별한 개발 지식이 없어도 모든 사람들이 아주 쉽게 사용할 수 있습니다. 오늘 여러분들께 이 저장 공간을 소개시켜드리고, 어떻게 활용할 수 있는지를 구글태그매니저(GTM. Google Tag Manager)를 활용한 Step by Step으로 알려드리고자 합니다. Session Storage & Local Storage 소개 Session Storage와 Local Storage는 HTML5에는 웹싸이트의 데이터를 저장할 수 있는 새로운 자료구조인 Web Storage입니다. Web Storage는 특정 정보를 영구/반영구적으로 저장할 수 있다는 점에서 쿠키와 아주 유사하다고 볼 수 있습니다. (물론, 분명히 쿠키와 다른 점이 있긴 합니다.) 어쨋든 Web Storage인 Session Stroage와 Local Storage는 브라우저 내에 Key & Value 쌍을 저장할 수 있습니다. Key & Value 쌍은 기존 dataLayer에 데이터를 넣었던 Object 형태와 동일하다고 보시면 됩니다. (e.g. {counter: 1}) 이 두 개의 Storage들은 데이터 지속 기간에서 차이점을 가지고 있지만, 어쨋든 둘 다 페이지를 새로 고침하거나 이동하더라도 데이터가 사라지지 않고 보존됩니다! 심지어 Local Storage는 브라우저를 아얘 꺼버리고 다시 실행해도 저장한 데이터가 남아있기도 하죠. Session Storage와 Local Storage는 동일한 메소드를 제공하는데요, 구글태그매니저(GTM. Google Tag Manager)에서 Storage 활용을 위해 알아두셔야할 주요 메소드만 간략하게 설명드리겠습니다. setItem(key, value) -> Key & Value 쌍을 저장합니다. (dataLayer Push와도 같다고 보시면 됩니다.) getItem(key) -> 선택한 Key에 해당되는 Value 값을 불러옵니다. removeItem(key) -> 선택한 Key에 해당되는 값을 불러와 Key & Value 모두 다 삭제합니다. clear() -> Storage안에 있는 모든 값을 다 삭제합니다. length -> Storage에 저장된 항목의 총 개수를 불러옵니다. 자, Web Storage는 분명 구글 태그매니저(GTM)를 다루는 유저들에겐 큰 희소식입니다. 이를 잘 활용하기만 하면, 양질의 새로운 데이터를 수집이 가능해지니까요. 그러면, 이제 한번 Session Storage와 Local Storage의 특성에 대해 알아보도록 하겠습니다. Session Storage의 특성 Session Storage의 특성은 아래와 같습니다. 현재 세션이 활성화된 기간에만 사용할 수 있습니다. 탭이나 창을 닫는 것과 같은 이탈 행위가 발생하면, Session Storage는 리셋됩니다. 반면에 새로고침은 Session Storage 데이터에 영향을 주지 않습니다. 세션에만 데이터가 지속되고, 세션이 끝나면 데이터가 삭제된다고 생각하면 되겠습니다. Local Storage의 특성 Local Storage의 특성은 아래와 같습니다. 브라우저나 OS가 재시작되더라도 데이터는 계속 보존됩니다. 탭을 여러개 열어도 저장된 데이터는 계속 공유됩니다. 저장된 데이터는 향후 사이트를 방문하더라도 사용할 수 있습니다. 사용자가 직접 삭제를 하지 않는 이상, 데이터가 영구적으로 지속됩니다. 자신이 수집하고자 하는 데이터를 잘 생각해서, 각 특성에 알맞게 Storage를 선택해주시면 되겠습니다! Session Storage와 Local Storage 활용하기 이제 Web Storage의 특성과 사용법에 대해 알게 되었으니, 한번 구글태그매니저(GTM)에서 활용해보도록 하겠습니다. 서론에서 언급했다시피, 저는 “Pageview Counter”를 구현하고, Custom Dimension화 시켜서, PageView Hit와 같이 구글 애널리틱스에 보내도록 하겠습니다. 아래와 같은 GTM 세팅을 진행해주셔야 합니다. (1) Custom HTML 태그를 생성해서, 페이지 이동마다 변수 “Counter”가 1씩 증가시키고 그 값을 Session Storage에 저장합니다. 해당되는 코드는 아래와 같습니다. <script> if(sessionStorage.getItem("_PageViewCounter") == null || sessionStorage.getItem("_PageViewCounter") == undefined) { sessionStorage.setItem("_PageViewCounter", 1); } else { var counter = 0; counter = parseInt(sessionStorage.getItem("_PageViewCounter")); counter = counter + 1; sessionStorage.setItem("_PageViewCounter", counter); } </script> 코드를 간략하게 설명드리면, “_PageViewCounter”라는 Key 값을 Session Storage에서 찾습니다. 만약 값이 비어있거나 존재하지 않다면, 첫 페이지 조회임으로 “_PageViewCounter”에 1을 넣어줍니다. 반대로 “_PageViewCounter”에 값이 존재한다면, “_PageViewCounter”에 있는 값을 Integer로 변환한 후, 해당 값에 1을 더해줍니다. 그리고 나서, 1이 추가된 값을 다시 Session Stroage에 넣어줍니다. 아주 간단하고 쉬운 알고리즘입니다. 실제 GTM 화면 예시는 아래와 같습니다: 해당 HTML 태그에는 Tag Sequencing으로 발동을 시킬 것이기 때문에 별도의 Trigger는 필요하지 않습니다. (2) All Pageview 태그로 가셔서 “Fire a tag before <태그 이름> fires” 를 선택하셔서, 만드신 Custom HTML을 선택해주시면 됩니다. ※ 위와 같이 Tag Sequencing으로 세팅하는 이유는 간단합니다. 이 Custom HTML 태그는 Tag Sequencing을 통해 Pageview보다 더 빠르게 실행되어야 합니다. 왜냐하면, 결국엔 Counter라는 변수는 All PageView 태그의 Custom Dimension으로 들어가야만 구글 애널리틱스에 동시에 전송되기 때문이죠. (3) Session Storage에서 “_PageViewCounter”를 불러오는 GTM Custom JavaScript 변수를 생성해야 합니다. function() { var pageviewCounter = parseInt(sessionStorage.getItem("_PageViewCounter")); return pageviewCounter; } 실제 GTM 화면 예시는 아래와 같습니다: (4) GA에서 Custom Dimension 생성 후, All Pageview 태그에 들어가서 Custom Dimension을 추가하시면 됩니다. 당연히 GA에서 Custom Dimension을 별도로 추가해주셔야 실제 GA로 데이터가 들어가는건 다들 아실 것이라 생각합니다. 실제 구글태그매니저(GTM) 화면 예시는 아래와 같습니다: PageView Counter 결과 위 프로세스를 따르시면, 페이지 조회 Hit가 발생할 때마다 “PageView Count” 라는 Custom Dimension이 같이 들어가게 됩니다. 이를 통해 다양한 분석을 진행할 수 있을 것이라 생각됩니다. 예를 들어 상품 상세 페이지까지 도달하기까지 얼마나 많은 페이지를 소비하는지를 확인하고 싶다고 가정하겠습니다. 그러면, 구글 애널리틱스 “All Pages” 리포트에 가셔서, Secondary Dimension으로 “Pageview Count” Dimension을 추가해주시면 됩니다. 그러면 아래와 같은 데이터를 확인해보실 수 있습니다. 많은 유저들이 상품 조회 페이지까지 약 4~5개의 페이지를 조회하고 상품 상세 페이지로 들어오는 것을 알 수 있겠습니다. 마무리 PageView Counter는 Web Storage를 활용한 아주 단편적인 예시입니다. 데이터가 보존된다는 특성을 잘 사용하면, 정말 다양한 데이터를 수집 및 분석하실 수 있을 것이라 생각됩니다. 이 글이 GTM을 다루는 여러분들께 조금이나마 도움이 되셨으면 좋겠습니다. 관련해서 궁금한 것은 언제든지 아래 댓글을 통해 남겨주시면 답변 드리도록 하겠습니다~!
구글 애널리틱스 – 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를 마스터하고 보다 다양하고 정확한 데이터들을 수집할 수 있는 마케터가 되면 좋겠다.
[성공사례 3rd Party Data] 한국 광고 데이터와 구글애널리틱스 데이터 병합 프로젝트 플러스제로의 클라이언트를 대상으로 성공적으로 광고 데이터(Naver, Facebook, Kakao, Google Ads)와 Google Analytics 데이터 병합 및 시각화 대시보드를 제공합니다. 과거 광고 따로, GA 따로 엑셀로 받고 합치는 중간과정을 없애고, Ads와 GA가 매칭 된 데이터가 매일 자동 업데이트 되는 대시보드를 통해, 레포팅, 성과분석 및 최적화를 자동화 하였습니다. 간단히 설명드리자면, 네이버, 카카오, 페이스북, 구글 등 대표 광고플랫폼에서 빅쿼리(BigQuery)로 데이터를 매일 자동으로 송출하는 환경을 만든 뒤, 구글 애널리틱스 데이터와 빅쿼리(BigQuery)데이터를 시각화 대시보드 툴인 구글 데이터스튜디오(DataStudio)와 연동하여 시각화 하는 것 입니다. 광고 데이터를 불러오는것 은 크게 어려운 일은 아니지만, 매일 자동으로 불러오고, 구글 애널리틱스의 지표와 매칭시키는 과정은 개발, 서버, 광고, 구글애널리틱스 지식이 있는 인력이 협업을 해야하는것이 문제 였으며, 플러스제로는 이를 해결할 수 있는 솔루션을 구축하였습니다. Project Objective 한국에서 사용되는 대표적인 디지털 광고 플랫폼으로 네이버, 카카오, 페이스북, 구글로 꼽을 수 있습니다. Google Analytics는 Google Ads(Google AdWords)와 같은 GMP이기 때문에 아주 쉽게 연동 되지만, 다른 플랫폼들은 Google Analytics와의 자동 연동이 지원되지 않아 많은 분들이 불편함을 겪고 있습니다. 저희 클라이언트는 당시에 활발하게 다양한 광고를 운영 중에 있었고, 각기 다른 플랫폼에서 매일 데이터를 수동으로 끌어와 한 곳에 모아 데이터를 합쳐야만 했습니다. 또, 심지어 이 광고 데이터들은 Google Analytics와 연동이 되지 않기 때문에 CPC / CTR / 간단한 Conversion 관련 Metric들로만 데이터를 분석하는 상황이었습니다. How PlusZero Handled It? PlusZero는 이 문제를 해결하기 위해 한국의 3대 매체인 네이버 / 페이스북 / 카카오 API를 활용하여 모든 퍼포먼스 데이터를 매일 자동으로 추출하여 BigQuery와 Google Analytics에 업로드하는 솔루션을 개발했습니다. 또한, 닐슨에서 제공하는 TV 시청률과 네이버의 실제 키워드 검색량 데이터 또한 광고 데이터와 병합하여, 트렌드에 따른 자신의 광고 성과를 아주 직관적이게 확인할 수 있도록 만들었습니다. 모든 광고가 “직접 전환”에만 영향을 미치지 않습니다. 대표적인 예시로 Display 광고는 “간접 전환” 데이터를 함께 보는 것이 중요합니다. 그래서 PlusZero는 Assist Conversion 데이터도 Google Analytics Reporting API를 통해 추출하여 광고 성과와 함께 확인하실 수 있도록 했습니다. 병합된 모든 데이터를 Database에 저장해드리는 것뿐만이 아니라, 보기 쉽게 Google DataStudio로 시각화를 하여 회사 모든 구성원들이 한 눈에 퍼포먼스를 파악할 수 있도록 만들었습니다. MAPPED 보러가기 이 광고와 구글애널리틱스 데이터를 시각화하여, 한눈에 광고성과를 파악하여, 성과가 낮은 광고, 캠페인, 키워드를 줄이고, 성과가 높은 광고를 확장하여, 광고비용을 줄이고 매출을 극대화 할 수 있는 환경이 조성되었습니다. Project Outcome PlusZero는 성공적으로 광고 운영과 데이터 분석에 꼭 필요한 데이터를 수집하고 병합할 수 있었습니다. 광고 성과 데이터, Assist Conversion, 산업 Trend 등 수 많은 데이터들이 Google Analytics와 합쳐져 클라이언트에게 쉬우면서 풍부한 데이터 시각화 대시보드를 전달할 수 있었습니다.
[성공사례 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 데이터로 대체할 수 있었고, 정확한 데이터를 기반으로 마케팅 활동을 이어 나가고 있습니다.
HQ 중앙관리를 위한 글로벌 기업 데이터 통합 구축 및 관리 국가 별 구조화 된 데이터 수집 및 HQ 통합관리 환경 조성 Project Objective 다양한 국가에서 진행되고 있는 비즈니스의 현황을 한눈에 파악하고, 국가간 벤치마킹을 할 수 있는 환경 조성 HQ에서 각 채널 별 우수한 KPI를 달성한 국가의 마케팅 전략을 파악하고 정리하여 타국가에 공유 How PlusZero Handled It? PlusZero는 모든 국가의 Google Analytics 셋팅과 KPI를 동일하게 진행하고, DataStudio를 통해 한곳에서 모든 국가의 KPI를 확인할 수 있는 환경을 조성하였습니다. 매달 각 국가별 이슈와 개선점을 정리하여 HQ 담당자에게 전달하고, 개선이 시급한 국가 마케팅 담당자에게 개선 가이드를 제공하여 모든 국가의 마케팅 상향 평준화 달성
UX 최적화를 위한 하이브리드 어플리케이션 A/B Test 환경 구축 App Store 업데이트 및 Publish 없이 자유로운 APP A/B Test 환경구축 Project Objective 어플리케이션은 App Store가 A/B Test 활성화에 큰 걸림돌입니다. Remote Config는 어플리케이션의 특정 부분을 선택하여 그 값을 자유롭게 바꾸는 데 제한이 없었지만, “새로운” 화면 혹은 부분을 선택하게 되면 어플리케이션 업데이트 및 App Store Publish가 필요합니다. 잦은 어플리케이션 업데이트는 유저들에게 불편한 경험으로 이어질 수 있습니다. How PlusZero Handled It? PlusZero는 이 문제를 해결하기 위해 최초 1회 업데이트 이후 별도 퍼블리시 없이, 모든 스크린에 A/B Test가 가능한 PlusZero Remote Config Module를 개발하였습니다. App 고객경험 최적화가 필요한 고객은 최소한의 퍼블리시만으로 제약없는 UX개선 A/B Test를 진행할수 있게 되었습니다.
Google Analytics Ecommerce Data 정확도 99% Measurement Protocol을 통한 실 결제 데이터 기반 결제 데이터 수집 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를 개발하여 99%의 매출 정확도를 기록했습니다.
WEB+APP+CRM 데이터 통합(data warehouse) 및 시각화 대시보드 구축 Project Objective APP은 Google Firebase 기반 데이터를 수집하고, WEB은 Google Tag Manager와 Google Analytics를 사용, 회원정보는 각 CRM 솔루션에서 데이터가 수집됩니다. 우리의 고객은 App, Web, CRM 데이터를 한곳에 통합하고, 이 데이터를 시각화 하고싶었습니다. How PlusZero Handled It? PlusZero는 Firebase와 Google Analytics를 WEB APP Property[GA4]에 연동하여 APP+WEB 데이터를 BigQuery에 보낸 뒤, CRM 역시 BigQuery에 넣어 전처리 및 매칭하는 프로젝트를 진행하였고, 이 APP+WEB+CRM 통합 데이터 기반 비즈니스 현황 시각화 프로젝트를 진행하였습니다.
CaseStudyGA360 & Query생성기& Audience Batch
CaseStudy GA360 & CRM & AdsRe-Targeting
광고, CRM, GA 데이터 레이크 구축 및 시각화 데이터 레이크를 통해 모든 데이터 통합 및 시각화를 통한 데이터 활용 환경구축