가치의 유형
실제 결제액, 확정 계약액, 예상 매출과 예상 이익을 구분합니다. 같은 ‘value’ 필드라도 뜻이 다르면 서로 비교할 수 없습니다. 계정에서 무엇을 전송하는지 구현과 원본을 확인하고 고객의 개인정보를 가치 라벨에 넣지 않습니다.
가정한 기대값
아래는 산술 구조 예시이며 실제 고객 가치나 예산 목표가 아닙니다. 가정의 불확실성을 별도로 봐야 합니다.
assumed_contract_probability = 0.10
assumed_value_per_contract = 1,000,000 KRW
expected_value_per_inquiry = 0.10 * 1,000,000 = 100,000 KRW
reported_value_type = modeled expectation
not_equal_to = confirmed revenue or guaranteed profit
review_inputs = cohort, sample size, cancellations, cost basis
가정의 원장
자료의 기간과 계약 판단 완료 여부, 취소·중복과 상품 구성을 기록합니다. 가정한 예로 과거 고가 상품 고객의 계약률을 새로운 저가 문의에 그대로 적용하면 값이 과대 추정될 수 있습니다. 숫자를 세분화할수록 충분한 근거가 있는지 확인합니다.
검수 순서
- 전송할 가치의 업무 의미를 고정합니다.
- 확률·금액의 원본과 적용 대상을 대조합니다.
- 경계·0·누락과 통화 처리를 시험합니다.
- 실제 후속 결과와 가정의 차이를 관찰합니다.
가치 변경이 입찰과 자동화에 영향을 줄 수 있다면 권한 있는 담당자와 범위를 확인합니다. 보고서 단가를 좋게 만들기 위해 과거값을 조용히 바꾸지 않습니다. 가치의 버전과 적용일을 남겨 전후를 같은 성과로 합치지 않게 합니다.
완료 기준
누가 읽어도 실제 매출인지 모델값인지 알 수 있어야 합니다. 불확실한 확률에 과도한 정밀도를 붙이지 않고 계산 가능 범위와 미확인 자료를 표시합니다. 실제 계약·매출 원장을 따로 유지하고 모델값이 맞지 않는 결과도 기록해 갱신 근거로 사용합니다.
자주 묻는 질문
- 리드 가치를 높게 넣으면 실적도 좋아 보이나요?
- 보고된 가치가 커질 수 있어도 실제 사업 결과가 늘어난 것은 아닙니다. 운영 목적과 근거 없이 값을 조정해 성과를 꾸미지 않고 정의 변경을 명확히 기록합니다.
- 모든 문의에 같은 가치를 넣어도 되나요?
- 사업 목적과 자료에 따라 판단할 수 있지만 실제 차이를 얼마나 설명하는지 검토해야 합니다. 근거가 부족한 세분화와 정확해 보이는 임의 숫자를 피합니다.
공식 참고자료와 작성 기준
공식 문서는 도구·검색 기능의 근거이며, 위의 점검 순서와 완료 기준은 현랩의 실무 설계 제안입니다. 예시를 실제 고객의 성과나 검색엔진의 보장으로 해석하지 않습니다.