쇼핑몰 솔루션에서 GA스니펫 기존방식과 GTM을 동시에 쓰기 위한 작업 후기

2017.01.13 15:34

하루네

쇼핑몰 솔루션에서 GA스니펫 기존방식과 GTM을 동시에 쓰기 위한 작업 후기

안녕하세요. 종종 댓글만 달고 매번 눈팅만 하다가 용기를 내어 글을 올려봅니다.

오래 전부터 저희 쇼핑몰에 GTM을 도입해보고 싶다고 생각만하다가 이번에 도입을 결정하면서 작업을 진행 중인 상황입니다. 그 과정 중에 이런저런 상황을 겪으며 작업한 후기, 삽질기(?)를 올려드리고자 합니다.

처음에는 작업 내용 기록 목적으로 문서를 만들었습니다만, 저희 삽질경험이 혹시라도 도움이 되지 않을까 하는 마음에 글로 올려봅니다. 항상 아이보스에서 도움을 받고 있는데, 저도 작은 도움이 될 수 있었으면 하는 바람을 가져봅니다. 글이 상당히, 아주 많이 깁니다. 따로 나눠서 게시할 정도로 거창한 내용은 아니라서 하나로 길게 가져가보겠습니다.

1. GTM 도입배경

2. 쇼핑몰 솔루션, 템플릿 구조에 GTM 도입 시 어려운 점

3. 쇼핑몰 솔루션의 예상치 못한 행동 - 솔루션의 코드 강제치환

4. 쇼핑몰 솔루션의 예상치 못한 행동 - iframe

5. GA와 GTM을 동시 쓰는 것에 대하여

6. 작업에 도움이 되는 도구들

7. 추가 고찰

8. 참고자료

1. GTM 도입배경

결정적으로 결심하게 된 이유는 이전 김종진 보스님께서 올리신 “구글 태그 관리자를 활용하여 검색광고 캠페인 추적 설정하기” 글이었습니다.

참고글 http://www.i-boss.co.kr/ab-74772-762

GA를 사용하면서 점차 쇼핑몰 내부 배너, 메뉴 등의 성과를 측정해야 할 필요성이 생기고 있었습니다. 그런데 이를 GTM을 활용하지 않고 이벤트 태깅을 하기에는 쇼핑몰 곳곳의 html마다 수정이 들어가야 하는데, 이 경우 추후 관리가 상당히 어려울 것으로 생각되었습니다. 그래서 GTM을 도입하려고 고민 중이었는데 위의 글을 보고 이건 도입을 해야만 한다는 쪽으로 생각이 바뀌었습니다.

크게 두 가지 이유에서 입니다.

첫째, 기본적으로 네이버 클릭초이스 검색광고, 다음 검색광고 등만이라도 UTM 태깅 작업에서 자유로워 질 수 있다면 평소 키워드검색광고 소재 관리에 있어 엄청난 효율이 생깁니다. 소재별, 랜딩페이지별로 UTM 넣다가 실수해보신 경험 종종 있으실 것입니다. 효율도 효율이지만 작업 실수의 가능성이 생길 여지가 없다고 봅니다. 실무관점에서 신속성과 유연성을 가져올 수 있기 때문에 이후 마케팅 전략의 기동성이 좋아진다고 봅니다.

두번째, 네이버쇼핑, 네이버쇼핑검색광고 등이 UTM 태깅이 가능할 경우 이 부분을 GA에서 소스/매체가 아닌 캠페인으로 분류해 파악할 수 있다는 것입니다. 이 두 가지 트래픽은 상당수가 naver/organic에 섞여서 유입이 됩니다. 보고서를 필터링해서 볼 수는 있기 때문에 반드시 utm 태깅이 필요 없다고 볼 수도 있지만, UTM 태깅을 통해 캠페인으로 분류를 하게 되면 [전환]-[다채널 유입경로]-[지원 전환] 보고서를 활용할 수 있게 됩니다. 여기서 캠페인별로 지원 전환 경로를 파악하게 되면 네이버쇼핑과 네이버쇼핑검색광고의 효과를 좀 더 자세히 살펴볼 수가 있습니다.

여기에 약간 다른 이야기를 곁들이자면, 요즘은 네이버페이 결제가 상당한 비중을 차지하여 위의 [전환]-[다채널 유입경로]-[지원 전환] 보고서에서 실제 구매전환을 추적하기가 쉽지가 않습니다. 네이버페이 결제의 경우 구매전환으로 집계할 방법이 없기 때문입니다. 하지만 [다채널 유입경로]보고서에서는 미리 설정해놓은 목표에 대해서도 전환 추적이 가능하고 저희는 이 부분이 상당히 유용하다고 보고 있습니다. 예를 들어 페이지뷰가 얼마 이상 도달하는 것을 목표로 하거나, 체류시간을 목표로 해놓고 해당 목표가 어떤 경로를 따라 전환이 달성되는지를 파악하는 것만으로도 사용자의 행동흐름을 파악할 수 있고 이에 맞춰 마케팅 예산을 분배할 수가 있습니다.

네이버쇼핑, 네이버쇼핑검색광고 뿐이 아니라 이전 김종진 보스님의 글에서도 서술되었듯이 그동한 UTM태깅이 불가능해 추적이 어려웠던 다양한 매체에 대해서도 접근이 가능합니다. 이 두 가지 이유가 저희가 GTM 도입을 결정하게 된 이유였습니다.

2. 쇼핑몰 솔루션, 템플릿 구조에 GTM 도입 시 어려운 점

GTM을 도입할 경우 전자상거래, 향상된 전자상거래 기능을 사용하기 위해서는 이와 관련된 data layer를 설정할 수 있어야 합니다. 어느 정도의 프로그래밍 지식이 없이는 조금 어려운 작업입니다. 게다가 이것을 쇼핑몰 솔루션 구조를 생각하며 해야 하기 때문에 관련 경험이 약간 있어야 작업이 가능하다고 생각합니다.

쇼핑몰 솔루션은 보통 템플릿 구조입니다. 웹브라우저에 최종적으로 보여지는 페이지를 헤더, 본문, 푸터 정도로 구분하여 관리가 됩니다. 저희가 이용중인 가비아 퍼스트몰을 예를 들자면 사이트의 메인 페이지는 /main/index 라는 주소로 접근이 가능합니다. 이 때 메인페이지의 실제 내용은 html_header.html 이라는 파일과 index.html 그리고 footer 구현을 위한 standard.html 세 개의 html 문서가 합쳐져서 표시가 됩니다. 이 작업은 솔루션에서 이루어지게 되며 이 부분은 솔루션 사용자가 일반적으로는 접근이 불가능한 부분입니다.

조금 더 가비아 퍼스트몰 예를 들자면 장바구니 페이지의 경우 /order/cart인데 html_header.html과 cart.html, standard.html 세 개의 조합입니다. 구매완료 페이지의 경우/order/complete 이며 html_header.html, complete.html, standard.html 세 개로 이루어져있습니다. 이와 같은 구조 이기 때문에 html_header.html의 내용만 수정해주면 사이트의 모든 페이지에 해당 내용이 적용되는 것과 같습니다.

이 때 html_header.html에는 <head></head> 의 head태그 내용과 <body> 태그의 시작으로 끝나도록 내용이 구성되어 있습니다. 이 부분은 사이트 모든 페이지의 <head> 태그 내의 내용이 되는 것이며, 이 부분에 GA 스니펫을 올려놓거나 GTM 스니펫을 올려놓는 것 만으로 기존 GA 설치와 GTM의 설치가 간편하게 끝날 수도 있는 것입니다.

하지만 그렇게 일이 쉽지 풀리지는 않습니다. GTM에서 전자상거래, 향상된 전자상거래를 이용하기 위해서는 GTM 스니펫이 실행되는 곳 이전에 data layer를 선언하여 관련 변수들을 집어넣어줘야만 합니다. 장바구니 페이지를 예를 들자면 data layer에 장바구니에 담긴 상품에 대한 가격, 수량, 상품명 등과 같은 정보를 집어넣은 후 GTM 스니펫이 실행되어야 합니다.

그런데 여기서 난관이 생깁니다. 한 가지는 data layer에 상품정보를 입력하기 위해서는 추가적인 정보가 필요하다는 것입니다. 보통의 쇼핑몰 솔루션의 경우 상품상세보기 페이지, 장바구니, 주문완료, 결제완료 페이지 등에서는 상품에 대한 정보들이 치환자로 서술되어 있습니다. { goods_name }, { orders.total_sale_price } 등과 같은 형태로 쇼핑몰 솔루션마다 제각각 다르며 이를 접근하고 다루기 위해서는 관련 정보를 솔루션 업체로부터 제공받아야 그 구조를 이해하고 활용할 수 있어야 합니다. 이러한 정보 없이 최종 html 코드를 분석해서 작업을 하는 것은 너무 어렵습니다. 게다가 장바구니, 구매완료 등의 페이지에서 이러한 정보는 배열로 구성이 되어 있기 때문에 data layer를 생성할 때 배열 관련한 처리도 정확히 다룰 수 있어야 합니다.

게다가 또 하나 문제가 있습니다. 앞서 설명 드린 바와 같이 전자상거래에 관련한 data layer는 GTM 스니펫 이전에 생성되어야 합니다. 그런데 앞서 예를 들 html_header.html에 GTM 스니펫을 올리게 된다면 그 코드 앞에 data layer를 생성을 구현해야 합니다. 이 때 html_header.html 은 공통으로 쓰이는 반면, 뒤에 이어지는 문서는 상품상세보기 페이지가 될 수도 있고 장바구니, 구매완료 페이지가 될 수도 있습니다. 공통으로 쓰이는 html_header.html의 data layer의 구조와 내용이 뒤에 이어지는 문서에 맞춰 바뀌어야 하는 상황인 것입니다.

제 경우 이 작업을 진행할 엄두가 나지를 않았습니다. 제가 IT 쪽 전문가는 아니기 때문에, 해당 작업이 이렇게 하면 될 수도 있겠다 싶지만, 머릿속으로 작업 내용을 대충 그려봐도 상당한 고생을 하겠구나 싶었습니다. 그렇다고 모든 페이지마다 GTM 스니펫을 전부 달자니 템플릿 구조의 장점을 하나도 활용 못하는 것인데다가, 그것 나름대로 상당한 고생이고 나중에 디자인 업데이트 할 때마다 코드를 수정할 일을 생각하니 그것 또한 머리가 아팠습니다.

그나마 다행인 건지, 아니면 여기서 불행이 시작되는 것인 지, 가비아 퍼스트몰의 경우 솔루션 상에서 GA와 GA의 전자상거래, data layer 부분이 구현은 되어 있었습니다. 조금 미흡한 부분이 있기는 하지만 지금까지 그것을 잘 이용해 오고 있었습니다. 그래서 생각한 것이 기존의 GA와 GA 전자상거래 관련 부분을 유지한 채, GTM을 새로 추가하여 쓰는 것입니다.

3. 쇼핑몰 솔루션의 예상치 못한 행동 - 솔루션 코드의 강제 치환

가비아 퍼스트몰 솔루션의 경우 GA 스니펫이 앞서 예를 든 html_header.html에 삽입되어 있는 것이 아니라, 최종적으로 페이지가 렌더링 될 때 솔루션에서 치환작업을 통해 페이지의 head태그 영역 최하단에 GA 스니펫이 삽입이 되는 방식입니다. 그래서 GA 스니펫이 삽입되는 위치를 감안하여 html_header.html에 GTM 스니펫을 삽입시켰습니다. 이런 식으로 하면 GTM 설치 자체는 매우 쉽습니다.

그렇게 한 후, 구글태그매니저 웹페이지로 이동하여 변수, 트리거, 태그를 생성하여 잘 작동하는지 테스트를 해봅니다. 이 때 트리거 조건을 기본적으로 제공되는 트리거인 All Pages를 이용하였습니다. 말 그대로 모든 페이지에서 태그가 트리거 되는 것입니다.

그렇게 한 후, 미리보기, 게시를 반복하는데 태그매니저에서 디버깅을 해보니 태그가 파이어링이 되지를 않습니다. 아니?? 도대체 왜??? 모든 페이지에서 트리거 되라고 설정을 했는데 왜 안되는 것인지 도대체 이해가 가지를 않아 엄청난 구글링과 함께 태그매니저 도움말과 개발문서를 살펴봅니다.

일단 결론을 파악해보니 모든 페이지에서 트리거가 된다는 것이 구현될 때 내부적으로 {{ Event }} equals ‘gtm.js’ 이라는 규칙이 실행되는 것이었습니다. 이것이 무슨 뜻인가 했더니 Event라는 변수의 값이 gtm.js 와 같을 때 트리거가 작동하여 태그가 파이어링, 실행되는 것이었습니다. 그런데 Event 라는 변수가 언제 gtm.js 값을 갖게 되는가?

new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],

j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=

'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);

})(window,document,'script','dataLayer','GTM-XXXXXX');</script>

GTM 스니펫 중 head태그에 들어가는 부분은 위의 형태입니다.

위에서 w[l].push({'gtm.start':new Date().getTime(),event:'gtm.js'}); 부분이 실행되면서 event라는 변수가 gtm.js 라는 값을 갖게 됩니다. GTM 스니펫이 최초 실행되면서 제일 처음 event에 담기는 값이 gtm.js 인 것입니다. 그러므로 GTM 스니펫이 제대로 설치가 되었다면 당연히 event에는 gtm.js 가 담겨 있을 것입니다.

다시 디버그를 해봅니다. 그런데 이게 웬일인가요. Event에 ‘gtm.js’가 아니라 이상한 경로와 함께 적혀있습니다. /data/skin/defaults/gtm.js 와 같은 값이었습니다. 뭔가 이상합니다. 저 경로는 갑자기 어디서 튀어나온 것인가요? 분명 소스코드에는 ‘gtm.js’인데 왜 최종적으로 저 값이 되었는지 감이 오지를 않습니다. 그런데 저 값이 왠지 눈에 익숙합니다. 저 값은 쇼핑몰 솔루션 스킨의 경로의 일부인 것이었습니다.

한참을 고민하다가 가비아 퍼스트몰쪽에 문의를 해보았습니다. 그쪽에서도 제법 찾아보더니 솔루션에서 페이지가 렌더링 될 때 소스에 ‘이름.js’로 처리가 될 경우 내부 파일로 인식하여 자동으로 경로를 붙여 주는 부분이 있다고 합니다. 그러니 제 경우 Event 값이 ‘gtm.js’가 아니라 ‘/data/skin/defaults/gtm.js’ 값을 갖게 되었고 이는 당연히 Event equals ‘gtm.js’ 를 true가 아닌 false로 만들어 트리거가 작동하지 않게 됩니다.

이를 해결하기 위해 트리거를 새로 만들어 {{ Event }} equals ‘gtm.js’ 가 아닌 {{ Event }} contains ‘gtm.js’로 설정해보았습니다. “같음” 대신 “포함”으로 조건을 바꾼 것입니다. 그런데 제가 잘못 봤을 수도 있지만 여전히 작동이 되지를 않습니다. 디버그를 해보니 분명히 Event contains ‘gtm.js’를 설정했는데 Event equals ‘gtm.js’ 도 트리거에 같이 있는 것이었습니다.

이를 또 열심히 검색해봅니다. 이유인 즉, 트리거를 생성할 때 [이벤트 유형]을 [페이지뷰]-[페이지뷰]로 할 경우 기본 규칙에 {{ Event }} equals ‘gtm.js’ 가 포함된다는 것이었습니다. 게다가 추가된 규칙끼리는 OR 연산이 아닌 AND 연산 적용이기 때문에 앞서 제가 Event contains ‘gtm.js’를 설정했어도 Event equals ‘gtm.js’를 만족시키지 못하기 때문에 트리거가 작동하지 않는 것이었습니다.

그래서 조금 더 고민해보았습니다. 페이지가 렌더링 됨에 따라 GTM의 이벤트 발생은 3가지 단계를 갖습니다. 1) gtm.js 2) DOM Ready 3) Window Loaded 입니다. gtm.js 단계는 GTM 스니펫이 불러와진 직후이며 그 이후 DOM Ready 단계, 최종적으로 Window Loaded 단계입니다. 최종 Window Loaded 단계는 페이지 내의 모든 이미지까지 다 불러와진 상태를 의미합니다. DOM Ready는 그 중간단계로 문서의 구조정보가 브라우저에 올라간 단계라고 합니다.

GTM에서는 페이지뷰라는 이벤트의 단계를 이와 같이 3단계로 나눠서 다룰 수 있게 해놨습니다. 사용자 중 페이지를 들어오자마자 즉시 이탈하는 경우가 있기 마련인데 이러한 경우도 그나마 태그를 파이어링 하기 위해서는 1단계 gtm.js 에서 트리거가 되어야 할 것입니다. DOM Ready나 Window Loaded에서 트리거를 설정했다면 이 경우 태그가 파이어링 되기 전에 사용자가 이탈해버리는 상황에 대응할 수가 없습니다.

제 경우는 일단 쇼핑몰의 솔루션의 문제로 인해 gtm.js 단계를 사용할 수가 없으므로 페이지뷰 트리거를 DOM Ready로 설정해보기로 하였습니다. 그랬더니 이제서야 태그가 정상적으로 파이어링이 됩니다. 이때 트리거의 규칙은 Event equals gtm.dom 인데 이와 관련해서 문제를 일으키는 부분은 없었습니다. Window Loaded의 경우도 문제 없이 됩니다. 길고 긴 삽질의 과정이었지만, 결국 솔루션에서 소스의 내용을 강제로 치환해버려서 발생한 문제였습니다. 조만간 해결 될 수 있겠죠. 그러면 gtm.js 단계에서 태그를 파이어링 하는 것도 가능해질 것 같습니다.

4. 쇼핑몰 솔루션의 예상치 못한 행동 - iframe

이렇게 기본 테스트가 되고 나서 네이버쇼핑에 한하여 UTM작업을 하는 태그를 만들어 테스트를 해보았습니다. 기분 좋게 반나절 정도 대기하고 GA를 살펴보는데, 데이터가 많이 이상합니다. 뭔가 많이 이상해서 다시 디버그를 돌려봅니다. 태그매니저에서는 딱히 이상이 보이지 않아 이번에는 크롬 확장프로그램인 Google Analytics Debugger를 이용해봅니다. 그랬더니 일부 페이지에서 GTM 태그가 한 개가 아닌 다수가 나타나는 것이었습니다. 왜 그런가 살펴보니 바로 iframe 태그가 원인이었습니다.

역시 쇼핑몰 솔루션이 문제가 된 것입니다. 쇼핑몰 솔루션의 경우 특정 페이지에서 내용을 iframe으로 불러오는 경우가 있습니다. 그런데 이때 iframe으로 불러오는 페이지의 head 부분에도 GTM이 적용되어 있기 때문에 최종적으로 GTM 스니펫이 여러 개가 설정되어 태그가 수 차례 파이어링 하게 되는 것입니다. 가비아 퍼스트몰의 경우 상품페이지에서 그런 문제가 생깁니다. 상품페이지의 상품리뷰, 상품문의 부분을 iframe으로 불러옵니다. 그래서 iframe의 페이지에서는 태그가 트리거 되지 않게 예외 트리거를 적용하고자 열심히 검색을 해봅니다.

https://www.simoahava.com/gtm-tips/prevent-tag-from-firing-in-iframe/

SIMO AHAVA의 블로그입니다. GTM 관련해서 검색하면 자주 나오는 블로그인데, 이번 작업을 하면서 매우 큰 도움이 되었습니다. 위의 링크를 보면 iframe을 어떻게 예외 처리하는지가 나와있습니다.

맞춤 자바스크립트 변수를 하나 생성한 후 아래의 내용을 담습니다. 위의 블로그에서는 변수명을 Page Is iframe 으로 하였습니다.

function() {

try {

return window.top !== window.self;

} catch(e) {

return false;

}

이 변수는 iframe이면 true를 갖게됩니다. 그리고 트리거를 하나 생성하여 이 변수를 사용해 Page Is iframe equals true 규칙으로 저장합니다. 그리고 이 트리거를 기존 태그의 예외 트리거에 추가하게 되면 이제 iframe 페이지에서는 태그가 트리거되지 않습니다. 이렇게 또 하나의 문제를 해결하였습니다.

5. GA와 GTM을 동시 쓰는 것에 대하여

지금까지는 GTM을 쇼핑몰 솔루션에 설치 시 겪을 수도 있는 문제에 관한 내용이었습니다. 이제 GA와 GTM을 동시에 쓰는 것에 대하여 살펴보고자 합니다. 작업을 하면서 이 부분을 많이 고민했습니다.

GA스니펫이 작동할 때 다음과 같은 코드가 실행됩니다.

ga(‘create’, ‘UA-12345-1’);

이것은 GA와 관련하여 tracking ID UA-12345-1의 트래커를 생성하는 명령입니다. 보통 사용할 때는 트래커의 이름을 지정하지 않고 기본으로 사용합니다.

그런데 GTM스니펫이 작동할 때를 Google Analytics Debugger로 확인해보면 다음과 같은 실행이 있습니다.

ga(‘create’, ‘UA-12345-1’, {name: ‘gtm1454402957304’ cookieDomain: ‘auto’}

즉 GTM 또한 GTM에서 지정한 tracking ID에 대해 트래커를 생성하게 됩니다. 게다가 GTM에서 생성한 트래커는 고유의 이름이 붙게 됩니다. GTM의 트래커 생성은 GA 스니펫과 이 부분에서 큰 차이가 있습니다. GTM의 경우 태그가 파이어링 할 때마다 고유 이름을 갖는 트래커를 생성합니다.

GTM 스니펫이 실행될 때 아래의 코드가 실행됩니다.

w[l].push({'gtm.start':new Date().getTime(),event:'gtm.js'});

여기서 new Date().getTime() 이란 현재의 날짜, 시간을 가져오는 것인데 이것을 바탕으로 트래커 이름을 생성하게 됩니다. 이런 구조이기 때문에 태그가 파이어링 할 때마다 고유 이름을 갖는 트래커가 생성됩니다.

기존 GA 스니펫 방식에서는 기본적으로는 트래커를 하나만 생성하여 ga(‘send’, ‘pageview’); 와 ga(‘send’, ‘event’); 등의 명령을 실행하게 되는데, GTM의 경우 각각의 페이지뷰 태그, 이벤트 태그가 파이어링 될 때마다 독립된 트래커가 생성됩니다.

결국 GA와 GTM을 동시에 사용하고 같은 tracking ID, 즉 같은 속성을 이용할 경우 최소 두 개 이상의 트래커가 생성되게 된다는 것입니다. 그리고 GA와 GTM을 동시에 사용하는 것과 별개로 GTM 태그를 여러 개 사용할 경우에도 동일 tracking ID 에 대해 다수의 트래커가 생성될 수 있다는 것입니다. 그리고 트래커가 여러 개 이면 각각의 트래커와 관련된 data layer도 전부 다르게 됩니다.

그래서 저는 동일한 tracking ID에 대해 트래커가 다수여도 동일한 세션이 유지되는지가 염려되었으나 검색과 SIMO AHAVA 블로그의 내용을 보고 동일 tracking ID에 대해 트래커가 다수여도 동일한 세션을 유지한다는 것을 알게 되었습니다. (참고: https://www.simoahava.com/analytics/ga-snippet-and-ga-gtm-tag-on-the-same-page/)

즉 기존 GA스니펫과 GTM을 같이 쓰는데는 문제가 없다는 것입니다. 다만 각각의 트래커의 data layer가 다르기 때문에 한쪽에서 다른 한쪽의 data layer의 정보를 수정하거나 가져올 방법은 마땅하지 않아 보이는데, 제 경우 그런 일을 딱히 시도할 일은 없을 것 같아, 이런 부분은 나중에 고려하기로 합니다. 위의 참고내용은 GA와 GTM을 같이 사용하는 것에 대해 자세한 내용을 담고 있습니다. 관심이 있으신 분은 꼭 살펴보시기를 바랍니다.

위의 블로그에는 GTM와 GA 트래커 이름을 같게 했을 경우에 대한 문제점에 대해서도 잘 다뤄져있습니다. 만약 GTM쪽에서 트래커 이름을 변경하여 경우, GA쪽과 같게 만들 경우 한쪽 data layer가 다른 한쪽을 덮어씌워버리는 문제가 발생하게 됩니다. 이런 작업은 data layer의 정보에 상당한 오류를 가져와 결과적으로 보고서 통계가 뒤엉키게 될 수 있습니다. GA와 GTM을 같이 쓰기 위해 트래커 이름을 같게 할 필요가 없으며, 해서도 안됩니다. (참고: https://www.simoahava.com/gtm-tips/be-careful-with-the-tracker-name-setting/)

6. 작업에 도움이 되는 도구들

태그매니저의 미리보기 기능을 적극적으로 활용하면 좋습니다. 크롬에서 태그매니저 페이지 tagmanager.google.com 를 접속한 상태에서 미리보기를 실행한 후, 새 탭에서 GTM이 설치된 사이트를 열면 태그가 잘 작동하는지를 살펴볼 수 있습니다. 또한 gtm.js 단계, DOM Ready, Window Load 단계 별로 태그들이 어떻게 작동하고 변수들이 어떤 값을 갖는지 확인할 수 있습니다.

여기에 추가로 크롬에서 Google Analytics Debugger 확장프로그램을 설치하시면 좋습니다. Google Analytics Debugger를 설치 후 ON 모드로 해놓고, 사이트에서 [마우스 우클릭]-[검사] 또는 Ctrl + Shift + I 해서 나오는 [개발자 도구] 화면에서 [Console] 탭을 들어가면 됩니다. 그러면 GA 관련한 실행과 변수 상세 내용을 확인할 수 있어 작업에 오류가 있을 때 확인하기가 좋습니다.

7. 추가 고찰

1) gtm.js, DOM Ready, Window Load와 트리거

GTM에서 트리거는 gtm.js, DOM Ready, Window Load 세 가지 단계에 걸쳐 설정이 가능합니다. 제 경우 쇼핑몰 솔루션의 문제로 당장은 gtm.js 단계에 트리거 설정이 불가능한 상태입니다. 몇 일간 GTM을 테스트 하면서 살펴보니 DOM Ready 단계에서 트리거를 설정할 경우, 페이지에 유입되자마자 거의 즉시 이탈하는 고객에 대해서는 트리거 작동율이 떨어집니다. 즉시 이탈 고객에게도 태그를 작동시키려면 gtm.js 단계에서 트리거를 설정해야 할 것 같습니다.

즉, 제 경우 네이버쇼핑에서 들어오는 유입에 utm태그 정보를 수정해 naver/organic으로 표시되는 트래픽을 좀 분류하려고 했으나, DOM Ready 단계에서 트리거 되다보니, 즉시 이탈 하는 고객들 대상으로는 태그가 작동하지 않아 여전히 많은 유입이 naver/organic으로 나타납니다. gtm.js 단계에서는 괜찮지 않을까 생각해보고 있습니다. 쇼핑몰 솔루션의 문제가 해결되어 gtm.js 단계에서 트리거 설정이 가능해지면, 기존에 UTM 태깅을 수동으로 하던 매체들을 점차 옮겨볼 생각입니다. 다만, 즉시이탈되는 유입 같은 경우에 GTM 태그가 작동되는지를 잘 살펴보고 작업을 진행할 생각입니다.

2) 페이지뷰 추적과 이벤트 추적에 관하여

GTM에서 태그를 구성할 때 유니버설 애널리틱스 유형을 선택하면 구글 애널리틱스와 관련된 태그를 만들어 목적에 맞게 사용할 수 있습니다. 이 때 추적유형이 페이지뷰, 이벤트, 거래, 소셜 채널, 시간, 링크 맞춤 설정, 양식 맞춤 설정 등이 있습니다. 이에 대한 상세한 내용은 다음에서 참고가 가능합니다.

https://support.google.com/tagmanager/answer/6107124?hl=ko&ref_topic=6333310

여기서 페이지뷰 추적과 이벤트 추적은 조금 생각해볼 부분이 있습니다. 추적유형 중 페이지뷰를 선택하면 GA 스니펫을 이용 했을 때 ga('send', 'pageview', [page], [fieldsObject]); 를 실행하는 것과 같은 명령을 취합니다. 이벤트 추적의 경우 ga('send', 'event', [eventCategory], [eventAction], [eventLabel], [eventValue], [fieldsObject]); 를 실행하게 됩니다.

이것은 만약 동일한 사이트에서 페이지뷰 추적을 하는 태그를 여러 가지 사용할 경우, 트리거 설정에 따라 동시에 파이어링 하게 되면 페이지뷰가 중복된다는 것입니다. GA 보고서에서 페이지뷰 수치가 실제보다 크게 잡히게 될 수 있습니다.

그러므로 기존 GA 스니펫을 사용했을 때와 마찬가지로 사이트 내 모든 페이지에서 페이지뷰 추적 태그는 단 한번만 파이어링 될 수 있도록 신경을 써야 한다고 생각합니다.

페이지뷰 추적 태그 이외에는 이벤트 추적 태그의 활용이 가능하며, 이벤트의 경우 상호작용 설정에 따라 이탈율에 영향을 주게 되니 태그 설계 시 이 부분을 고려하셔야 합니다. 이벤트 추적을 설정할 때 [이벤트 추적 매개변수]에 [비 상호작용 조회] 부분의 설정이 가능합니다. 초기값은 거짓으로 되어 있습니다.

만약 단순히 데이터를 업데이트하기 위한 이벤트 추적 태그를 설계하신다면 이탈율에 영향을 줘서는 안되므로 [비 상호작용 조회] 부분을 참, True로 설정하시는 것이 좋습니다. 이 부분이 GA 스니펫을 사용했을 때 event의 non-interaction 설정하는 부분입니다.

다음은 구글 애널리틱스 개발문서의 Event Tracking 부분의 하단 부분 Non-interaction events의 내용입니다. 해당 부분 설정을 GTM에서는 추적 태그 설정에서 [비 상호작용 조회] 부분의 참, 거짓으로 가능한 것입니다.

https://developers.google.com/analytics/devguides/collection/analyticsjs/events

8. 참고자료

구글 태그매니저 도움말 자료

https://support.google.com/tagmanager/?hl=ko#topic=

구글 태그매니저 개발문서

Developer Guide와 Enhanced Ecommerce를 보시면 Data layer를 어떻게 구성하면 되는지 상세히 나와있습니다.

https://developers.google.com/tag-manager/quickstart

구글 애널리틱스 개발문서

https://developers.google.com/analytics/

https://developers.google.com/analytics/devguides/collection/analyticsjs/

SIMO AHAVA의 블로그 자료