이벤트 로그 설계부터 태깅작업까지(feat.GTM 이벤트 매개변수에 동일한 이름의 매개변수를 생성하면?)

목차
1. 로그 설계와 태깅 작업, 제가 해보겠습니다!
2. 사용자 행동을 확인하고 싶은 이유는?
3. GTM으로 태깅 작업하기
4. 버튼 이름이 수집되지 않는다
5. 마무리

1. 로그 설계와 태깅 작업, 제가 해보겠습니다!

최근 회사에서 '문의 접수'를 목적으로 제작된 페이지를 새롭게 오픈했다. 

관련해 페이지 내에서 사용자들이 어떤 행동을 거쳐 문의 접수를 하는지 확인하고 싶다는 요청이 들어왔다. 일반적으로 데이터 분석가가 이벤트 로그 설계서를 작성하고 문서를 개발팀에 전달하면 태깅 작업을 진행해주신다. 우리 회사에서도 큰 프로젝트들은 이런 프로세스로 진행하지만, 이번에는 규모가 작은 프로젝트이기도하고 GTM을 활용할 예정이라 태깅 작업이 어려울 것 같지 않아서 태깅 작업도 내가 진행하고 싶다고 말씀드려서 직접 담당하게 됐다.

딱 요런 느낌으로 해보겠다고 선언한 과거의 나

엄청 간단한 페이지라 크게 어려움이 없을 것 같았지만, 막상 진행하다보니 예상하지 못한 부분에서 이슈가 생겼다(ㅎㅎ). 이 글을 통해 이벤트 로그 설계서 작성과 태깅 작업에 대한 프로세스를 정리하고 그 과정에서 배운 점을 정리해보고자 한다.

---

2. 사용자 행동을 확인하고 싶은 이유는?

이번 페이지는 다른 페이지보다 UX요소들이 간단한 편이고 기간도 넉넉해 모든 데이터를 다 확인할 수 있게끔 태깅 작업을 진행해야겠다라는 희한한 생각을 갖고 일을 시작했다. 그러고 나니 몇가지 문제가 걸리면서 일이 진척되지 않았다.

1. 네이밍 규칙은 어떻게 하지?
   • 이벤트 이름은 모두 다 영어로 할지부터 시작해 대소문자 구분 여부, snake case를 사용할지 camel case를 사용할지 등 사소하지만 중요한 규칙들을 어떻게 정해야할지 고민이 됐다.
2. 이벤트 카테고리는 어떻게 정하지?
   • 가장 많이 고민이 됐던 부분이다. 클릭, 스크롤과 같은 실제 행동에 따라 구분을 지어야할지, 문의 접수 완료 단계까지 가는 행동들을 문의접수라는 대 카테고리를 범주화해야할지 등

제대로 로그 설계를 하지 않고 시작했다가는 소중한 데이터들이 마구 혼재되거나 과하게 적재될 것만 같아서 다시금 분석 방향성에 대해 생각해봤다. 본격적으로 이벤트 로그를 설계하기 전에 페이지의 목적, 데이터를 확인하는 목적을 다시금 정리해보고 업무를 시작했다. 특히 데이터는 사람들의 발자취이기 때문에 데이터를 확인하고 이용하는 '목적'이 가장 중요한 듯하다.(물론 데이터 업무에 만 적용되는 조건은 아니지만!) 

- 페이지 목적 : 문의 접수(전환)

- 데이터 분석 목적 : 페이지에 접속한 사용자들의 문의접수율(전환율) 높이기위한 인사이트 제공

- 어떤 행동을 확인해야할까?
ㄴ 문의접수하기까지 어떤 섹션에 가장 집중했는지
ㄴ 어떤 영역을 통해 전환 단계에 진입했는지
ㄴ 진입해서 어떤 행동을 가장 먼저하는지

 대강 요런 목적성을 염두하고 설계서를 작성했다. 그리고 구글링을 통해 이미 템플릿으로 많이 만들어진 다양한 이벤트 로그 설계서를 확인했다. 또한, 마침 수강 중인 카일스쿨님의 'PM을 위한 데이터 리터러시' 강의에서 이벤트 로그 설계 부분을 다루고 있어 이 부분을 수강하고 강의에서 제공되는 템플릿을 내가 진행하고 있는 방향성에 맞게 커스텀했다.

내가 GA4와 빅쿼리를 통해서 데이터를 수집&분석하고 GTM으로 태깅 작업을 진행할 예정이었기 때문에 관련된 정보와 안내 링크는 최대한 한 곳에서 확인할 수 있게끔 구성했다. 최종적으로 GTM을 활용해 비개발직군에서도 쉽게 태깅할 수 있도록 문화를 만들어보고 싶다는 목표가 있어서 모두가 이해할 수 있는 수준의 설계서를 만들고자 했다.

이벤트 로그 설계서 중 일부

---

3. GTM으로 태깅 작업하기

GTM 스크립트 삽입을 개발팀에 요청하고 설계서에 정의한 것과 같이 GTM에 태그/이벤트/변수를 셋팅했다. 매번 디버깅만하다가 직접 셋팅해보니 그것도 새로운 경험이었다. 그러다가 또 문제가 발생했으니!!! 웹에 대한 이해도가 낮은 상태에서 태깅 작업을 진행하려고 하니 트리거 조건을 잡는 과정에서 문제가 많았다.

1.버튼 내 삽입되어 있는 이미지 효과 때문에 글자가 하나씩 분리되어 있던 것.

태깅 작업 중 가장 큰 문제는 버튼 내 삽입된 이미지 효과 때문에 버튼 텍스트가 한글자씩 따로 퍼블리싱되어 있었다. 즉, 버튼의 텍스트가 <span> 태그로 나뉘어 각 글자가 따로 DOM 요소로 존재했던 것. 그래서 클릭 이벤트를 특정 트리거에 연결하려고 하면, 실제 클릭한 글자만 잡히고 버튼 전체를 인식하지 못했다.

대략 이런 느낌으로 움직이는 애니메이션 효과였다

 

그래서 결국 맞춤 자바스크립트 변수를 새로 생성해 분리된 글자를 하나의 텍스트로 반환할 수 있게끔 설정했다. 물론 자바에 대한 지식이 없으니 이 부분은 GPT의 도움을 받아 해결...

2. '문의 접수' 조건 설정은 무엇으로?

문의 접수 이벤트를 태깅하기 위해 접수 완료 시 잠시 변경되는 URL을 트리거 조건으로 설정했다. 하지만 문제는 그 URL이 너무 짧은 시간 동안만 표시되고 사라져서, GTM에서 이를 인식하지 못했다는 것! 결국 디버깅에서도 감지되지 않아 개발팀의 도움을 받을 수밖에 없었다.

개발팀이 데이터 레이어에 접수 완료 데이터를 푸시(push)하도록 해준 덕분에, URL 변경 없이도 정확히 트리거를 설정할 수 있었다. 데이터 레이어를 활용하니, 이제는 안정적으로 태깅 작업이 가능해졌다.

---

4. 버튼 이름이 수집되지 않는다!

이제 태깅 작업도 끝났고, 데이터가 잘 들어오겠지! 하고 디버깅을 돌려봤는데... 또 문제가 발생했다. 첩첩산중도 이런 첩첩산중이 없었다! 이번엔 버튼 이름이 제대로 수집되지 않는 문제였다. 처음엔 위에서 만들어둔 맞춤 자바스크립트 변수(Click Data Title JS)와 기존에 있던 Click Text 변수를 하나의 이벤트 매개변수에 함께 넣어서 해결하려 했는데, 이게 잘못된 생각이었다.

문제 원인

하나의 변수에는 하나의 값만 넣어야 한다는 기본 원칙을 간과했던 것. 두 변수를 같은 매개변수에 넣으니, 첫 번째로 지정했던 Click Text 값이 제대로 들어오지 않았던 것이다.

하나의 변수 = 하나의 값이라는 기본 원칙을 기억하자! 이번 일을 통해 매개변수 설정의 중요성과 변수 관리의 기본기를 다시 배웠다. 앞으로는 변수와 값을 더 명확히 구분해 태깅 작업을 진행해야겠다. GTM 디버깅 과정에서 문제가 생기면, 원인부터 차근차근 살펴보는 게 필수다!

---

5. 마무리

처음으로 이벤트 로그 설계부터 태깅 작업까지 혼자 진행하면서 예상치 못한 문제들과 해결 과정을 겪었다. 특히 GTM과 데이터 레이어를 활용하며 기본적인 원칙과 협업의 중요성을 배울 수 있었다. 이번 경험을 통해 데이터 설계와 태깅의 전 과정을 스스로 점검하고 성장할 수 있는 기회가 됐으니 다음번 작업은 좀 더 매끄럽고 원활하게 해보자

👉🏻참고 링트

- https://www.inflearn.com/course/pm-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EB%A6%AC%ED%84%B0%EB%9F%AC%EC%8B%9C/dashboard

PM을 위한 데이터 리터러시(프로덕트 데이터 분석) 강의 | 카일스쿨 - 인프런

- https://osoma.kr/blog/how-to-write-event-definition/

이벤트 정의서와 작성 방법