GA4 리드 이벤트 뜻: disqualify_lead, close_unconvert_lead 정리

리드와 리드 이벤트는 무엇인가요?

리드(lead)는 상담 신청이나 도입 문의처럼 상품과 서비스에 관심을 보인 잠재고객입니다. 예를 들어 기업 교육 담당자가 '직원 20명 대상 교육 견적'을 요청하면 그 요청 하나를 리드 하나로 관리합니다.

GA4는 웹사이트와 앱의 이용 현황을 분석하는 도구이고, 이벤트는 GA4에 기록하는 행동 하나하나입니다. 리드 이벤트를 쓰면 문의를 받았는지, 상담했는지, 고객이 됐는지를 나눠 기록할 수 있습니다. 최종 계약은 온라인에서도 오프라인에서도 일어납니다.

교육 견적 문의 하나가 지나가는 상태를 리드 이벤트 이름과 함께 놓으면 이렇습니다.

교육 견적 문의 하나가 지나가는 상태

1. 11. 문의 접수generate_lead
   견적 요청이 정상 저장됨
2. 22. 기준 판단qualify_lead
   맞지 않으면 disqualify_lead
3. 33. 상담working_lead
   담당자와 연락이 오감
4. 44. 종료close_convert_lead
   계약 없이 끝나면 close_unconvert_lead

설치보다 먼저 정할 것은 우리 회사의 문의 하나를 어떤 상태로, 언제 기록할지입니다. 이 기준이 없으면 이벤트를 여섯 개 다 보내도 숫자를 해석할 수 없습니다.

화면에 이름이 보여도 자동 수집은 아닙니다

GA4 속성을 만들 때 비즈니스 목표를 고르면 그 목표에 맞는 보고서와 추천 설정이 보입니다. 아래는 비즈니스 목표에서 리드 생성을 고른 화면입니다.

목표를 고르는 일과 이벤트를 수집하는 일은 별개입니다. Google의 추천 이벤트는 이벤트 이름과 구조를 권장하는 목록이고, 실제 수집은 사이트나 앱에서 필요한 정보를 담아 직접 보내도록 설정해야 일어납니다. 리드 생성 목표를 고르지 않은 속성에서도 같은 이벤트를 쓸 수 있습니다.

다음은 Google 문서에 실린 리드 관련 추천 이벤트 여섯 개와 권장 발생 시점입니다. 아래 절에서 이 여섯 이름을 교육 상담 사례에 하나씩 대입합니다.

여섯 이벤트를 교육 상담 사례에 대입하기

가운데 열은 Google의 공식 정의를 요약한 것이고, 오른쪽 열은 교육 상담에서 생길 수 있는 예입니다.

disqualify와 close_unconvert는 어떻게 다른가요?

disqualify_lead는 이 리드가 자격 기준에 맞지 않는다는 판단이고, close_unconvert_lead는 고객이 되지 않은 채 리드를 닫았다는 판단입니다. 두 판단을 나누는 기준은 상담 전후가 아닙니다. 상담 도중에 자격 미충족을 알게 될 수도 있고, 연락이 닿지 않는 리드를 회사의 종료 기준에 따라 미전환으로 닫을 수도 있습니다.

두 이벤트로 나누는 실제 상황

상황	disqualify_lead자격 미충족	close_unconvert_lead미전환 종료
제공하지 않는 교육 분야를 요청함	제공	제공하지 않음
상담 중에 교육 대상이 아님을 알게 됨	제공	제공하지 않음
자격은 맞지만 다른 업체와 계약함	제공하지 않음	제공
응답 없이 회사가 정한 종료 기간이 지남	제공하지 않음	제공
검토 중이라는 답을 받음	제공하지 않음	제공하지 않음

검토 중인 리드를 언제부터 종료로 볼지는 영업 담당자와 같은 기준을 정해 두어야 집계가 맞습니다.

반드시 같은 순서로 진행하나요?

아닙니다. 첫 절의 네 단계는 가능한 경로 하나일 뿐이고, Google이 여섯 단계의 순서를 정해 두지는 않았습니다. 실제 업무에서는 상담을 먼저 하고 자격을 나중에 판단하기도 하고, 종료한 문의가 다시 진행되기도 합니다. 순서보다 중요한 것은 각 상태를 언제, 누가, 어떤 근거로 기록하는지입니다.

문의 접수 하나의 기록 기준부터 정합니다

처음에는 generate_lead 하나만 정해도 됩니다. 핵심은 버튼을 누른 순간과 접수가 끝난 순간을 구분하는 것입니다. 같은 신청이라도 이벤트를 어디에 연결하느냐에 따라 기록이 달라집니다.

generate_lead를 어디에 연결하느냐에 따라 달라지는 기록

신청 결과	버튼 클릭에 연결누르면 바로 기록	저장 성공에 연결서버가 접수를 알린 뒤
정상 접수	기록됨	기록됨
필수 항목 오류로 접수 안 됨	기록됨	기록 안 됨
서버 저장 실패	기록됨	기록 안 됨

웹사이트 상담 신청을 측정한다면 기준표는 이 정도로 정합니다.

GA4의 향상된 측정은 양식 제출 같은 웹 행동을 설정에 따라 자동으로 기록합니다. 여기서 form_submit이 잡혀도 그 기록이 우리 서비스의 실제 저장 성공과 일치하는지는 따로 따져야 합니다. 양식을 만든 방식에 따라 자동 기록이 잡히는 시점이 다르기 때문입니다.

실제 성공 신호는 개발 담당자가 Google Tag Manager(GTM)나 사이트 코드에 연결합니다. GTM은 측정 태그를 한곳에서 관리하는 도구입니다. 이미 같은 행동을 수집하는 태그가 있는지 먼저 찾고, 같은 행동에 태그를 두 개 걸지 않습니다.

연결한 뒤 점검하는 순서

운영 사이트에 임의로 신청을 반복해 넣지 말고, 테스트 환경과 테스트용 신청 정보를 정해 두고 점검합니다. 아래 네 단계를 차례로 진행합니다.

generate_lead 연결 뒤 점검 순서

1. 11. 정상 신청테스트 신청을 접수
   generate_lead가 1회 기록되면 성공
2. 22. 오류 신청필수 항목을 비우고 제출
   이벤트가 없으면 성공
3. 33. 새로고침완료 화면을 다시 불러옴
   추가 기록이 없으면 성공
4. 44. 건수 대조신청 시스템의 접수 건수와
   GA4 보고서 건수를 비교

3단계의 중복 방지는 이벤트를 보내는 쪽에서 설계해야 합니다. 이벤트 이름을 generate_lead로 정해도 GA4가 같은 신청의 중복 전송을 알아서 걸러 주지 않습니다.

1단계부터 3단계까지는 GA4의 실시간 보고서나 관리 → 데이터 표시 → DebugView에서 봅니다. DebugView는 디버그 모드로 보낸 이벤트만 따로 보여 주는 개발용 화면입니다. 여기에 아무것도 뜨지 않으면 디버그 모드를 켰는지, 올바른 속성으로 보내는지를 담당자가 살펴봅니다. 사용자 동의나 개인정보 설정 때문에 이벤트가 표시되지 않는 경우도 있는데, 이때 동의를 우회해 전송하지는 않습니다.

4단계는 일반 보고서에서 합니다. 개발용 트래픽을 제외하도록 설정해 두었다면 테스트 이벤트가 일반 보고서에 없는 것이 정상이므로, 어떤 보고서로 대조할지 담당자와 미리 정합니다. 이벤트가 한 번 보였다고 모든 이용자의 수집을 검증한 것은 아니므로 점검 날짜와 조건, 결과를 함께 남겨 둡니다.

CRM이 없어도 상태 기준은 만들 수 있습니다

CRM(Customer Relationship Management)은 고객 정보와 상담 이력을 관리하는 시스템입니다. 전문 CRM이 있으면 상태 관리와 자동 전송이 편해지지만, 리드 정의는 CRM 없이도 시작할 수 있습니다. 작은 팀은 접근 권한을 제한한 업무 시트나 기존 신청 관리 화면에 상태 열을 두고 기록부터 합니다.

다만 시트에 상태를 적는 일과 GA4에 이벤트를 보내는 일은 별개입니다. 시트 기록만으로도 팀의 기준을 점검할 수 있지만, GA4 이벤트가 저절로 생기지는 않습니다. GA4와 연동하려면 세 가지를 차례로 정합니다.

상태 기록을 GA4로 보내기 전에 정할 것

1. 11. 상태 확정어떤 상태 변경을
   누가 확정하는지
2. 22. 기록 연결신청 기록과 웹 이용 기록을
   어떤 허용된 값으로 잇는지
3. 33. 전송과 중복어느 시스템이 언제 보내고
   재시도 때 중복을 어떻게 막는지

2단계에서 자주 쓰는 값이 client_id입니다. client_id는 브라우저 단위로 이용 기록을 구분하는 값이라, 기기나 브라우저, 저장 상태가 바뀌면 달라집니다. 사람마다 평생 하나씩 붙는 고객 번호가 아니며, 이메일 주소나 전화번호를 이 값에 그대로 넣어서도 안 됩니다.

3단계에서 서버가 직접 보내는 방법으로는 Measurement Protocol이 있습니다. 웹이나 앱 수집을 보완해 서버에서 GA4로 이벤트를 보내는 기능입니다. generate_lead 다음 상태가 웹이나 앱 안에서 일어난다면 그 화면에서 바로 이벤트를 보내도 됩니다.

세션은 일정 시간 이어지는 이용 활동의 묶음이고, session_id는 세션을 구분하는 값입니다. 몇 주 뒤 계약 이벤트에 예전 session_id를 넣어 보내도 처음 방문한 세션의 유입 출처는 되살아나지 않습니다. 세션에 이벤트를 붙이려면 전송 시각과 실제 발생 시각이 정해진 조건을 맞춰야 합니다. 계약 날짜를 최초 문의 날짜로 바꿔 보내는 방식은 쓰지 않고, 몇 주에 걸친 영업 분석은 별도의 리드 기록과 연결 설계로 합니다.

이벤트에 상담 원문을 넣지 않습니다

리드 종료 이유를 분류하고 싶다면 '제공 범위 외', '타사 선택', '연락 불가'처럼 회사가 정한 범주 이름으로 보냅니다. 매개변수는 이벤트와 함께 보내는 부가 정보입니다. 매개변수와 페이지 URL에는 개인을 알아볼 수 있는 정보를 담지 않습니다.

리드 이벤트에 담을 수 있는 것

담을 정보	이벤트 매개변수이벤트와 함께 보내는 값	페이지 URL주소 뒤에 붙는 값
종료 이유 범주(제공 범위 외, 타사 선택)	제공	–
고객 이름	제공하지 않음	제공하지 않음
이메일 주소, 전화번호	제공하지 않음	제공하지 않음
상담 내용 원문	제공하지 않음	제공하지 않음

종료 이유는 자세히 적을수록 좋은 것이 아니라 같은 기준으로 집계할 수 있어야 쓸모가 있습니다. 범주를 서너 개로 정해 두면 담당자가 바뀌어도 같은 이름으로 기록됩니다.

이벤트 횟수만 나누면 전환율이 되나요?

이번 달 generate_lead가 100회, close_convert_lead가 20회라고 리드 전환율이 20%로 정해지지는 않습니다. 같은 신청이 두 번 기록됐을 수 있고, 이번 달 계약에는 지난달 문의가 섞여 있을 수 있습니다.

전환율은 같은 집단을 정해진 기간 동안 따라가서 계산합니다. 예를 들어 별도 리드 기록에서 8월에 새로 들어온 리드를 따라가면 이렇게 집계합니다.

8월 접수 리드의 30일 내 계약 전환율 계산 예

• 100건8월에 새로 접수한 리드같은 신청의 중복은 뺀 수
• 20건접수 후 30일 안에 계약100건 가운데
• 20%30일 내 계약 전환율20 나누기 100

이 계산은 100건 모두 30일 관찰이 끝난 뒤에 집계했기 때문에 성립합니다. 아직 30일이 지나지 않은 리드가 섞여 있으면 그 리드를 미전환으로 치지 말고, 기간이 끝난 뒤 다시 집계합니다.

자격 미충족 비중이 높다면 그 숫자는 광고 대상, 서비스 안내, 접수 기준, 담당자의 기록 방식을 차례로 살펴볼 단서입니다. 그 비율 하나로 마케팅 탓이라고 결론 내리지는 않습니다. 계약 비중이 낮을 때도 가격, 고객 일정, 제안 내용, 수집 누락을 함께 봅니다.

어디서 결과를 보나요?

리드 이벤트를 보내기 시작했다면 GA4 보고서 메뉴에서 결과를 봅니다.

GA4에서 리드 결과를 보는 순서

1. 11. 보고서 열기왼쪽 메뉴의
   보고서
2. 22. 리드 생성 모음보고서 모음에 따라
   획득 아래에 있기도 함
3. 33. 리드 획득리드 이벤트 결과를
   보는 기본 보고서
4. 44. 자격 미충족 및 손실disqualify와 close_unconvert의
   이유별 집계

메뉴가 보이지 않으면 편집자 이상 권한을 가진 담당자에게 보고서 모음 추가를 요청합니다. 보고서 이름이 미리 떠 있거나 값이 0으로 나온다고 수집이 정상인 것은 아니므로, 이벤트를 보내기 시작한 날짜와 실제 전송 상태를 함께 봅니다.

4단계의 리드 자격 미충족 및 손실 보고서는 disqualify_lead와 close_unconvert_lead를 보낸 자료로 만들어집니다. 회사의 상태 기록이 일관돼야 이 보고서의 이유별 숫자를 판단에 쓸 수 있습니다.

처음 설계를 끝냈는지는 문의 접수 기준표에 발생 조건, 제외 조건, 중복 처리 세 가지가 적혔는지로 판단합니다. 이 세 항목을 개발 담당자와 분석 담당자가 같은 뜻으로 설명할 수 있으면 실제 전송과 보고서 점검으로 넘어갑니다.

자주 묻는 질문

여섯 개를 전부 써야 하나요?

아닙니다. 정확히 기록할 수 있는 행동부터 시작합니다. 문의 접수와 계약 완료만 필요하다면 그 두 상태를 먼저 설계하고, 추가 분석이 필요해질 때 나머지를 더합니다.

쇼핑몰도 리드 이벤트를 쓸 수 있나요?

도입 문의나 대량 구매 상담을 따로 운영한다면 쓸 수 있습니다. 이때 일반 상품 구매와 상담 리드가 같은 성과로 두 번 합산되지 않도록 정의를 나눠 둡니다.

Sources

• 추천 이벤트 안내
• 리드 이벤트 공식 정의
• 리드 양식 측정 안내
• DebugView 안내
• Measurement Protocol 개요
• Measurement Protocol 세션 연결 조건
• 개인 식별 정보 전송 방지 안내
• 리드 획득 보고서
• 리드 자격 미충족 및 손실 보고서

3줄 요약

1. 리드 이벤트는 문의부터 고객 전환까지의 행동을 기록하는 추천 이벤트로, 이름이 보인다고 자동 수집되는 것은 아닙니다.

2. 자격 미충족과 미전환 종료는 서로 다른 판단이며 모든 리드가 여섯 이벤트를 정해진 순서로 통과하지는 않습니다.

3. 먼저 회사의 상태 기준과 발생 시점을 정하고 제출 성공, 중복 기록, 같은 리드 집단의 전환 여부를 검증합니다.