BASSIP

Growth Analytics

요약

이번 달 성과 ·

분석 단위: Request(문의 기준) · 담당자 필터 없음(문의 단계엔 담당자 데이터가 없어 "통계 → 담당자별 보기"의 사건 기준으로 확인) · 기간을 직접 바꿔가며 분석하려면 "통계" 또는 "전환 비교"를 이용하세요.

현재 파이프라인 · 이번 달 문의 중 진행 중인 것 기준

최근 3개월 핵심 지표

월별 문의 · 계약 · 전환율

첫 연락 속도에 따른 계약률

문의 → 계약 중앙 소요일

미전환 Top 3

주간 보고서

월요일~일요일 기준

유입채널 · IP 유형별 전환 성과 선택 기간 반응

유입 채널별 문의 · 계약 · 전환율

IP 유형별 문의 · 계약 · 전환율

추이 · 소요일 선택 기간 반응

기간별 추이

문의 건수 → 종료 단계 도달률

구간 시작 건수

종료 단계 도달률(%)

구간 소요일수 분포

막대에 마우스를 올리면 건수가 표시됩니다

퍼널 현재 시점 고정

문의 대비 마일스톤별 기록 현황

각 마일스톤을 문의 전체 대비 독립 집계(순차 필터링 아님) · 전체 스냅샷

전환 비교

계약 전환 vs 미전환 · 전환된 문의와 미전환된 문의는 무엇이 달랐나?

결과가 확정된 두 그룹만 비교합니다(진행 중 문의 제외) · 기준: 문의 접수일

1. 단계별 전환 파악

왜 문의접수/첫연락/첫견적/계약, 이 4개뿐인가: Bassip 원본 DB에 실제로 시각이 찍혀 있는 지점이 이 4개뿐입니다. "취부콜 필요"·"자료 수신 대기" 같은 칸반 세부 단계는 지금 값(스냅샷)만 있고 "언제 들어왔는지" 이력이 없어서, 그 단계에서 며칠 머물다 전환/미전환됐는지는 계산할 방법이 없습니다(세션 내내 여러 방식으로 확인함). 대신 아래 표는 실제로 있는 3개 구간(접수→연락, 연락→견적, 견적→계약)에서 얼마나 걸렸는지에 따라 최종 계약률이 어떻게 달라지는지를 보여줍니다 — 어떤 단계에서 시간을 끌면 위험한지 여기서 바로 보입니다.

소요시간에 따른 최종 계약률

각 칸 = 그 시간대 안에 첫 연락이 된 건들의 최종 계약률 · 작은 숫자는 표본 건수 · 표본 10건 미만은 생략

원래 "연락→견적"·"견적→계약" 구간도 넣었었는데, 실제로 세어보니 견적(quote_date) 기록이 미전환 1,442건 중 3건뿐이라(정식 견적서를 거의 안 씀) 그 두 구간은 계약군 쪽에만 표본이 쏠려 무의미하게 90~100%로만 나왔습니다. 그래서 양쪽 그룹 모두 기록이 충분한 이 구간만 남겼습니다.

계약군 vs 미전환군 단계 비교

큰 숫자: 단계 도달률 · 작은 숫자: 문의 접수 후 해당 단계까지 중앙 소요일

첫 연락이 늦으면 계약률이 떨어지나?

첫 연락 속도 비교(시간 단위 세분화)

2. 소재별 전환 파악

원본에 식별된 Instagram·Facebook·Google·Naver·GPT 등 유입 소재·플랫폼별 전환 성과를 비교합니다.

유입 소재·플랫폼별 전환 성과

막대: 확정 전환율 · 함께 보기: 견적 도달률

광고 소재(캠페인/카피)별 전환 성과

utm_term(없으면 utm_content) 기준 · 확정 10건 이상 소재만 표시

3. 채널별 리드 Quality 파악

전환율·견적 도달률·초기 연락 속도로 유입 리드의 질을 비교합니다.

채널·플랫폼 성과

전환율 · 견적 도달률 · 초기 연락 속도만 비교

전환율 = 계약 ÷ (계약 + 미전환). 진행 중은 전환율 분모에서 제외합니다. 구매의사 직접 기록이 없어 견적 도달률을 관심도 대체지표로 사용합니다.

기타 참고 분석 핵심 3개 분석 외

IP 유형별 전환 비교

문의 요일 · 시간대 비교

요일

업무시간 내/외 (09~18시)

계약 vs 미전환 상세 소요일수 분포

수임 완료 (계약 전환)

소요일수 분포

수임 안됨 (미전환)

소요일수 분포

미전환 사유

분석 기준 · 데이터 계산 방식

갱신 상태: 이 대시보드는 Neon(원본 DB)을 Supabase로 매일 08:00(KST) 자동 동기화하도록 설계돼 있지만(.github/workflows/sync-data.yml), 실제로는 동작하지 않고 있는 것으로 확인됐습니다 — Neon 원본은 계속 늘어나는데(확인 시점 기준 Request 3,188건) 이 화면은 마지막 수동 갱신 시점(3,145건)에 멈춰 있습니다. GitHub Actions 설정(Secrets 등록 여부)을 다시 점검해야 합니다.
"분석 단위"를 반드시 확인하세요. 요청(Request) 단위는 문의 전체가 모수라 문의→계약 영업 전환 분석에 적합하고, 사건(Case) 단위는 실제로 계약 이후 사건이 개설된 건만 대상이라 계약 이후 진행 단계(수임~등록) 분석에만 써야 합니다. 두 단위를 같은 화면에서 같은 의미로 섞으면 전환율이 왜곡됩니다.
진행 중 문의의 "현재 단계 N일째" 표시는 근사치입니다. request(문의)엔 case처럼 단계별 진입 시각을 남기는 이력 테이블이 없어서(stage_dwell_days 컬럼도 전 건 0으로 비어있음), 대신 레코드 마지막 수정 시각(stage_updated_at = requests.updated_at)을 기준으로 계산합니다. 실무상 레코드가 수정되는 주된 이유가 단계 변경이라 문의 접수일 기준보다는 실제 체류기간에 훨씬 가깝지만, 일괄 마이그레이션/배치 작업이 스친 레코드는 실제로는 오래 정체됐는데도 "최근 갱신됨"으로 짧게 보일 수 있습니다.
사건(Case) 단위의 세부 진행 단계(명세서 작성 중, 초안 송부, OA 대응 등)는 case_stage_histories 로그에서 각 단계에 처음 도달한 시각을 뽑은 것입니다. 로그가 없는 사건은 해당 단계가 "미도달"로 잡힐 수 있습니다.
결제(입금) 데이터는 아직 포함되지 않았습니다. contract_payments 테이블에 RLS 정책이 없어 현재 0건으로 보입니다 — "첫 계약 체결"을 결제의 근접 지표로 대신 쓰고 있습니다.
"첫 연락"은 communications.direction = 'outbound' 기록 기준입니다. 이 기록이 없는 건이 전체의 상당수라, 전화 상담 등이 누락 기록됐을 가능성이 있습니다 — 실제로 "연락 기록 없음" 그룹의 계약전환율이 다른 구간보다 높게 나오는 경우가 있어, 미기록이 곧 미연락을 의미하지 않을 수 있습니다.
담당자별 분석은 계약 이후 사건(Case) 기준으로만 가능합니다. 문의(Request) 단계에는 담당자 데이터가 아예 기록되어 있지 않습니다(전체 3,188건 중 0건).
미전환 사유는 requests.unqualified_reason 기준입니다. 미전환 건의 상당수는 사유 자체가 기록돼 있지 않아(사유 미기록으로 표시) 실제 비중과 다를 수 있습니다.