출시 전에 계측을 볼 자리를 넉 달 만에 규칙으로 만들었습니다

7월 사고 뒤에 남긴 할 일은 두 가지였습니다. dataLayer 이관은 9월에 끝났어요. 고민은 남은 하나였습니다. “URL이나 가입 흐름이 바뀌면 마케팅에 미리 알린다”는 합의를 어떻게 받아 낼지였는데, 10월 22일에 다시 봤을 때도 합의한 기록이 없었어요.

출시 뒤에 메우는 일이 쌓였습니다

결제 매출 0, 가입 완료 이벤트 중복, 일부 버튼의 클릭 미수집, 보안 설정 변경 뒤 리퍼러 손실이 모두 그런 일이었어요. 11월 6일에는 모바일 개편 소식을 개발 테스트 엿새 전에 우연히 알았습니다. 결제 화면까지 바뀌는 개편인데 정의서 요구사항 596건 중 계측 요구는 0건이었어요.

빠져 있던 건 절차였습니다

문제는 누가 놓쳤느냐보다 계측을 볼 자리가 절차에 없다는 데 있었습니다. 그래서 출시 절차를 정하는 쪽에 1:1로 “결제·가입·주소 같은 핵심 구조가 바뀌면 출시 전에 그로스팀이 계측을 볼 자리”를 요청했어요.

11월 9일에 규칙으로 답이 왔습니다. 기획자가 계측까지 기획하고, 마케팅 계측은 기획 단계에서 제 피드백을 받아요. 저는 테스트만 맡습니다.

기획 정의서에는 이런 칸이 들어갑니다. 이벤트와 파라미터는 예시예요.

## 계측 요구 (기획 단계에서 채움)

| 사용자 행동 | 이벤트 | 파라미터 | 보내는 시점 | 확인 방법 |
|---|---|---|---|---|
| 결제 완료 | purchase | transaction_id, value, currency | 결제 승인 응답 직후 | GTM 미리보기 |
| 가입 완료 | sign_up | method | 계정 생성 성공 직후, 1회만 | GA4 DebugView |

“1회만”을 보내는 시점 칸에 적어 두면 완료 페이지 재방문으로 이벤트가 다시 찍히는 사고를 기획 단계에서 막을 수 있습니다.

효과는 바로 나왔습니다

모바일 계측 요청서는 11월 10일 하루 만에 v7에서 v11까지 왕복을 끝냈어요. 새 유료 상품 하나는 개발팀이 dataLayer를 미리 심어 둬서 GTM 연결만으로 끝났습니다.

GTM 원칙도 같은 쪽으로 굳혔습니다

개발팀이 모르는 맞춤 HTML 리스너는 본체에 심지 않아요. 기본 기능으로 안 되면 dataLayer를 요청합니다.

하지 않기로 한 방식은 이런 코드입니다.

<!-- 하지 않기로 한 방식: 개발팀이 모르는 리스너를 GTM 맞춤 HTML로 심기 -->
<script>
  document.addEventListener("click", function (e) {
    if (e.target.closest(".pay-button")) dataLayer.push({ event: "pay_click" });
  });
</script>
<!-- 클래스명이 바뀌면 조용히 깨집니다. 기본 트리거로 안 되면 dataLayer push를 요청합니다. -->

화면 쪽 코드는 개발팀이 바꾸는데, 이 리스너가 있다는 사실은 GTM 안에만 있습니다. 7월에 thanks page 주소가 바뀌었을 때와 같은 구조의 위험이에요.