매출을 높이는 데이터 측정 전략의 3가지 특징
구글 애널리틱스 4로 이전하기 4 - Measurement Plan
앞선 audit을 통해 기존 데이터 수집과 활용에 대해 리뷰를 마쳤다면, 다음으로는 audit 결과를 바탕으로 데이터 측정 전략을 수립해야 한다. Measurement plan, Measurement requirements, KPI measurements documentation 등 각 회사나 팀들이 각기 다른 이름으로 부르는 이 과정이 끝나면 GA4로의 이전에 대한 대략적인 문서화 작업이 끝난다고 보면 된다. 나머지 과정은 tag implementation, QA 등의 실행과정에 해당된다.
혹시 앞선 글이 궁금하시다면 - https://brunch.co.kr/@jaehoshindler/41
이 단계는 개인적으로는 가장 설레는 작업이기도 하고, 가장 어려운 작업이기도 하다. Ecommerce 제품처럼 KPI가 뚜렷하고 (또는 최소한의 conversion에 대한 정의), 조직의 maturity가 높다면 오히려 쉽다. 문제는 조직의 디지털 제품에 대한 business objective 설정과 이해가 부재할 때이다. B2B나 유관 부서가 너무 많은 경우 흔히 나타나는데 이 경우 KPI structure부터 건드려야 하는 경우가 있어서 커뮤니케이션 노력이 2-3배가 증가하기도 한다. 한편으로는 하얀 도화지에 탄탄한 밑그림을 그려주는 느낌이 들어, 일에 대한 보람을 느끼는 단계이기도 하다.
데이터 측정 전략이 매출과 무슨 관계야 하겠지만, 그 매출과 관련된 일련의 사용자 행동 데이터를 수집하고 분석하고 연결하는 일을 설계하는 작업이 데이터 측정 전략이다. 문제점을 발견하는 것만으로는 매출을 높일 수 없다. 매출을 데이터로 높이고 싶다면, 진단된 데이터의 수집, 연결, 활용에 대한 문제점들에 대해 실행 가능한 솔루션을 내야 한다. 실행가능한 솔루션들을 효율적으로 문서화하는 것이 좋은 데이터 측정 전략이라 할 수 있다.
흔히 데이터를 수집하고 분석하는 과정을 집을 설계하고 건축해서 주거하는 것으로 비유한다. 그래서 Digital analyst들 중에 우리 회사처럼 analytics architect로 job title을 짓기도 한다. 지난 audit을 통해 기존에 지어진 집의 구조와 문제점들을 진단했다면, 측정 전략을 통해 매출을 높이기 위해서 아래와 같은 목표를 달성할 수 있어야 한다.
1. 목적에 맞는 집
목적이 없는 건축물은 없다. 주거용이든 상업용이든 공공기관이든 건축설계사는 분명한 목적을 가지고 설계를 하게 되어 있다. 제품도 마찬가지이다. 웹사이트든 모바일앱이든 사용자에게 가장 기대하는 행동이 있기 마련이다. 그렇지 않은 제품이라면 사용자는 길을 잃고 만다. 아무리 아름다운 디자인을 갖고 있다고 해도, 만드는 사람이 분명치 못한 의도를 갖고 있다면 말이다.
뚜렷한 KPI를 갖고 있다면 좋다. 그렇다고 해서 모든 KPI가 유효하진 않다. bounce rate, users와 같은 기본적인 metric을 두고 KPI라고 한다면 집의 용도에 대한 리뷰가 필요하다는 의미이다. 따라서 digital analytics에 있어 KPI는 측정 가능해야 하며 (measurable), 실제적이어야 하며 (tangible), 통장에 보이는 것과 가까울수록 (bankable) 좋다. 그리고 데이터 측정 전략은 이런 KPI를 효율적이며, 정확하고, 분석 가능한 형태로 다뤄야 한다.
현재 지어진 집의 용도와 집의 상태가 일치하는지 audit을 통해 확인했다면, 유지/보완/전면 재건축 중에 방향을 결정해야 한다. 보완/재건축의 방향이라면 '어떻게'가 중요하다. 가장 중요한 interaction을 어떤 event와 parameter로 언제 어디에서 수집할 것인가? 앞서서 이야기했듯, dataLayer 만능주의를 버리기 바란다.
2. 안전한 집
유럽/영국은 물론, 전 세계적으로 privacy 이슈가 디지털과 데이터 분야에 큰 변화를 가져온 지 5년이 넘었다. 건축에 있어 안전진단과 관련 법을 준수하는 것이 중요해졌듯이, 데이터 측정 전략에도 안전과 관련한 이해와 인식이 너무 중요해졌다.
Privacy는 매출보다 단기보다 중장기적인 비용과 관련이 높으므로 ROI에 기여가 높다. 한번 수립된 측정 전략은 쉽게 수정할 수 없다. 일시적인 필요를 위해 많은 비용을 들여서 전략을 수립했는데, privacy 이슈로 다시 수정해야 할 때의 비용 또는 privacy 관련 제재로 인해 벌금이 부과되는 것은 더 이상 유럽에서 남의 일이 아니다.
특히 tag management에 있어서는 이러한 privacy requirement를 파악하고 효율적으로 GTM account structure를 만드는 것이 중요하다. 10개 남짓한 tag들만 있다면 문제가 되지 않겠지만, sophisticated한 client일수록 GTM container가 무겁고 작은 변화를 주기에도 쉽지 않기 때문이다.
dataLayer spec을 작성할 때에도 안전한 데이터를 수집하는 것을 늘 염두에 두어야 한다. dataLayer는 특성상 서버 DB 등 프론트에서 접근할 수 없는 데이터를 염두에 두는 경우가 많기 때문에, PII를 무의식 중에 포함하지 않도록 해야 한다.
3. 확장 가능한 집
한국은 대부분 아파트라 확장 가능한 집이라는 개념이 생소하겠지만, 영국이나 해외에서는 대부분 집들이 정원을 포함하고 있고 단독주택이라 법의 테두리 안에서 위로 옆으로 확장이 가능하다.
같은 개념으로, 사용자의 privacy가 중요해진 context 속에서 수집된 데이터를 어떻게 확장할 것인가는 중요한 과제이다. 예전처럼 user ID나 3rd party cookie를 통해서 데이터를 결합하는 일이 불가능해졌기 때문이다. 이런 privacy라는 독특하고 새로운 환경 속에서 어떤 방법으로 1st party data를 확장할 것인지, 이를 3rd party data로 어떻게 activate 할지, 데이터 분석가들은 새로운 과제에 직면하고 있다. 특히 Chat-GPT는 script 단위의 문제해결에 대해서는 개인보다 우위를 점할 것이기에, 데이터 분석가라면 보다 통합적인, 진짜 architectural한 문제들을 푸는 것에 역량을 가져야 한다.
결국 이는 digital maturity 라는 큰 context 안에서 지속적으로 진단하고 개선해 나가야 함을 의미한다. 마케팅에 있어 가장 마지막 단계라 할 수 있는 full personalisation - automation은 한 번에 이뤄질 수 없다. 큰 목표 안에서 단계별 세부 목표들을 계속 segment 하고 실행할 근거가 measurement plan이 되어야 한다.
따라서 Measurement plan에 아래의 기본적인 문서 작업을 포함하는 하는 것을 추천한다.
1. GA/GTM Account structure and configuration
2. Measurement requirements
Measurement title - 무엇을 측정하고자 하는지 (i.e. Pageview)
Section/Element - 어떤 UI Section/Element와 관련이 있는지 (i.e. All Pages, Global navigation)
For what - 측정하고자 하는 이유 또는 수집된 데이터의 가치
How to measure - i.e. dev support, click element
Tagging details - Tag, trigger, parameters 의 세부 내용
3. Custom Dimensions/Metrics/Conversion event
4. Core user journey data collection
중요한 사용자 journey가 있다면 해당 데이터가 어떻게 수집되는지 예시화 하는 것도 좋다
5. References
개인적으로는 개발팀의 도움이 필요한 dataLayer spec 등의 경우 Technical implementation documentation으로 따로 쓰는 편을 선호한다. Technical implementation documentation은 기본적으로 개발자들을 위한 developer documentation에 해당한다. 따라서 지나친 화면 캡처와 예시보다 원칙을 설명하는 것을 추천한다. Measurement plan에서 개발팀의 도움이 필요한 부분을 하이퍼링크로 Technical implementation documentation 페이지 내 링크를 걸면 Measurement plan이 불필요하게 무거워지는 일을 막고 큰 틀에서 Technical implementation documentation을 이해하는데 상호 레퍼런싱을 할 수 있다.
