B2B SaaS 무료체험·가입 전환 추적 감사 체크리스트 2026, trial signup에서 PQL까지 연결 전 확인할 기준
B2B SaaS 무료체험·가입 전환 추적 감사 체크리스트 2026, trial signup에서 PQL까지 연결 전 확인할 기준
B2B SaaS에서 무료체험 가입 수가 늘어도 매출 가능성이 같이 늘었다고 보기는 어렵습니다. 개인 이메일로 둘러보는 사용자, 테스트 계정, 학생 사용자, 기존 고객의 재가입, 기능만 잠깐 눌러본 사용자가 모두 sign_up으로 잡힐 수 있기 때문입니다.
그래서 무료체험 전환 추적은 단순히 가입 버튼 클릭이나 계정 생성 수를 세는 작업이 아닙니다. trial_started, email_verified, workspace_created, activation_completed, integration_connected, invite_teammate, pql_created 같은 제품 사용 행동을 어떤 기준으로 묶을지 먼저 정해야 합니다.
이 글은 법률 자문, 개인정보보호 자문, 광고 성과 보장 글이 아닙니다. 데모 요청 폼 중심의 리드 추적이 아니라, 무료체험 제품 행동이 product-qualified lead, 즉 PQL 후보로 넘어가기 전 운영자가 확인해야 할 감사 체크리스트입니다. 실제 적용 전에는 각 도구의 공식 문서와 회사 내부 데이터 처리 기준을 다시 확인해야 합니다.
영업 폼과 CRM 리드 중심 흐름은 B2B SaaS 데모 요청 전환 추적 감사 체크리스트에서 따로 다뤘습니다. 이번 글은 데모 요청이 없어도 제품 안에서 가입, 활성화, 사용량, 계정 단위 신호가 쌓이는 PLG형 SaaS에 초점을 둡니다. GA4와 Google Tag Manager 권한부터 불안하다면 GA4·Google Tag Manager 권한 감사 체크리스트를 먼저 보고, 영업 CRM 자동화 권한은 AI 영업 CRM 자동화 보안 체크리스트와 함께 정리하는 편이 좋습니다.
무료체험 퍼널을 가입 수가 아니라 행동 단계로 나눕니다
무료체험 가입 전환은 보통 아래 흐름으로 이어집니다.
| 단계 | 예시 이벤트 | 감사 질문 |
|---|---|---|
| 방문자 식별 | anonymous_id, session_start | 가입 전 행동과 가입 후 사용자를 연결할 수 있는가 |
| 가입 시작 | start_signup, view_signup_page | 가격 페이지, 제품 페이지, 초대 링크 유입을 구분하는가 |
| 가입 완료 | sign_up, account_created | 개인 사용자와 회사 계정 생성이 구분되는가 |
| 이메일 확인 | email_verified | 인증 전 이탈과 인증 후 사용을 분리하는가 |
| workspace 생성 | workspace_created, account_created | 사용자 단위와 회사 계정 단위를 따로 볼 수 있는가 |
| 첫 핵심 행동 | activation_completed | 제품 가치가 실제로 발생한 행동을 정의했는가 |
| 팀 사용 신호 | invite_teammate, role_assigned | 혼자 테스트한 계정과 팀 도입 후보를 구분하는가 |
| 연동 완료 | integration_connected | CRM, Slack, Google Workspace, 결제, API 연동을 구분하는가 |
| 사용량 기준 | usage_threshold_met | 일정 기간 안에 의미 있는 사용량을 넘겼는가 |
| PQL 생성 | pql_created, sales_ready_account | 영업팀에 넘길 이유와 근거가 남는가 |
가장 흔한 실수는 sign_up 하나만 주요 전환으로 두는 것입니다. 무료체험 가입은 많지만 활성화가 낮으면 랜딩 메시지, 온보딩, 가격 기대치, 제품 사용 난이도를 봐야 합니다. 가입은 적어도 activation과 팀 초대가 높다면 더 좁은 타깃에서 품질 좋은 계정이 들어오는 것일 수 있습니다.
이벤트 이름은 제품 행동 중심으로 고정합니다
GA4는 이벤트와 주요 이벤트를 기준으로 사용자 행동을 측정합니다. 제품 안의 행동을 분석하려면 가입, 인증, workspace, 초대, 연동, 활성화 같은 이름을 섞지 않고 고정해야 합니다.
출처: Google Analytics Help – Events and key events
출처: Google Analytics Help – Recommended events
출처: Google for Developers – GA4 event reference
| 이벤트 | 권장 용도 |
|---|---|
sign_up |
계정 가입 완료 |
trial_started |
무료체험 시작 또는 플랜 trial 진입 |
email_verified |
이메일 인증 완료 |
workspace_created |
팀/회사 단위 작업공간 생성 |
activation_completed |
제품의 핵심 가치 경험 완료 |
invite_teammate |
팀원 초대 |
integration_connected |
핵심 외부 도구 연동 완료 |
usage_threshold_met |
의미 있는 사용량 기준 도달 |
pql_created |
제품 사용 기준으로 영업 전달 후보 생성 |
이벤트 이름은 간단해야 합니다. signup_success, sign_up_done, user_register, trial account created가 동시에 쓰이면 분석과 CRM handoff가 흔들립니다. 새 이벤트를 추가하기 전에는 기존 제품 분석 도구, 데이터 웨어하우스, CRM 필드명과 먼저 맞춰야 합니다.
사용자 ID와 account ID를 따로 봅니다
B2B SaaS는 개인 사용자 한 명보다 회사 계정이나 workspace 단위 판단이 중요할 때가 많습니다. 한 회사에서 다섯 명이 가입했는데 모두 별도 lead로 들어가면 영업팀은 같은 회사를 여러 번 보게 됩니다. 반대로 한 명의 champion 사용자가 팀원 초대와 연동까지 끝냈는데 개인 사용자 단위로만 보면 계정 신호가 약하게 보일 수 있습니다.
| 식별자 | 쓰는 이유 | 감사 질문 |
|---|---|---|
| anonymous_id | 가입 전 방문 행동 연결 | 가입 후 user_id와 연결되는가 |
| user_id | 개별 사용자 행동 분석 | 이메일 변경, SSO 전환 후에도 유지되는가 |
| account_id | 회사·workspace 단위 분석 | 같은 회사 사용자를 하나로 묶을 수 있는가 |
| workspace_id | 제품 내 작업공간 분석 | 여러 workspace를 가진 고객을 구분하는가 |
| company_domain | 회사 추정과 중복 병합 | 무료 이메일, 대행사 도메인, 자회사 도메인을 어떻게 처리하는가 |
| CRM company ID | 영업·고객관리 연결 | 제품 account와 CRM company가 연결되는가 |
GA4 Measurement Protocol이나 서버 사이드 태깅을 쓰는 경우에는 브라우저 이벤트와 서버 이벤트가 같은 사용자를 두 번 세지 않는지 확인해야 합니다.
출처: Google for Developers – GA4 Measurement Protocol
출처: Google for Developers – Server-side tagging
출처: Google Tag Manager Help – Set up and install Tag Manager
서버 이벤트를 추가하면 측정 공백을 줄일 수 있지만, 실패 재시도와 중복 제거 기준이 함께 필요합니다. 같은 activation_completed가 브라우저와 서버에서 각각 한 번씩 들어가면 PQL 점수가 부풀 수 있습니다.
활성화 기준은 제품별로 하나의 문장으로 정의합니다
PQL 판단의 핵심은 activation입니다. 가입한 사용자가 제품의 핵심 가치를 실제로 경험했는지 보는 기준입니다. 이 기준은 제품마다 다르므로 정답처럼 복사하면 안 됩니다.
| 제품 유형 | activation 예시 |
|---|---|
| 협업 도구 | workspace 생성 후 팀원 2명 이상 초대 |
| CRM | 첫 pipeline 생성과 lead import 완료 |
| 문서 자동화 | 첫 문서 업로드 후 자동 분류 완료 |
| 분석 도구 | SDK 설치 후 첫 이벤트 수집 |
| 고객지원 도구 | 채널 연결 후 첫 티켓 처리 |
| 보안 도구 | 사용자 동기화 후 첫 정책 적용 |
| 결제 SaaS | 테스트 결제와 webhook 확인 완료 |
좋은 activation 기준은 구체적이어야 합니다. 로그인 3회처럼 표면적인 행동보다 integration_connected, first_report_created, first_ticket_resolved처럼 제품 가치와 가까운 행동이 낫습니다. 다만 너무 높은 기준을 잡으면 초반 신호가 적어져 팀이 개선 방향을 놓칠 수 있습니다.
PQL 점수는 회사별 가중치로 관리합니다
PQL은 보편적인 표준이 아니라 회사가 정하는 운영 기준입니다. 따라서 "이 행동을 하면 무조건 좋은 리드"라고 단정하기보다 점수와 사유를 함께 남기는 방식이 안전합니다.
| 신호 | 점수 예시 | 주의점 |
|---|---|---|
| 업무 이메일 사용 | +10 | 무료 이메일 사용자를 무조건 제외하면 손실 가능 |
| 회사 도메인 사용자 2명 이상 | +15 | 같은 회사인지 domain 병합 기준 필요 |
| 핵심 기능 1회 완료 | +20 | 제품별 activation 정의 필요 |
| 핵심 연동 완료 | +20 | 단순 연결과 실제 사용을 구분 |
| 팀원 초대 | +15 | 초대만 하고 미사용인 경우 제외 |
| 7일 내 재방문 | +10 | 알림 클릭만으로 부풀지 않게 관리 |
| 사용량 기준 도달 | +20 | 봇, 테스트 계정, 내부 계정 제외 |
| 가격 페이지 재방문 | +5 | 구매 의도 보조 신호로만 사용 |
점수보다 중요한 것은 pql_reason입니다. 영업팀에 넘길 때 "점수 80점"만 보내면 왜 연락해야 하는지 알기 어렵습니다. workspace_created + integration_connected + 3 active users처럼 사람이 읽을 수 있는 이유를 남겨야 합니다.
HubSpot과 Salesforce에는 제품 행동 필드를 따로 보냅니다
무료체험 사용자를 CRM에 연결할 때는 기존 영업 폼 필드만으로 부족합니다. 제품 안에서 어떤 행동을 했는지, 어느 account에 속하는지, 왜 PQL로 판단했는지 필드가 남아야 합니다.
HubSpot은 lifecycle stage를 통해 contact나 company가 어느 단계에 있는지 관리할 수 있습니다.
출처: HubSpot Knowledge Base – Use lifecycle stages
HubSpot Forms를 함께 쓰는 경우에는 웹 폼 필드와 제품 가입 필드가 서로 덮어쓰지 않는지 확인해야 합니다.
출처: HubSpot Knowledge Base – Create forms
Salesforce는 lead와 account, opportunity 흐름을 분리해서 관리합니다. 제품 가입 계정이 Salesforce lead나 account와 어떻게 연결되는지 미리 정해야 합니다.
출처: Salesforce Help – Set Up Web-to-Lead
| CRM 필드 | 감사 기준 |
|---|---|
| product_user_id | 제품 사용자와 CRM contact가 연결되는가 |
| account_id | 회사·workspace 단위 신호가 보존되는가 |
| plan | free, trial, paid, enterprise 후보가 구분되는가 |
| trial_start_date | trial 시작일과 종료일이 남는가 |
| activation_date | 핵심 행동 완료일이 남는가 |
| pql_created_at | PQL 판단 시점이 남는가 |
| pql_reason | 영업팀이 볼 수 있는 판단 근거가 있는가 |
| usage_score | 단순 가입이 아니라 사용량 기반 점수가 있는가 |
| integration_count | 연동 완료 수가 보존되는가 |
| team_member_count | 팀 사용 가능성이 보이는가 |
CRM에는 모든 이벤트를 그대로 밀어 넣지 않는 편이 좋습니다. 제품 분석 도구나 데이터 웨어하우스에는 상세 이벤트를 남기고, CRM에는 영업 판단에 필요한 요약 필드와 사유를 보내는 구조가 관리하기 쉽습니다.
Amplitude나 제품 분석 도구에서는 속성 변경을 추적합니다
제품 분석 도구는 이벤트뿐 아니라 사용자 속성과 계정 속성을 함께 봐야 합니다. Amplitude는 이벤트와 사용자 속성을 통해 사용자의 행동과 속성 변화를 분석하는 구조를 제공합니다.
출처: Amplitude Docs – User properties and events
| 속성 | 예시 값 | 보는 이유 |
|---|---|---|
| user_role | admin, member, viewer | 의사결정자와 실사용자 구분 |
| company_size | 1-10, 11-50, 51-200 | 계정 가치와 온보딩 난이도 판단 |
| signup_source | organic, paid, referral, invite | 유입 채널별 활성화 차이 |
| trial_plan | starter, pro, team | 플랜별 activation 기준 분리 |
| workspace_count | 1, 2, 3+ | 제품 구조와 확장 가능성 확인 |
| integration_type | Slack, Google Workspace, CRM, API | 깊은 사용 신호 확인 |
| activation_status | not_started, partial, completed | 온보딩 병목 파악 |
| pql_status | candidate, sent_to_sales, disqualified | 영업 전달 상태 확인 |
사용자 속성은 최신 상태를 보여주고, 이벤트는 변화의 순간을 보여줍니다. 둘을 섞어 쓰면 "지금은 pro trial"인지, "언제 pro trial로 바뀌었는지"가 흐려질 수 있습니다. 상태값과 이벤트 시간을 분리해서 기록해야 합니다.
무료체험 남용과 내부 테스트 계정은 별도 제외합니다
무료체험은 스팸과 테스트가 섞이기 쉽습니다. 가입 수를 KPI로만 보면 이런 계정이 성과처럼 보입니다.
| 제외 후보 | 확인 기준 |
|---|---|
| 내부 테스트 계정 | 회사 도메인, QA prefix, 테스트 workspace 이름 |
| 봇 가입 | 짧은 시간 반복 가입, 비정상 user agent, email pattern |
| 기존 고객 재가입 | 기존 account ID, 결제 이력, 동일 도메인 |
| 학생·개인 실험 | 개인 이메일, 낮은 사용량, 회사 정보 없음 |
| 경쟁사 조사 | 특정 도메인, 반복 조회, 영업팀 확인 |
| 초대만 수락한 사용자 | 핵심 행동 없이 member로만 존재 |
| 자동화 테스트 | webhook, API 테스트 계정, sandbox flag |
제외 기준은 너무 공격적으로 잡으면 실제 잠재고객을 놓칠 수 있습니다. 처음에는 보고서에서 분리해 보는 정도로 시작하고, 충분한 근거가 쌓이면 PQL 점수에서 감점하거나 disqualified 사유로 남기는 방식이 안전합니다.
변경 전후 7일은 activation과 PQL을 따로 봅니다
무료체험 추적을 바꾸면 가입 수, 활성화율, PQL 수가 갑자기 달라 보일 수 있습니다. 실제 성과가 좋아진 것이 아니라 이벤트 정의가 바뀐 결과일 수 있습니다.
| 변경 항목 | 전후 비교 기준 |
|---|---|
| 가입 이벤트명 변경 | 이전 sign_up과 새 sign_up이 동시에 잡히는지 |
| 이메일 인증 이벤트 추가 | 인증 전 사용자와 인증 후 사용자를 구분하는지 |
| workspace 기준 변경 | user 단위와 account 단위 집계가 달라지는지 |
| activation 기준 변경 | 기존 활성화율과 새 활성화율을 별도 표로 보는지 |
| PQL 점수 변경 | sales handoff 수가 갑자기 부풀지 않는지 |
| CRM 필드 매핑 변경 | pql_reason, usage_score가 사라지지 않는지 |
| 서버 이벤트 추가 | 브라우저 이벤트와 중복 집계되지 않는지 |
변경 전 7일, 변경 후 7일을 같은 표로 두고 가입 완료, 이메일 인증, activation, 팀 초대, 연동 완료, PQL 생성, 영업 전달을 나눠 봐야 합니다. 가입 수가 그대로인데 activation이 떨어졌다면 이벤트 누락일 수 있고, PQL이 늘었는데 영업팀 반응이 나빠졌다면 기준이 너무 약해졌을 수 있습니다.
공개 전 최종 체크리스트
아래 항목을 모두 확인한 뒤 무료체험 데이터를 광고, 제품, 영업 운영에 연결하는 편이 안전합니다.
| 체크 항목 | 완료 |
|---|---|
sign_up, trial_started, email_verified 이벤트를 구분했는가 |
|
| user_id, account_id, workspace_id가 끊기지 않는가 | |
| activation 기준을 제품별 한 문장으로 정의했는가 | |
| 팀원 초대와 연동 완료 같은 깊은 사용 신호를 분리했는가 | |
PQL 점수와 pql_reason을 함께 남기는가 |
|
| HubSpot·Salesforce에 제품 행동 요약 필드를 보내는가 | |
| 내부 테스트, 봇, 기존 고객 재가입을 보고서에서 분리하는가 | |
| 브라우저 이벤트와 서버 이벤트 중복을 막았는가 | |
| 변경 전후 7일 표로 activation과 PQL 변화를 비교하는가 | |
| 개인정보·동의·보존 기준은 내부 정책과 공식 문서로 재확인했는가 |
무료체험 전환 추적은 가입 수를 예쁘게 만드는 일이 아닙니다. 제품 사용자가 실제 가치를 경험했는지, 팀 사용 신호가 있는지, 영업팀이 연락할 이유가 있는지를 같은 데이터 언어로 연결하는 작업입니다. 이 기준이 잡히면 무료체험 숫자는 단순 vanity metric이 아니라 제품 개선과 영업 우선순위를 함께 잡는 운영 신호가 됩니다.
About The Author
