GA4 구매 이벤트 설계 사례: 서비스 신청과 실제 결제 구분

기존 태그 상당수는 페이지 주소나 화면 전환을 조건으로 실행됐습니다. 이런 방식은 페이지를 열었다는 사실은 알려주지만, 서비스 신청이나 결제가 실제로 성공했는지까지 항상 보장하지는 않습니다. 확인하려는 업무의 완료 조건과 코드가 실행되는 조건을 나란히 놓고 비교해야 하는 이유입니다.

행동이 기록될 때 함께 보내는 정보도 확인했습니다. 예를 들어 구매가 발생했다는 사실만 있고 어떤 상품인지 구분할 값이 없다면 상품별 분석은 어렵습니다. 이처럼 이벤트를 설명하는 부가 정보를 매개변수라고 합니다.

진단에서는 이전 분석 환경의 기준을 그대로 사용하고 있는지도 살폈습니다. 기존 이벤트 이름을 유지하는 것보다 현재 서비스에서 구분해야 할 행동과 정보를 제대로 담고 있는지가 중요했습니다.

미팅 내용과 웹페이지 코드를 검토한 뒤 구매 이벤트는 실제 결제 시점에 맞추는 방향을 제안했습니다. 그전에 일어나는 신청과 설정은 별도 행동으로 남기도록 했습니다. 이렇게 구분해야 신청한 사람 중 어느 단계에서 다음 행동으로 이어지지 않는지 살펴볼 수 있습니다.

이처럼 고객이 신청에서 구매까지 이동하는 단계를 나눠 보는 것이 퍼널 분석입니다. 이벤트 정의서를 전달할 때는 단계별 분석뿐 아니라 구매 이전 행동을 광고의 전환 기준으로 사용하는 목적도 고려했다고 설명했습니다. 광고에서 관심 행동을 평가하는 기준과 실제 구매를 집계하는 기준을 구분한 것입니다.

구현 방식으로는 페이지 주소만 보고 행동을 추정하는 대신, 웹사이트가 행동 발생 시점에 필요한 정보를 dataLayer에 전달하도록 제안했습니다. dataLayer는 사이트 코드와 태그 사이에서 이벤트명이나 상품 정보 등을 전달하는 통로입니다. 무엇을 언제 보낼지 정한 뒤 그에 맞춰 코드를 작성하도록 요청하는 방식입니다.

정의서에는 GA4의 표준 항목과 서비스에 맞춘 항목을 나눠 적었습니다. 고객이 수집 기준을 확인한 다음 개발팀이 참고할 스크립트 가이드로 이어가도록 안내했습니다. 분석 목적을 먼저 합의해야 코드에 담을 조건도 정할 수 있기 때문입니다.

개발 요청을 전달한 다음에는 실제 서비스에서 그 조건을 재현할 준비가 필요합니다. 회원가입을 다시 확인하려면 이미 가입된 상태를 초기화해야 하고, 결제 관련 행동도 테스트할 조건을 마련해야 합니다. 이 프로젝트에서는 로그인, 회원가입, 장바구니, 결제 수단 등록과 환불 등 행동별로 수정 요청을 나눴습니다.

담당자에게 수집 환경과 사용 방법을 설명하는 온보딩 과정에서도 후속 점검 항목을 정리했습니다. 장바구니 이벤트를 특정 시작 동작에서 한 번 수집하도록 조정할 항목을 적고, 회원가입 재검수를 위한 계정 초기화를 요청했습니다. 구매와 결제 수단 등록, 스크롤 이벤트 등 남은 항목도 목록으로 전달했습니다.

온보딩 자료와 광고 유입을 구분하는 UTM 설정 가이드를 보낸 뒤에는 기존 태그 제거 여부를 다시 확인하고 보고서를 함께 볼 일정도 조율했습니다. 문서에서 정한 수집 기준이 실제 코드와 데이터에 반영됐는지 후속 검수에서 확인할 수 있도록 연결한 작업이었습니다.