B2B SaaS 무료체험 남용·trial 품질 필터 체크리스트 2026, 테스트 계정과 봇 가입을 보고서에서 분리하는 기준

B2B SaaS에서 무료체험 가입 수가 늘었다고 바로 좋은 신호로 보면 위험합니다. 내부 QA 계정, 반복 테스트 계정, 봇 가입, 학생 계정, 개인 이메일 체험, 기존 고객의 재가입, 경쟁사 조사 계정이 모두 trial_started로 들어올 수 있기 때문입니다.

이런 계정이 섞이면 광고 보고서, 제품 분석, PQL 점수, CRM 리드 품질이 모두 부풀어 보입니다. 가입 수는 늘었는데 활성화율이 낮아 보이거나, 반대로 실제 구매 가능성이 낮은 사용자가 PQL 후보로 넘어가 영업팀 시간을 쓰게 됩니다.

이 글은 법률 자문, 개인정보보호 자문, 보안 자문, 광고 성과 보장 글이 아닙니다. 무료체험과 제품 분석을 운영하는 팀이 테스트 계정과 남용 계정을 보고서에서 분리하기 전 확인할 실무 체크리스트입니다. 실제 적용 전에는 각 도구의 공식 문서와 회사 내부 데이터 처리 기준을 다시 확인해야 합니다.

무료체험 가입 이벤트와 PQL 흐름 자체는 B2B SaaS 무료체험·가입 전환 추적 감사 체크리스트에서 먼저 정리했습니다. 데모 요청 폼과 CRM 리드 흐름은 B2B SaaS 데모 요청 전환 추적 감사 체크리스트를 보면 됩니다. GA4와 GTM 권한부터 흔들린다면 GA4·Google Tag Manager 권한 감사 체크리스트를 먼저 점검하는 편이 좋습니다.

먼저 trial 품질 필터의 목적을 정합니다

무료체험 품질 필터는 가입자를 임의로 지우는 작업이 아닙니다. 같은 데이터를 목적별로 다르게 보는 기준입니다.

목적	필터 기준
제품 온보딩 분석	내부 테스트, 봇, 명백한 중복 가입을 제외
광고 성과 분석	내부 테스트, 직원, 기존 고객 재가입, 테스트 캠페인 제외
PQL 산정	activation, team signal, integration, usage threshold 중심으로 가중
영업 전달	무료 이메일, 경쟁사 추정, 기존 고객, support 문의를 별도 라우팅
제품 실험	A/B 테스트 대상에서 내부 계정과 자동화 테스트 계정 제외
경영 보고	총 가입, 유효 trial, 활성화 trial, PQL, paid conversion을 분리

가장 중요한 것은 원본 이벤트를 삭제하지 않는 것입니다. 제품 분석 도구나 데이터 웨어하우스에는 원본을 보존하고, 보고서나 CRM handoff 단계에서 is_internal, is_duplicate, is_abuse_suspected, is_existing_customer, is_qualified_trial 같은 상태값으로 분리하는 편이 안전합니다.

제외할 계정 유형을 한 표로 고정합니다

무료체험 남용 필터는 감으로 운영하면 팀마다 기준이 달라집니다. 아래처럼 제외 후보와 보류 후보를 구분해야 합니다.

유형	예시 신호	처리 기준
내부 테스트 계정	회사 도메인, QA prefix, staging workspace	기본 보고서에서 제외
자동화 테스트	test automation user, 반복 API 호출	제품 QA 보고서로만 분리
봇 가입 의심	짧은 시간 반복 가입, 비정상 이메일 패턴	abuse suspected로 별도 집계
중복 가입	같은 회사 도메인, 같은 CRM company, 같은 workspace	account 단위로 병합
기존 고객 재가입	CRM customer status, 같은 billing account	expansion 또는 support 흐름으로 분리
학생·개인 학습	무료 이메일, 회사 정보 없음, 낮은 사용량	무조건 제외보다 별도 세그먼트
경쟁사 조사 추정	경쟁사 도메인, product-only browsing	영업 전달 제외 후보
고객지원 문의	support, help, billing 문의 목적	sales lead가 아니라 support로 라우팅

이 표를 만들 때 주의할 점은 "무료 이메일이면 무조건 나쁜 trial"이라고 단정하지 않는 것입니다. 초기 사용자가 개인 이메일로 먼저 테스트한 뒤 회사 계정으로 전환할 수도 있습니다. 따라서 제외 규칙은 강한 신호와 약한 신호를 나눠야 합니다.

GA4 이벤트에는 필터용 파라미터를 분리합니다

GA4는 이벤트와 주요 이벤트를 기준으로 행동을 측정합니다. 무료체험 품질을 보려면 sign_up, trial_started, activation_completed, pql_created 같은 이벤트와 함께 필터에 필요한 파라미터를 정리해야 합니다.

출처: Google Analytics Help – Events and key events

출처: Google for Developers – GA4 event reference

이벤트	필터용 파라미터 예시
sign_up	email_domain_type, signup_source, invited_by_user_id
trial_started	trial_plan, trial_start_source, account_id
email_verified	email_domain, is_business_domain_candidate
workspace_created	workspace_id, company_domain, workspace_name_pattern
integration_connected	integration_type, connection_scope
activation_completed	activation_rule_version, activation_reason
pql_created	pql_score, pql_reason, pql_rule_version
trial_disqualified	disqualify_reason, rule_version

필터용 파라미터를 이벤트 이름에 섞으면 안 됩니다. trial_started_internal_test, trial_started_student, trial_started_bot처럼 이벤트 이름을 계속 늘리면 보고서가 깨집니다. 이벤트 이름은 고정하고, 상태값과 사유를 파라미터나 사용자 속성으로 관리하는 편이 낫습니다.

Measurement Protocol과 서버 이벤트는 중복 제거를 먼저 봅니다

무료체험 제품은 브라우저 이벤트와 서버 이벤트를 함께 쓰는 경우가 많습니다. 가입 완료는 프론트엔드에서 잡히고, 이메일 인증이나 결제 trial은 서버에서 잡힐 수 있습니다. 이때 같은 행동이 두 번 잡히면 남용 필터 이전에 숫자 자체가 부풀어 보입니다.

출처: Google for Developers – GA4 Measurement Protocol

출처: Google for Developers – Server-side tagging

출처: Google Tag Manager Help – Set up and install Tag Manager

확인 항목	감사 질문
event_id	같은 행동을 브라우저와 서버에서 식별할 수 있는가
user_id	가입 전 anonymous_id와 가입 후 user_id가 연결되는가
account_id	개인 사용자보다 회사 계정 단위 집계가 가능한가
timestamp	서버 재시도 이벤트가 뒤늦게 중복 집계되지 않는가
retry policy	실패 재전송이 중복 trial로 보이지 않는가
test traffic	staging, QA, 내부 IP 이벤트가 분리되는가

서버 사이드 태깅을 쓰면 측정 안정성은 좋아질 수 있지만, 필터 기준이 더 중요해집니다. 서버에서 생성된 trial_started가 내부 자동화 테스트인지, 실제 사용자의 가입인지 구분할 수 있어야 합니다.

user ID, account ID, company domain을 따로 관리합니다

B2B SaaS의 trial 품질은 사용자 한 명만 보고 판단하기 어렵습니다. 같은 회사에서 여러 명이 가입했는지, 기존 고객의 다른 팀인지, 같은 사람이 이메일만 바꿔 반복 가입했는지 봐야 합니다.

식별자	쓰는 이유	주의점
anonymous_id	가입 전 방문 행동 연결	쿠키 동의와 브라우저 변경으로 끊길 수 있음
user_id	개별 사용자 행동 추적	이메일 변경, SSO 전환 뒤 유지 기준 필요
account_id	회사·workspace 단위 집계	같은 회사의 여러 workspace 처리 기준 필요
workspace_id	제품 내 작업 공간 구분	테스트 workspace naming rule 필요
company_domain	회사 추정과 중복 병합	무료 이메일과 자회사 도메인 예외 필요
CRM company ID	영업·고객관리 연결	CRM 병합 규칙과 동기화 필요
billing customer ID	유료 전환·기존 고객 확인	결제 시스템과 product account 연결 필요

무료체험 남용 필터는 한 가지 식별자만으로 만들면 오판이 많습니다. 이메일 도메인만 보면 개인 이메일 trial을 놓치고, user_id만 보면 같은 회사의 팀 사용 신호를 놓칩니다. 최소한 user, account, company domain 세 축은 따로 봐야 합니다.

내부 테스트 계정은 처음부터 이름 규칙을 둡니다

내부 테스트 계정이 보고서에 섞이는 문제는 대부분 이름 규칙 부재에서 시작합니다. QA 팀, 개발자, 마케팅 팀, 대행사가 각자 테스트 계정을 만들면 나중에 제거하기 어렵습니다.

항목	권장 규칙
이메일	qa+scenario@company.com, test+campaign@company.com처럼 prefix 통일
workspace name	[TEST], [QA], [STAGING] prefix 사용
company name	Internal Test, QA Account처럼 고정
plan	test plan 또는 sandbox plan으로 분리
source	internal_test, staging, agency_test로 명시
CRM sync	기본은 CRM 영업 큐로 보내지 않음
리포트	기본 KPI에서는 제외하고 QA 리포트에서만 확인

이미 테스트 계정이 많이 섞여 있다면 과거 데이터를 억지로 지우기보다, 특정 날짜 이후 새 naming rule을 적용하고 전후 비교표를 따로 두는 편이 안전합니다.

봇 가입 의심은 단일 신호로 차단하지 않습니다

봇이나 자동 가입을 구분할 때는 여러 신호를 함께 봐야 합니다. 한 가지 신호만으로 trial을 제외하면 정상 사용자를 잃을 수 있습니다.

신호	강도	설명
짧은 시간 같은 IP에서 다수 가입	강함	자동화나 공격 의심
email pattern 반복	중간	무작위 문자열, disposable domain 후보
이메일 인증 미완료 반복	중간	낮은 품질 가입 후보
workspace 생성 없음	약함	온보딩 이탈일 수도 있음
user agent 이상	중간	자동화 스크립트 후보
가격 페이지 미방문	약함	제품 초대 가입일 수도 있음
핵심 기능 클릭 없음	약함	온보딩 실패일 수도 있음
매우 빠른 API 호출 반복	강함	자동화 테스트 또는 남용 가능성

운영 보고서에서는 bot_suspected처럼 의심 상태로 분리하고, 실제 차단 정책은 보안·법무·개인정보 기준을 확인한 뒤 별도 흐름에서 다뤄야 합니다. 이 글의 목적은 계정을 차단하라는 것이 아니라, 성과 보고서와 PQL 산정에서 오염을 줄이는 것입니다.

기존 고객 재가입은 신규 trial과 분리합니다

기존 고객이 다른 이메일이나 다른 workspace로 다시 trial을 시작할 수 있습니다. 이 계정을 신규 acquisition으로 보면 광고 성과와 PQL 품질이 왜곡됩니다.

확인 기준	분리 방법
CRM lifecycle stage	customer, opportunity, churned customer 구분
billing customer ID	과거 결제 계정과 연결
회사 도메인	기존 customer domain과 매칭
SSO organization	같은 SSO tenant인지 확인
support ticket	고객지원 문의와 trial 가입 동시 발생 확인
account owner	기존 고객 담당자에게 라우팅

HubSpot은 lifecycle stage로 contact나 company의 단계를 관리할 수 있습니다.

출처: HubSpot Knowledge Base – Use lifecycle stages

Salesforce에서는 lead와 account, opportunity의 관계를 분리해 봐야 합니다.

출처: Salesforce Help – Leads

기존 고객 재가입은 나쁜 신호가 아닐 수 있습니다. 확장 구매, 다른 팀 도입, 재활성화 가능성이 있습니다. 다만 신규 trial acquisition 지표와는 분리해야 합니다.

CRM에는 제외 사유와 다음 라우팅을 같이 보냅니다

무료체험 품질 필터가 제품 분석 도구에만 있으면 영업팀은 여전히 낮은 품질 리드를 받습니다. CRM에는 trial 상태와 제외 사유, 다음 라우팅이 함께 들어가야 합니다.

CRM 필드	예시 값
trial_quality_status	qualified, review_needed, disqualified
trial_quality_reason	internal_test, duplicate, existing_customer, bot_suspected
pql_score	0-100
pql_reason	activation + integration + team invite
account_match_status	new_account, existing_customer, duplicate_company
source_type	paid, organic, invite, internal_test
lifecycle_stage	subscriber, lead, MQL, SQL, customer
owner_route	sales, customer_success, support, no_route

Salesforce의 중복 관리나 CRM 병합 규칙을 쓰는 팀은 중복 lead를 어떻게 처리할지 먼저 정해야 합니다.

출처: Salesforce Help – Duplicate Rules

HubSpot에서 리스트를 쓰는 팀은 active list나 static list로 trial 품질 세그먼트를 나눠 운영할 수 있습니다.

출처: HubSpot Knowledge Base – Create active or static lists

CRM에 모든 제품 이벤트를 다 보내는 것은 좋지 않습니다. CRM에는 영업 판단에 필요한 요약 필드만 보내고, 상세 이벤트는 제품 분석 도구나 데이터 웨어하우스에 남기는 구조가 관리하기 쉽습니다.

Amplitude 같은 제품 분석 도구에서는 속성과 이벤트를 분리합니다

제품 분석 도구에서는 이벤트와 사용자 속성을 혼동하지 않는 것이 중요합니다. Amplitude는 이벤트와 사용자 속성을 통해 사용자의 행동과 상태를 분석하는 구조를 제공합니다.

출처: Amplitude Docs – User properties and events

구분	예시	쓰는 이유
이벤트	trial_started, activation_completed, trial_disqualified	변화가 발생한 순간 기록
사용자 속성	user_role, email_domain_type, signup_source	현재 사용자 상태 기록
계정 속성	account_size, company_domain_type, billing_status	회사 단위 품질 판단
계산 속성	pql_score, usage_score, abuse_risk_score	보고서와 라우팅 기준
상태 속성	trial_quality_status, pql_status	현재 운영 상태

예를 들어 trial_disqualified는 이벤트로 남기고, 사용자의 현재 상태는 trial_quality_status=disqualified로 둡니다. 이렇게 해야 언제 제외됐는지와 지금 어떤 상태인지가 모두 보입니다.

결제 trial은 billing 시스템과 연결해 봅니다

카드 등록형 trial이나 유료 전환이 있는 SaaS는 제품 이벤트만으로 부족합니다. billing trial의 시작, 종료, 취소, 유료 전환이 product account와 연결되어야 합니다.

출처: Stripe Docs – Trials in subscriptions

billing 신호	확인 질문
trial_start	제품의 trial_started와 같은 계정인가
trial_end	만료 전 사용량과 알림이 연결되는가
payment_method_added	구매 의도 신호로 따로 보는가
subscription_created	유료 전환과 product account가 연결되는가
subscription_canceled	trial abuse인지 정상 이탈인지 구분하는가
invoice_failed	결제 실패와 제품 사용 신호를 분리하는가

카드 등록형 trial은 가입 품질이 높아 보일 수 있지만, 결제 실패와 취소가 섞이면 실제 전환율은 다르게 보입니다. 반대로 카드 없는 trial은 볼륨이 많지만 활성화 품질을 더 엄격히 봐야 할 수 있습니다.

보고서는 총 가입과 유효 trial을 분리합니다

무료체험 리포트는 하나의 숫자로 끝내면 안 됩니다. 아래처럼 raw, filtered, qualified를 분리해야 운영 판단이 가능합니다.

지표	의미
raw signups	필터 전 전체 가입
verified signups	이메일 인증 완료 가입
trial started	무료체험 시작
internal/test excluded	내부 테스트 제외 수
duplicate excluded	중복 계정 제외 수
abuse suspected	봇·남용 의심 수
existing customer separated	기존 고객 재가입 분리 수
valid trial	기본 품질 필터 통과 trial
activated trial	핵심 행동 완료 trial
PQL	영업 전달 후보
paid conversion	유료 전환

raw signups가 늘었는데 valid trial이 그대로라면 마케팅 유입 품질이나 봇 가입을 봐야 합니다. valid trial은 늘었는데 activated trial이 낮다면 온보딩과 제품 가치 경험을 봐야 합니다. activated trial은 높은데 PQL이 낮다면 회사 규모, 팀 사용 신호, CRM 매칭 기준을 다시 봐야 합니다.

변경 전후 7일은 rule version으로 비교합니다

trial 품질 필터를 바꾸면 과거와 현재 숫자가 달라집니다. 실제 사용자가 바뀐 것이 아니라 규칙이 바뀐 결과일 수 있습니다.

변경 항목	비교 기준
internal domain rule 추가	내부 제외 수와 valid trial 감소폭
duplicate company rule 추가	account 단위 trial 수 변화
bot suspected rule 추가	abuse suspected 비율
existing customer 분리	신규 acquisition trial 감소폭
PQL score 가중치 변경	PQL 수와 sales accepted lead 변화
activation rule 변경	activation rate 전후 비교

규칙에는 trial_quality_rule_version을 붙이는 편이 좋습니다. 예를 들어 2026-07-v1 규칙으로 집계한 7일과 2026-07-v2 규칙으로 집계한 7일을 구분해야 팀이 같은 숫자를 보고 이야기할 수 있습니다.

운영 체크리스트

아래 항목을 통과한 뒤에만 trial 품질 필터를 광고 최적화나 영업 라우팅에 연결하는 편이 안전합니다.

체크 항목	완료
원본 이벤트를 삭제하지 않고 필터 상태값만 추가하는가
내부 테스트 계정 naming rule이 있는가
봇 의심, 중복, 기존 고객, support 문의를 별도 사유로 분리하는가
user_id, account_id, company_domain, CRM company ID가 따로 관리되는가
브라우저 이벤트와 서버 이벤트 중복 제거 기준이 있는가
GA4 이벤트 이름과 파라미터가 고정되어 있는가
CRM에 trial_quality_status와 trial_quality_reason이 들어가는가
PQL 점수와 pql_reason이 함께 남는가
billing trial이 product account와 연결되는가
변경 전후 7일 비교표와 rule version이 있는가

무료체험 품질 필터의 목표는 가입자를 많이 제외하는 것이 아닙니다. 총 가입, 유효 trial, 활성화 trial, PQL, 유료 전환을 분리해서 봄으로써 제품팀, 마케팅팀, 영업팀이 같은 숫자를 믿고 움직이게 만드는 것입니다.