pile·
DB / 데이터·우아한형제들우아한형제들·

한 번 성공하니 다음도 쉬울 줄 알았다: 최소주문금액바 4번의 A/B실험

배달의민족 퀵커머스에서 최소주문금액 달성 여부를 탐색 화면에 노출하는 기능을 2024년 10월부터 2026년 5월까지 네 차례 실험한 기록이다. 1차는 명확한 성공이었지만 2차에서 평균주문금액이 오히려 하락했고, 3·4차는 메인 지표가 움직이지 않았다. 실패한 실험에서 보조 지표를 읽어 다음 가설로 연결하는 과정을 다룬다.

핵심 포인트
  • Phase 1은 안드로이드·가게홈에만 최소 리소스로 붙여 빠르게 검증했다. 장바구니 이탈률이 줄고 주문전환율이 올라 확대 근거가 됐다.
  • Phase 2 전면 확대에서 이탈률과 전환율은 개선됐지만 평균주문금액이 소폭 하락해 GMV 임팩트가 미미했다. 허들을 정확히 알려주니 딱 그 지점까지만 담은 것이다.
  • 첫 주문 고객은 혜택 문구 클릭률이 올라도 이탈이 함께 늘었고, 멤버십 고객은 클릭이 실제 전환으로 이어졌다. 같은 UI가 세그먼트별로 반대로 작동했다.
  • Phase 3 업셀링 넛지는 메인 지표를 못 움직였는데, 고허들 쿠폰 운영이 부족해 노출 대상자 자체가 극소수였던 것이 원인이었다.
  • Phase 4에서 부족 금액 8천 원 이하에만 추천을 노출한 C그룹의 평균주문금액이 유의미하게 하락해, Phase 3에서 검증 못 한 가설이 반대 방향으로 증명됐다.
상세 정리
  • 문제 정의: 고객이 최소주문금액 달성 여부를 확인하려고 장바구니를 반복해서 열어봐야 했다. 미달성으로 이탈하는 고객을 줄이는 것이 목표였다.
  • Phase 1(2024-10) 설계: 안드로이드만, 가게홈 지면만, 스낵바 형태로 좁게 시작했다. 상황이 갖춰지길 기다리지 않고 작게 빠르게 검증하는 쪽을 택했다.
  • Phase 1 결과: 장바구니 이탈률 감소와 커머스 전체 주문전환율 상승을 확인해 다음 단계의 근거를 얻었다.
  • Phase 2(2025-02) 확대: 모든 탐색 지면과 iOS·안드로이드로 넓혔다. 이탈률과 전환율은 재현됐지만 평균주문금액이 소폭 내려갔다.
  • 천장 효과의 해석: 허들을 명확히 알려주면 사용자가 정확히 그 지점에만 맞춰 담는다. 정보의 정확성이 객단가의 상한선으로 작동한 셈이다.
  • 세그먼트 분화: 첫 주문 고객은 혜택 문구에 반응해 클릭은 늘었지만 실제 전환으로 가지 못하고 이탈도 함께 증가했다. 멤버십 고객은 클릭 후 주문까지 이어졌다.
  • Phase 3(2025-11) 가설: "N원 더 담으면 N원 할인" 업셀링 넛지를 붙이면 전환율과 객단가가 함께 오를 것으로 봤다.
  • Phase 3 구현: 분산돼 있던 혜택 안내를 통합하고, 최소주문금액바는 '현재 상태', 새 서브보드는 '다음 행동 가이드'로 역할을 갈랐다. 장바구니 상태별 혜택 우선순위도 정책화했다.
  • Phase 3 결과와 원인: 전환율·객단가 모두 변화가 없었다. 다만 노출된 사용자에 한정하면 장바구니 사이즈와 전환율이 올랐고, 고허들 쿠폰 운영이 미흡해 모수가 작았던 것이 실패 원인으로 확인됐다.
  • Phase 3의 교훈: 최소주문금액바의 본질은 탐색과 주문 사이의 마찰 제거이고, 객단가 향상은 프로덕트 단독이 아니라 사업·마케팅과 함께 움직여야 한다는 정리다.
  • Phase 4(2026-05) 설계: A(기존), B(부족 금액 무관 항상 추천), C(부족 금액 8천 원 이하에만 추천) 세 그룹으로 나눴다. C안의 기준선은 UT 피드백에서 나왔다.
  • Phase 4 배경 데이터: 이탈 고객의 절반 이상이 최소주문금액 미달성이었고, 대부분 소액 Gap만 채우면 허들을 넘길 수 있었으며, 주문에 성공한 고객은 주로 무료배달 구간을 택했다.
  • Phase 4 결과: 전환율은 움직이지 않았고, B는 객단가를 방어한 반면 C는 유의미하게 하락했다. 이 시점에는 마케팅팀이 고허들 쿠폰을 적극 운영해 데이터가 충분했다.
  • 역방향 검증의 의미: "업셀링 넛지가 객단가를 올린다"는 명제가 C그룹에서 정반대로 나타나며, Phase 3에서 모수 부족으로 확인하지 못한 가설이 뒤늦게 증명됐다.
  • 저자의 결론: 메인 지표 달성 여부만으로 실험을 평가하면 안 되고, 실험의 가치는 거기서 발견한 고객 행동 패턴에 있다는 것이다.
우아한형제들
우아한형제들 블로그
원문은 여기서 이어서 읽을 수 있어요
원문 읽기
읽음 (0)

이 글과 비슷한

  1. DB / 데이터·spotify-engSpotify Engineering·

    데이터 레이크 온라인 포인트 쿼리 인덱싱 — RAP

    Spotify 엔지니어링이 페타바이트 규모 데이터 레이크(GCS)에 저장된 Parquet 파일에서 한 자릿수 밀리초 레이턴시로 포인트 쿼리를 수행하는 RAP(Random Access Parquet) 방식을 공개했다. Trino·BigQuery 같은 분산 SQL 엔진은 단일 행 조회도 스케줄링·플래닝 비용으로 수 초가 걸리지만, RAP는 외부 인덱스로 키→(파일, 행 번호)를 직접 매핑해 의존적 read chain을 병렬화함으로써 이 문제를 해결했다. 기존 KV 스토어(Bigtable)와 달리 GB당 비용이 클라우드 스토리지 read 수준에 불과해 장기 이력 데이터나 롱테일 피처도 인터랙티브 조회 대상이 된다.

    #data-engineering#indexing#data-lake+2
  2. DB / 데이터·여기어때 (GC컴퍼니)여기어때 (GC컴퍼니)·

    데이터 통합— MongoDB 원칙으로 document를 통합하고 동기화를 재설계하다 (3/3)

    여기어때 전시개발팀은 ES 단일 대문서 → MongoDB v1 RDB 1:1 파편화 → v2 도메인 단위 통합이라는 세 차례 구조 전환을 거쳐 전체 동기화 시간을 약 1시간에서 10분으로 단축했다. 이 글은 3부작의 마지막으로, v2 통합 문서 구조에 맞춰 "$set/$unset 필드 단위 부분 갱신 + 이벤트 발행" 기반 동기화를 어떻게 재설계했는지 구체적인 MongoDB 패턴과 함께 설명한다.

    #denormalization#data-sync#mongodb+2
  3. DB / 데이터·pinterest-engPinterest Engineering·

    Pinterest 차세대 DB 수집 프레임워크의 자동화된 스키마 진화

    Pinterest의 CDC 기반 DB 수집 파이프라인은 MySQL에서 Kafka, Flink, Spark, Iceberg를 거치는 다층 구조다. 스키마 변경이 생기면 모든 계층을 동시에 업데이트해야 해 드리프트, 배포 실패, 데이터 불일치가 반복됐다. Pinterest 엔지니어링 팀은 이를 해결하기 위해 가산적 변경만 자동화하는 스키마 진화 프레임워크를 구축하고, PR 기반 롤아웃과 SLA 기반 일관성 모델을 도입했다.

    #data-pipeline#apache-flink#cdc+2