[빵그리의 오븐 추천시스템 구축기]3.사용자 데이터 분석 기반 메인 홈화면 상품 추천

이전 이야기

https://thrcle.tistory.com/7

[빵그리의 오븐 추천 시스템 구축기]2.메인 홈화면 상품 추천을 위한 테스트 설계 과정

 

---

Intro

추천시스템을 구현하는 관점에서 생각해보면,

추천시스템이란 어떤 유저에게 어떤 상품을 어떤 순서로 정렬할 것인가의 문제입니다.
 
유저데이터 부족&콜드스타트 문제의 상황에서 개인화 추천시스템을 구축한다는 것은 아직 먼 이야기일 것입니다.
이에 단계별 목표를 정하는 것이 중요하다고 생각되었고
빵그리의 오븐 추천시스템을 2가지 관점에서 나누어 구축하였습니다.

1. [메인 홈화면]사용자 분석을 통한 세그먼트별 인기상품 추천
2. [상품 상세페이지] 롱테일 현상 방지를 위한 상품 메타데이터 기반 유사상품 추천

 

이번 포스팅에서는 1번 [메인 홈화면]사용자 분석을 통한 세그먼트별 인기상품 추천에 대해 포스팅하겠습니다

---

기존 추천 방식

• 프로젝트에 참여하기 전, 기존 추천정렬 방식은 세그먼트별 찜, 조회수, 상품별 태그정보(비건여부, 글루텐프리여부 등) 등을 고려하여 score값을 매기고, score값을 내림차순으로 정렬하여 조회하는 방식이었습니다. 
• 이때 세그먼트(preference_type)의 갯수는 총 10가지이고  기준은 방문목적 선택화면에서의 조합의 수입니다.(4C2) 

검증 및 세그먼트 분류 과정

• 이러한 접근은 '10가지의 preference_type별로 선호하는 아이템이 달라진다'가 전제되어야 했고 이에 대한 검증과정이 필요했습니다. 
• 이에 우선 사용자 특성(성별, 나이, 상품  찜 갯수 등)을 바탕으로 군집화를 해보았고 elbow method를로 확인했을 때, 10개가 아닌 3-4개의 세그먼트로 재구성하는 것이 적절하다고 판단하였습니다.
• 서비스의 관점에서 고려해보았을 때, 빵그리의 오븐에서 말하는 건강디저트란, 나에게 맞지 않는 성분이 들어가지 않고 건강에 대한 부담을 최소화한 디저트를 의미하기 때문에, 세그먼트를 나눌 때 '건강타입'도 중요한 요소로 작용했습니다.

• 서비스의 관점에서 고려해보았을 때, 빵그리의 오븐에서 말하는 건강디저트란, 나에게 맞지 않는 성분이 들어가지 않고 건강에 대한 부담을 최소화한 디저트를 의미하기 때문에, 세그먼트를 나눌 때 '건강타입'도 중요한 요소로 작용했습니다.
• 콜드스타트 문제 해결을 위해 기획한 사전정보수집문항기을 기반으로 비율차이가 2배 이상 나는 경우를 크게 세그먼트의 기준으로 우선 고려하였습니다.
• 사전정보수집문항은 크게  방문목적, 건강정보, 기피재료의 관점으로 분류하였습니다.

방문목적

• 방문 목적의 경우는 다이어트&근성장을 선택한 유저의 비율이 전체의 절반가량되었습니다.

 

• 다이어트와 근성장 그룹간의 선호 아이템의 차이가 있을까?
  • 아이템 태그정보(고단백, 저당 등)를 기반으로 확인했을 때 다이어트를 선택한 유저와 근성장을 선택한 유저 사이의 유의미한 차이가 있다고 보이지 않아서 두 그룹을 하나의 세그먼트로 통일하였습니다. 

 

건강정보

 

기피재료

마지막으로 기피재료의 경우는 사용자마다 선택할 수 있는 옵션이 다양하여 하나의 세그먼트 기준으로 활용하는 것이 아닌, 후처리 제외로직으로 사용하였습니다. 

* 기피재료 선정기준은 식품의약품안전처가 선정한 알레르기 유발물질 중 디저트에 주로 사용될 수 있는 재료로 구성하였습니다.

---

세그먼트 분류결과

• 근성장&다이어트 / 유당불내증 / 근성장or다이어트&유당불내증 / 일반사용자
  • 근성장 & 다이어트: 건강정보 입력 페이지에서 근성장 또는 다이어트를 선택한 사용자
  • 유당 불내증: 건강정보 입력 페이지에서 유당불내증 또는 기피 재료로 우유 선택 또는 유제품 선택한 자
  • 근성장 or 다이어트 & 유당불내증 : 1,2 중복 해당 사용자
  • 일반 사용자: 1,2,3에 해당하지 않는 일반 사용자

 

---

추천 정렬 기준

• 각 세그먼트별 사용자의 선호도가 높았던 아이템 순으로 정렬할 때, 활용가능 정보는 상품 클릭 정보, 찜데이터였습니다.
• 실제 반영한 정렬 기준은 세그먼트별 아이템 찜 내림차순 정렬이었습니다.
  • Explicit data : 고객이 호불호를 직접적으로 표현한 데이터 (ex. 리뷰,좋아요 등)
  • Implicit data : 고객이 호불호를 간접적으로 표현한 데이터 (ex. 검색 기록, 구매내역 등)
    • Implicit data의 경우 현재 단계에서 사용자의 행동에 대한 의도를 잘못 해석할 가능성이 있다고 생각하여 ver1에서는 클릭데이터를 활용하지 않았습니다.
• 마지막으로 품절 여부 검토(스케줄러를 통한 상품 페이지별 판매중지 태그 확인 후 업데이트)를 통해 판매 중지되지않은 상품만 사용자에게 추천될 수 있도록 구현하였습니다. 
• 보통 추천상품의 경우 전체상품 갯수의 20% 이하를 추천하지만, 전체 상품이 211개&추천 초기 상황임을 고려하여, 메인 홈화면에 추천되는 상품은 전체 상품 갯수 중 1/3개 이내만 노출될 수 있도록 구현하였습니다.

---

정리

요약 및 정리해보자면,
홈화면에서는 유저데이터 분석을 통해 세그먼트를 분류하고 후처리(사용자별 기피재료 제외 및 품절된 상품 제외)를 통해 최종적으로 찜 카운트가 높은 순으로 아이템을 추천하는 방식으로 구현하였습니다.

---

서비스 적용

• 로그인을 하지 않은 경우, 인기상품순서대로 정렬됩니다.
• 사용자가 로그인을 한 경우, 사용자 정보를 활용하여 추천 상품이 정렬됩니다.

---

한계 및 추후 계획

한계

- 유저데이터 부족으로 인한 접근 방식의 한계가 있었습니다.
- 네이버 스마트 스토어에서 크롤링 및 전처리를 과정에서 맛별 단위로 DB를 구축하는 어려움이 있었습니다. 이에  추천단위를 맛별이 아닌 상품 단위로 설정하였습니다. 

추후계획

- 우선은 유저데이터를 확보하는 것이 가장 우선적인 문제 - 근본적으로는 서비스 자체에 대한 고민 및 개선이 필요합니다.
- score 산출 로직 고도화 : 더 다양한 로그데이터를 수집 및 호감도에 미치는 영향도에 대한 분석 및 정의가 필요합니다.

---

다음 포스팅에서는 <[상품 상세페이지] 롱테일 현상 방지를 위한 상품 메타데이터 기반 유사상품 추천>에 대해 다루도록 하겠습니다.

*좋았던 점/아쉬운 점/기타 피드백 모두 환영합니다!