(프로덕트) 문화(자아 표현에 자부심을 지닌 사람들, 반항의 아이콘 등)를 판매하는 패션 브랜드임
우리의 웹 서비스 매출은 자사 제품 판매를 통해 이루어지는가? 웹서비스의 매출은 자사 제품 판매를 통해 이루어짐 (닥터 마틴의 자사 쇼핑몰임)
기획자는 어떠한 의도로 해당 웹 페이지를 주어진 화면처럼 구성한 것일까? (e.g. 수익성, 광고성 등) 젊은 이미지 및 래퍼의 이미지가 사용되었으며, 동적인 느낌 및 반항아 이미지를 가져감
그리고 기획자의 의도를 개발자가 기술적으로 구현하기 위해 분석해야할 요소는 무엇 무엇이 있는가? (e.g. Filtering, Pagination, Sorting, 모달 창, 팝업 창 구현 등)
전체 제품을 노출하는 리스트 페이지와 상세 페이지가 담는 제품 데이터의 수와 그 양은 어떤 차이가 있는가?
전체페이지는 전체 상품을 호출하며, 고객이 전체 구도를 확인 할 수 있어야 함
상세페이지는 상품에 대한 세부 데이터를 호출해야하며, 리뷰, 소재 등이 표시되어야 함
우리의 웹 서비스를 경유하여 판매하는 제품은 어떻게 정의할 수 있을까?
닥터마틴스가 뭘 팔까?
닥터마틴스 여자 남자 부츠에 어울리는 옷이 한정됨.
자아표현에 자부심이 사는 사람.
개성 표현
홍대 스타일
반항적인 태도,
그래서 우리가 내린 결론.
배민은 '시간'은 판매한다.
닥터마틴스는 '문화' / '컬쳐'를 판매한다.
메인페이지도, 그루비룸, 미란이 ==> 문화의 아이콘을 주로 가져가는 느낌.
기획자의 의도를 개발자가 기술적으로 구현하기 위해 분석해야할 요소는 무엇 무엇이 있는가? (e.g. Filtering, Pagination, Sorting, 모달 창, 팝업 창 구현 등)
Filtering, Pagination는 해보는 게 좋다. --> Sorting은 실무에서 많이 하고 --> 데이터베이스에서 보내주면, 프론트에서 출력
Filtering
- 상품: 최신순으로, where
- 가격 : 3만원 이하면, where이하,
[실제 구현할 땐]
필터링: 평점순. 리뷰많은 순, 낮은 가격순 중에 선택해서 이런 걸로 진행
pagination
- 페이지 매기기, 1,2,3 --> 닥터마틴스는 더보기인데, 10개씩해서 묶어주기
- 더보기를 하더라도, 20 개씩 묶어줘야함.
프론트만 하는게 아니라,
백엔드도 데이터를 잘라서 줘야함. 요청한 수만큼 query들어가는.
>> 전체 제품을 노출하는 리스트 페이지(카테고리에 나열된 페이지) vs. 상세 페이지가 담는 제품 데이터의 수(사이즈 정보, 리뷰, 하나의 상품에 대한 데이터)
백엔드 질문으로 보여서, 데이터로 접근해보기로 했다.
전체 제품을 노출하는 리스트 페이지(카테고리에 나열된 페이지) vs.
--> 모든 구두를 보여주는데/ 가격, 사진만 보여주는
데이터 테이블로 보면, colum이 적고
상세 페이지가 담는 제품 데이터의 수(사이즈 정보, 리뷰, 하나의 상품에 대한 데이터)
-->하나의 구두를 보여주는데/ column이 옆으로 쫙 나오는
<우리 진행 방식>
와꾸는 만들어놓고, 아직 기능 구현 안되면 아직 안 됐다고, 마우스 올리면 나오게 해도 되는
주문
자사 제품을 주문하는 절차를 웹 서비스 내에서 기술적으로 구현합니다.
자사 제품에 대한 구매 욕구가 주문까지 이어질 수 있게 개발자가 기술적으로 구현 해야 할 요소는 무엇인가?
(기술요소) 절차 간편 화가 필요하며, 홈페이지 속도 개선은 필수적으로 필요함 (프로덕트) 고객에게 유익한 정보임을 강조해야 함 배송비나 배송기간을 명확히 보여주어야 함 정확한 정보, 환불에 대한 정보를 명확히 명시해야함 결제정보를 자동으로 저장해서, 재구매 시 간편결제 서비스를 제공해야함
대부분의 사이트가 보유하고 있는 장바구니 기능은 필수일까 아니면 선택일까?
고객이 개별로 상품 구매/결제하지 않으므로, 장바구니 기능은 필수적이라 생각함
생필품은 재 구매율이 높으므로, 기존 고객 장바구니 데이터는 지속 보관해야 함
장바구니에 개별 품목을 선택하여 삭제할 수 있는 부분은 왜 존재하는 것이고, 기술적으로 어떻게 구현할 수 있을까?
소비자 측면의 잠재적 불편 요소를 제거하기 위함
일부 상품을 장바구니에서 삭제하기 위해 모든 장바구니 데이터 삭제 → 불편함 초래
프론트엔드에서 장바구니 관련 데이터 처리 요청을 받음 (장바구니 데이터를 1차 가공) → 백엔드에서는 최종 처리만 반영함 (고객 페이지 이탈 시, 변경 데이터는 반영하지 않음)
프론트엔드에서 장바구니 데이터를 가져온 상태에서 유저 액션에 따라 (예: 장바구니에서 삭제) 데이터를 1차 가공 한 후 백엔드에 실제로 전송하는 것은 버튼 하나 (구매하기라던지)에 의해서만 발생, 페이지를 이탈할 경우 변경한 데이터는 저장되지 않음
주문의 절차가 까다롭게 되면 우리의 매출 수익성에 어떠한 영향을 줄까?
주문 과정이 길어질 경우,
카드번호 배송지가 저장되지가 않으면 길어지면, 고객들이 해야되는게 많아지면 사기 싫어짐 카드 번호를 매번 일일히 입력해야된다던가
자주 사는 상품은 상세페이지를 거치지않고 바로 결제하는것이 좋다는 것
해당 사이트는 개별 상품에 대한 구매가 가능한가? 아니면 전체/복수의 상품에 대한 구매가 가능한가?
해당 사이트는 개별 상품에 대한 구매 및 복수 상품에 대한 구매가 가능함.
주문의 절차 중 다른 제품을 추천하는 알고리즘은 왜 존재하는 것이고, 어떻게 구현할 수 있을까?
추천해주는 방식이 다른 두가지가 있음
한가지가 내가 구매를 했을때 나의 구매행동 패턴을 가지고 제시해야함(내정보를 이용해서 제시함)
다른 두가지 다른 사람들의 구매 패턴을 보고 매칭시켜서 추천을 하는 것 (빈도수와 관련)
AI 추천은 구매 패턴을 학습한 다음 제시하는 방식임
💡 [내용분석]
[공통]
(필수 구현 사항) 장바구니 기능을 구현해야함
(필수 구현 사항) 주문 페이지에서 고객에게 배송비, 배송기간, 환불 정책 등의 정보를 명확하게 제공해야 함
(필수 구현 사항) 개별 상품 구매와 복수 상품 구매를 모두 지원해야 함
(필수 구현 사항) 주문 절차를 간소화하여 고객의 구매욕구를 촉진해야 함
다양한 구매 방법 지원: 개별 상품 구매와 복수 상품 구매를 모두 지원해야 합니다.
주문 절차 간소화: 주문 절차를 간소화하여 고객의 구매욕구를 촉진해야 합니다.
데이터 보안: 고객의 개인정보 및 결제 정보를 안전하게 관리하고 보안을 유지해야 합니다.
AI 추천 시스템: 추천 시스템을 위해 AI를 활용하여 고객에게 적절한 상품을 제안해야 합니다.
고객 피드백 수집: 주문 프로세스를 개선하기 위해 고객 피드백을 수집하고 이를 바탕으로 개선 작업을 진행해야 합니다. 주문 절차를 간소화하여 고객의 구매욕구를 촉진해야 합니다.
(필수 구현 사항) 고객의 개인정보 및 결제 정보를 안전하게 관리하고 보안을 유지해야 함
(필수 구현 사항) 추천 시스템을 위해 AI를 활용하여 고객에게 적절한 상품을 제안해야 함
(선택 구현 사항) 주문 프로세스를 개선하기 위해 고객 피드백을 수집하고 이를 바탕으로 개선 작업을 진행해야 함
[FrontEnd]
(필수 구현 사항) 복수의 상품을 구매할 수 있도록, 장바구니 기능을 구현해야함
(필수 구현 사항) 주문 프로세스를 간소화 해야함
주문 페이지에서 배송비, 배송기간, 정확한 상품 정보, 환불 정책 등을 명확하게 표시하여 고객에게 유용한 정보를 제공해야 함
결제 정보를 자동으로 저장하여 재구매 시 간편 결제 서비스를 제공해야 함
(필수 구현 사항) 장바구니 기능을 구현해야 함
고객이 여러 상품을 한꺼번에 담아두고 필요에 따라 선택할 수 있도록 기술을 구현해야 함
재구매를 촉진하기 위해 기존 고객의 장바구니 데이터를 유지해야 함
장바구니에서 개별 품목을 선택하여 삭제할 수 있는 기능은 사용자 편의를 높이기 위한 것이며, 프론트엔드에서 이를 구현할 때, 백엔드로 해당 요청을 전송하여 데이터를 처리해야 함
(선택 구현 사항) 추천 알고리즘 기능을 구현 해야 함
사용자의 구매 패턴을 분석하거나 다른 사용자의 패턴을 활용하여 추천을 제공해야 함
[BackEnd]
(필수 구현 사항) 복수의 구매 요청에 대한 응답을 해야 함
(선택 구현 사항) AI를 구현해야함
(필수 구현 사항) 웹 서비스의 속도를 향상을 염두에 두고 기술 구현을 해야함
(필수 구현 사항) 장바구니 데이터 관리 및 기존 고객의 장바구니 정보를 지속적으로 보관해야함
Frontend에서 요청된 개별 품목 삭제를 백엔드에서 처리하여 장바구니 데이터를 업데이트해야 함
(선택 구현 사항) Backend에서는 추천 알고리즘을 구현하고, 사용자의 구매 패턴을 분석하여 추천 상품을 제공해야 함
(선택 구현 사항) 재구매 시 간편 결제 서비스를 위한 정보를 관리해야 함
<고객에게 유용한 정보를 보여준다. >
할인가, 할인퍼센트
가격 정보,
배송비, 배송기간 제대로 보여줘도,
사고는 싶은데 얼마나 얼리는데,
명시는 해줘야 함.
차라리, 1주일 걸린다고 말해주는 게 나음 (너그러워지게 만드는)
엘리베이터가 늦어요, 처럼, 왜 이렇게 배송이 늦어요? 하면, "택배사의 사정으로 인해"
본인들은 노력하느거처럼 보이고,
배민의 배달이 늦어요 -> 지도 위치
환불 정보 -> 정확히 정보 명시에 동의함 "내가 환불 가능하구나 하고 더 구매하게 됨"
한달 이용기
자사 제품을 주문하는 절차를 웹 서비스 내에서 기술적으로 구현합니다.
쿠팡 보면 카드 한번 저장해놓으면, 버튼으로 바로 결제 됨. --> 고객의 실수로, 더 생각하고 싶었는데, 사게 되는
쿠페이/ 결제 정보 자동 저장 하는 것 -->
카드 번호 맨날 쳐아 하고.
대부분의 사이트가 보유하고 있는 장바구니 기능은 필수일까 아니면 선택일까?
- 필수
- 마켓컬리의 경우 장보는 오프라인의 느낌 준다
- 비교하고 싶을 떄 담음 -->
- 상세페이지에서 다시 찾기도 힘들고
- 생필품, 자주 사는 것들 구매했더라도 다시 담아둠 (쿠팡이츠)
- 장보기리스트: 잊지 않음: 내가 계란을 사야되는구나 하고 아는 -=> 살 거 남는 거 이상의 기능을 한다
+ 장바구니가 계속 저장되어있으면, 당시에 안 사도 나중에 들어왔을 때, 잊고 있다가 또 사게 됨
장바구니에 개별 품목을 선택하여 삭제할 수 있는 부분은
왜 존재하는 것이고, 기술적으로 어떻게 구현할 수 있을까?
- 당연한 거 아닌가?
- 실제 마트에서 결제 시, "이거 빼야해요"
- 기술적으로 어떻게 구현?
1) 장바구니 데이터베이스가 아닌, temp 데이터베이스 (일시적) --> 장바구니에 뺏다 넣었다 하면 서버 다운되니, 데이터베이스에 가긴 하는데, 텀을 준다. 유저 행동 다 끝나고 나서 5초 뒤에 저장한다던가, 의미 있고 저장할 때만.select,
실제 결제할 때만 DB에서 가져오는 방식 (장바구니 담을 떄마다 실제 데이터베이스에 담는게 아님)
2)상품의 url 정도만 가져온다고만 하고, url에 해당하는 db를 가져온다.
주문의 절차가 까다롭게 되면, 우리의 매출 수익성에 어떠한 영향을 줄까?
주문 절차가 까다롭다
--> 카드번호 일일히 쓰거나, 배송지 저장 안 된거,
다른 사이트에도 연동해서 구매하도록
고객이 하는게 길어지면, 하기 싫어진다.
--> 굳이 아는 제품이면, 자주 사는 상품이면, 상세페이지 거치기 않고 바로 결제하면 좋다
해당 사이트는 개별 상품에 대한 구매가 가능한가? 아니면 전체/복수의 상품에 대한 구매가 가능한가?
당연히 가능
주문의 절차 중 다른 제품을 추천하는 알고리즘은 왜 존재하는 것이고, 어떻게 구현할 수 있을까?
- 구현방식 1) 닥터 마틴스에는 없음 --> 어울리는거 다 보여주는 거 (사이트 자체의 연관 짓기--> 고객 유저 정보 상관 없음)
