작성: IILL Editorial · 이벤트 이름과 성공 조건은 사이트별 계측 계약에 맞춰 검증하세요.
랜딩페이지 전환은 CTA 버튼을 누른 순간이 아니라 서버가 문의를 정상 접수한 순간으로 측정해야 합니다. 클릭, 제출 시도, 성공, 실패를 하나의 이벤트로 묶으면 실제 문의 수를 부풀리고 폼 장애도 찾기 어렵습니다.
가장 작은 실무 퍼널은 page_view → contact_click → submit_intent → submit_success입니다.
실패는 성공에 섞지 않고 submit_failure로 따로 봅니다.
네 단계의 의미를 먼저 정합니다
| 단계 | 예시 이벤트 | 발생 조건 | 주요 전환인가 |
|---|---|---|---|
| 방문 | page_view |
랜딩페이지가 표시됨 | 아니요 |
| 관심 | contact_click |
상담·전화·메일 CTA를 누름 | 아니요 |
| 제출 의도 | contact_form_submit_intent |
유효한 폼이 서버로 전송되기 직전 | 아니요 |
| 접수 성공 | contact_form_submit_success |
서버가 저장·메일 발송 성공을 확인 | 예 |
| 접수 실패 | contact_form_submit_failure |
서버·네트워크·검증 오류 | 아니요 |
GA4는 폼이나 정보 요청을 제출했을 때 generate_lead 사용을 권장합니다. 이 의미가
조직의 보고 기준과 맞을 때 사용하세요. 이 사이트에서 문의 완료는 서버가 접수를
확인한 성공을 뜻합니다. 전송을 시도했지만 저장이나 전달에 실패한 요청은 문의가
아닙니다. 서버 확인 뒤 generate_lead를 보내거나, 기존 성공 이벤트를 유지하고 두
이름의 관계를 문서로 남기세요.
이벤트 → 주요 이벤트 → Google Ads 전환
세 단계는 서로 다른 설정입니다.
- 이벤트: 서버가 결과를 확인한 뒤 사이트가
contact_form_submit_success를 보냅니다. - 주요 이벤트: GA4에서 이 이벤트를 사업상 중요한 행동으로 표시합니다.
- Google Ads 전환: GA4와 Google Ads가 연결되어 있다면 이 주요 이벤트를 광고 측정과, 설정에 따라 입찰에 사용하는 전환으로 만들거나 가져옵니다.
세 단계에서 같은 서버 확인 결과를 사용하세요. 수치가 더 많이 쌓인다는 이유로 CTA 클릭을 주요 이벤트나 광고 전환으로 올리면 실제 문의보다 클릭을 최적화하게 됩니다. 다만 기여 분석, 집계 기간, 시간대와 설정 차이로 GA4와 Ads 합계는 달라질 수 있으므로 어떤 이벤트와 설정을 썼는지 함께 기록합니다.
클릭을 전환으로 잡으면 무엇이 틀어지나요?
사용자는 버튼을 누른 뒤 다음 상황에서 문의를 완료하지 못할 수 있습니다.
- 필수 입력 오류를 만난다.
- 네트워크가 끊긴다.
- 서버가 오류를 반환한다.
- 메일 발송이나 저장이 실패한다.
- 중복 클릭으로 요청이 여러 번 발생한다.
클릭만 보고하면 광고와 콘텐츠가 성공한 것처럼 보이지만 실제 담당자에게 도착한 문의는 없습니다. 클릭은 카피와 CTA 위치를 진단하는 지표로 남기고, 성공 이벤트만 key event로 설정합니다.
구현 순서
1. 공통 문맥을 작게 정하기
locale, page_type, content_group, ui_location, contact_method처럼 실제 보고에
쓸 값만 보냅니다. 값의 종류가 계속 늘어나는 버튼 문구나 원문은 custom dimension으로
만들지 않습니다.
gtag("event", "contact_click", {
locale: "ko",
page_type: "landing_page",
ui_location: "hero",
contact_method: "form"
});2. 유효한 제출 직전에 의도 기록하기
브라우저 validation을 통과하고 실제 request를 시작할 때 한 번 기록합니다. 단순히 submit button에 click listener만 붙이면 keyboard 제출과 validation 실패를 정확히 구분하기 어렵습니다.
3. 서버 응답 뒤 성공과 실패 나누기
성공 응답을 받은 뒤 contact_form_submit_success를 보냅니다. 실패 응답과 exception은
contact_form_submit_failure에 result처럼 제한된 오류 종류만 붙입니다. 오류 원문,
폼 입력값, 이메일 주소는 보내지 않습니다.
4. 중복을 막기
제출 중 버튼을 잠그고 server idempotency를 적용합니다. GA4 이벤트도 같은 성공을 두 번 보내지 않도록 상태를 관리합니다. thank-you page를 함께 쓰는 경우, callback과 page_view 양쪽에서 성공 이벤트가 중복되지 않는지 확인합니다.
UTM은 유입 이름표이지 사용자 데이터 칸이 아닙니다
외부 캠페인 링크에는 합의된 utm_source, utm_medium, utm_campaign을 사용합니다.
내부 링크에 UTM을 붙이면 기존 유입 세션을 새 캠페인처럼 덮어쓸 수 있으므로 사용하지
않습니다. 임의 query 전체를 분석으로 보내지 말고 허용한 값만 정규화합니다.
예시 규칙:
utm_source:naver,google,newsletterutm_medium:cpc,organic,emailutm_campaign: 팀이 합의한 짧은 campaign ID
이름, 이메일, 전화번호, 문의 내용, 내부 customer ID를 UTM이나 event parameter에 넣지 마세요. GA4는 상담 내용을 보관하는 CRM이 아닙니다.
공개 전 QA
- 별도 QA browser에 테스트 표시를 붙입니다.
- CTA 클릭, 유효한 제출, 성공, 실패를 한 번씩 실행합니다.
- browser payload에서 event name과 제한된 parameter를 확인합니다.
- GA4 Realtime 또는 DebugView에서 순서와 수신을 확인합니다.
- 서버의 실제 접수·메일 발송도 함께 확인합니다.
- QA traffic은 분석에서 구분하되 raw collection을 바로 삭제하지 않습니다.
Google의 lead form 보고 가이드는 방문부터 제출까지의 이탈을 funnel exploration으로 보는 방법을 설명합니다. custom dimension은 parameter가 실제로 수집되고 보고에 필요하다는 것을 확인한 뒤 만드세요. 새 정의는 과거 데이터에 소급 적용되지 않습니다.
보고서에서 볼 네 가지 비율
- CTA 관심률 =
contact_click / landing sessions - 폼 시작률 =
submit_intent / landing sessions - 완료율 =
submit_success / submit_intent - 실패율 =
submit_failure / submit_intent
처음에는 locale, landing page, source/medium 정도로만 나눕니다. 표본이 작은데 버튼별, 기기별, 캠페인별로 모두 쪼개면 결론보다 노이즈가 커집니다. 28일 단위로 보되, 폼 실패는 운영 장애이므로 즉시 확인합니다.
지금 할 일: 실제 테스트 문의를 한 건 보내고 브라우저 전송값, GA4 DebugView, 문의가 남은 메일함이나 데이터베이스 기록까지 이어서 확인하세요. Ads가 연결되어 있다면 같은 이벤트가 의도한 전환에 들어왔는지도 봅니다. 홈페이지 전체가 필요한지 먼저 판단해야 한다면 홈페이지와 랜딩페이지의 차이를 확인하고, 폼과 측정 기준을 함께 설계하려면 랜딩페이지 제작 서비스에서 범위를 정할 수 있습니다.
홈페이지 제작, 어디서부터 정할지 막막하신가요?
현재 상황과 필요한 결과를 들은 뒤, 만들 범위와 다음 단계를 먼저 정리합니다.