수요 분석
수요가 변하는 이유와 구매 조건·고객 선호를 구분하는 기준
발행
수요가 흔들릴 때 가격부터 바꾸면 원인을 놓치기 쉽습니다. 변화 이유는 구매 조건과 고객 선호의 변화로 나눠 살피고, 이 구분을 가격 민감도 분석과 동적 가격 검토의 출발점으로 삼습니다. B2B SaaS에서는 계약 규모와 예산 승인 절차가 구매 조건에 들어갑니다. 사용자가 중시하는 보안이나 자동화 수준은 고객 선호에 해당합니다. 두 신호를 분리하면 가격 조정 전에 어느 단계에서 수요가 달라졌는지 추적할 수 있습니다.
수요 변화의 두 축
둘로 나눕니다. 경제학에서 가격이 바뀌어 같은 수요곡선 위의 선택량이 달라지는 경우와 소득이 바뀌어 수요곡선 자체가 이동하는 경우는 기록 방식이 다릅니다. 대체재의 조건이나 선호 변화는 수요 자체를 움직이는 요인이므로 별도 신호로 표시합니다. 위키백과의 수요 설명을 B2B SaaS에 적용할 때 계약 단가와 결제 조건은 구매 조건, 보안 요구나 자동화 선호는 고객 선호로 분류합니다. 구매 조건은 거래가 성립하는 문턱이고, 고객 선호는 조건이 같을 때 무엇을 고르는지 드러내는 선택의 방향입니다. 두 데이터를 한 지표로 합치면 원인 분석이 흐려집니다. 구매 조건의 변경 시점과 기능 사용 패턴을 같은 지표에 넣지 않습니다.
구매 조건 변화의 판별
구매 조건은 거래 문턱입니다. 가격이 그대로인데 문의가 줄었다면 예산 승인 시점과 결제 방식이 달라졌는지 먼저 확인합니다. B2B SaaS에서는 보안 검토가 길어지거나 계약 기간 기준이 바뀌는 것만으로도 구매 완료까지 걸리는 경로가 달라집니다. 이 변화를 고객 선호 하락으로 읽지 않습니다. 견적 요청일과 승인 단계부터 계정 단위로 로그에 남기고, 결제 실패 사유는 별도 필드로 기록합니다. 예산 축소 응답과 결제 중단 시점이 겹치는지 비교합니다. 특정 기능을 계속 조회하지만 결제 직전에서 멈추는 계정이 늘면 기능보다 구매 절차의 마찰을 먼저 분리해 읽습니다.
고객 선호 변화의 판별
가격은 같아도 변합니다. 같은 요금제에서 검색 기능 사용은 유지되는데 자동화 기능 선택이 줄었다면, 거래 조건보다 제품 선호가 이동한 신호로 기록합니다. 문의 문장에서 보안 요구가 반복되다가 처리 속도 질문으로 바뀌는 흐름도 선호 데이터로 분리합니다. 단일 계정의 클릭만으로 판단하지 않고 신규 계정과 기존 계정을 나눠 같은 기간의 선택률을 비교합니다. 가격 민감도 분석은 할인 반응만으로 판단하지 않습니다. 동일한 구매 조건에서 기능 조합이 선택되는 흐름을 읽고, AI 에이전트가 자동 분류하더라도 원본 이벤트에는 계정 구분과 요금제 조건을 함께 남겨 선호와 구매 장벽을 섞지 않습니다.
데이터 판별과 가격 실험
판별은 2단계로 합니다. 1단계에서는 조건을 고정합니다. 같은 요금제와 같은 결제 흐름에서 계정군별 기능 선택 차이를 기록합니다. 2단계에서는 조건을 바꿉니다. 가격이나 청구 주기를 바꾼 뒤 이탈 지점이 이동하면 구매 조건 신호로 남기고, 조건을 유지한 채 특정 기능의 선택만 달라지면 고객 선호 신호로 분류합니다. 국회도서관은 AI 에이전트를 별도 주제로 다룹니다. 가격 A/B 테스트와 동적 가격 엔진은 이 분류를 입력값으로 삼고, 가격 최적화 솔루션의 자동 조정 범위와 사람의 검토 책임을 업무 전환의 맥락에서 정한 뒤 운영합니다.
핵심 요약
- 두 가지 수요 변화는 거래 문턱을 바꾸는 구매 조건과 선택 방향을 바꾸는 고객 선호로 나뉩니다.
- B2B SaaS에서는 예산 승인 지연과 결제 이탈을 기능 선호와 분리해 기록합니다.
- 가격 민감도 분석은 A/B 테스트의 할인 반응만 세지 않고 같은 조건에서 기능 선택이 어떻게 달라지는지 읽습니다.
- 동적 가격과 가격 최적화 솔루션은 원인 분류 뒤에 자동 조정 범위를 정하는 순서로 적용합니다.
자주 묻는 질문
구매 조건 변화와 고객 선호 변화는 어떻게 먼저 나누나요?
가격과 계약 조건이 바뀌었는지 먼저 확인합니다. B2B SaaS에서 조건이 같을 때 기능 선택만 달라지면 고객 선호 신호로 분리하고 결제 직전 이탈이 함께 늘면 구매 조건 기록을 다시 봅니다.
가격이 내려갔는데도 수요가 줄면 무엇을 확인하나요?
가격 인하만으로 선호 하락을 판단하지 않습니다. 예산 승인 단계와 결제 방식이 바뀌었는지 계정별로 비교하고 특정 기능 조회가 유지되는지도 함께 기록합니다.
동적 가격을 적용하기 전에 필요한 데이터는 무엇인가요?
가격 변화 시점과 요금제 조건은 기본 필드입니다. 계정군은 별도 값으로 남깁니다. AI 에이전트가 동적 가격을 계산하더라도 원본 이벤트와 수동 검토 결과를 연결해야 원인과 조정 결과를 나눠 읽을 수 있습니다.
가격 A/B 테스트로 원인을 확정해도 되나요?
한 번의 실험 결과만으로 원인을 확정하지 않습니다. 가격 A/B 테스트에서 2개 조건의 결제 이탈 지점을 비교하고 조건을 고정한 기능 선택 변화와 함께 읽어야 구매 조건과 선호를 나눌 수 있습니다.
참고한 자료
— Monetai · monetai.io