끝났다고 생각한 순간, 일이 다시 시작됐다
쿠폰, 최종혜택가, 그리고 생각보다 컸던 작업 범위와 영향들
도메인 임베딩 프로젝트가 오픈되고, 한동안은 마음이 조금 놓였다.
큰 배포는 끝났고, 이제 연말까지는 비교적 차분하게 갈 수 있겠다는 기대가 있었다.
그러넫 갑자기 올해 말까지는 없을 거라 예상했던 쿠폰 이벤트를 진행한다고 한다.
기존에는...
고객에게 각각 등록된 판매가 / 할인가만 보여주고, 쿠폰 할인은 "쿠폰 할인 50,000원”처럼 별도의 영역으로만 노출되고 있었다.
쿠폰 이벤트를 적극적으로 알리려면, 쿠폰이 반영된 가격 자체를 전면에 보여줄 필요가 있었다.
가격 하나 바꾼다고 끝나지 않았다.
말은 간단했지만, 막상 손을 대보니 생각보다 영향 범위가 컸다. 가격이 노출되는 영역을 전반적으로 다시 점검해야 했다.
우선 가장 많이 노출되는 메인, SRP, PDP를 중심으로, 판매가 / 최종혜택가 / 최종 할인율을 내려주는 구조로 큰 방향을 잡았다.
문제는 그 다음부터였다.
PDP만 봐도 가격이 노출되는 영역이 최소 세 곳이었다.
상단 대표가, 실제 상품 가격 영역, 그리고 최종 CTA 내 금액
각각 기준과 적용 조건이 달랐고, 그럼에도 고객에게는 하나의 ‘가격’으로 인식되기 때문에 싱크를 맞춰야 했다.
SRP는 캐싱으로 또 다른 고민이었다.
트래픽과 데이터 조회가 많은 영역이라 캐싱이 필수인데, 기존에는 판매가 기준으로만 캐싱되고 있었다.
판매가와 최종혜택가는 잘 노출되지만, 필터나 정렬 기준을 적용하는 데에는 한계가 있었다.
여기에 SRP/PDP의 달력 기반 최저가 노출 영역, 그리고 처음엔 고려하지 못했던 예약폼과 마이페이지 > 예약 상세의 금액 싱크 문제까지.
고객에게 바로 노출되지 않는 할인가를 기준으로 실제 예약 로직이 돌아가고 있었기 때문에, 결국 판매가 / 할인가 / 최종혜택가라는 3중 가격 구조로 가격 노출 수정이 필요했다.
방향은 맞지만 완벽하지 않다.
정리하면 이 작업의 배경과 목표는 명확했다.
플랫폼에서 고객에게 쿠폰 이벤트를 효과적으로 전달하기 위해, 쿠폰 할인 금액이 반영된 최종혜택가를 고객에게 직접 노출한다는 것.
즉, 판매가·할인가·최종혜택가 구조는 유지하되, 프론트에는 판매가 / 최종혜택가 / 최종혜택률을 내려주는 방식이었다.
다만 쿠폰 이벤트에 맞춰 다급하게 진행하다보니 한계도 분명했다.
최우선적으론 ‘가격이 전시되는 영역’ 위주로 작업으로, 최종혜택가를 기준으로 기능이 돌아가야 하는 부분들까지는 충분히 커버하지 못했다.
돌이켜보면, 초기 분석을 조금 더 꼼꼼히 했으면 어땠을까 하는 아쉬움도 남는다.
그래도 다시 다음을 준비한다.
운영 배포 이후 쿠폰 이벤트는 오픈했고, 뒤이어 플랫폼 전용 상품도 판매되며 또 다른 이벤트가 이어지고 대박이 터졌다.
임베딩 프로젝트가 끝났으니 연말은 조금 쉬엄쉬엄 갈 수 있겠다고 생각했던 건, 역시나 착각이었다.
끝은 늘 또 다른 시작이었다. 연차를 쓰는 중간에도 QA와 이벤트 이슈를 따라가느라 정신없는 2주를 보냈다.
그럼에도 이런 작업들이 숫자로, 성과로 바로 보인다는 건 분명 큰 위안이다.
