커뮤니티2

구글 애널리틱스 – 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를 마스터하고 보다 다양하고 정확한 데이터들을 수집할 수 있는 마케터가 되면 좋겠다.