GA4 전환 추적 설정 대행의 납품물이 태그 설치 화면뿐이라면 문의 완료를 제대로 측정하는지 알기 어렵습니다. 버튼을 누른 순간과 서버가 문의를 받아 저장한 순간을 구분하고, 정상 제출 한 건이 어떻게 기록되는지 확인해야 합니다.
검수의 기준은 태그 유무보다 실제 문의와 이벤트가 맞는지입니다.
1. 문의 완료 이벤트가 의미하는 행동을 정하세요
GA4에서는 사업에 중요한 행동을 주요 이벤트로 지정합니다. Google 주요 이벤트 설명을 참고해 문의 완료의 조건과 이벤트 이름을 문서로 정하세요. 버튼 클릭이나 폼 시작은 보조 지표로 두고, 서버 응답 실패를 성공 이벤트로 세지 않도록 개발 담당자와 저장 성공 시점을 합의합니다.
2. 완료 페이지와 중복 발생을 별도로 시험하세요
완료 페이지를 새로 고치거나 주소로 바로 방문해도 이벤트가 생기는지 보세요. 제출 재시도와 빠른 연속 클릭도 검사해야 합니다. GA4에는 이벤트당 또는 세션당 집계 방식이 있으므로 공식 집계 방식 문서와 설정을 함께 확인합니다. 세션당 집계로 숫자만 줄이는 것은 중복 발생 원인 수정을 대신하지 못합니다.
3. 견적 신청 사이트에서 실패 시나리오를 남기세요
예시로 정상 제출, 필수 입력 누락, 저장 실패, 완료 페이지 재방문을 각각 시험합니다. 정상 저장은 한 건인데 이벤트가 두 번이면 설치 위치와 실행 조건을 확인해야 합니다. DebugView 공식 문서는 디버그 모드에서 이벤트를 살펴보는 방법을 설명합니다. 테스트 기기와 시각, 저장 결과, 이벤트 확인 화면을 묶어 받으세요.
4. 수정과 인계까지 포함한 대행 계약을 받으세요
이벤트 설계, 태그 설치, 개발 수정, 테스트와 보고서 구성을 항목별로 견적 받으세요. 폼이 바뀌었을 때 재검수 비용과 하자 보수 기간도 정합니다. 최종 결과물에는 이벤트 정의서, 적용 버전, 제외 조건과 관리자 권한이 있어야 합니다. 실명·전화번호 같은 개인정보를 분석 이벤트에 넣지 않도록 전달 항목도 검수합니다. Google PII 전송 예방 문서를 참고하세요.
계약 전 체크리스트
- 정상 저장과 오류 상황을 각각 시험했는가
- 태그를 설치한 위치와 수정 이력이 남아 있는가
- 동의 상태 등 측정 조건을 테스트 기록에 적었는가
자주 묻는 질문
완료 페이지 조회만 써도 되나요?
구현에 따라 가능하지만 직접 방문과 새로고침이 잘못 집계되는지 확인해야 합니다.
주요 이벤트 수가 문의 인원인가요?
이벤트와 사람은 다릅니다. 같은 사람이 여러 요청을 보낸 경우의 집계 기준을 따로 정하세요.
DebugView에서 안 보이면 제출 실패인가요?
단정할 수 없습니다. 동의 상태와 디버그 설정을 확인하고 실제 저장 기록을 먼저 대조하세요.
인수 후 사이트를 수정하면 어떻게 하나요?
폼 동작이 바뀌면 다시 시험해야 합니다. 재검수 담당자와 비용을 유지관리 조건에 넣으세요.