Airbnb 는 머신러닝을 이용하여 어떻게 호스트 선호도를 알 수 있을까?

딥벨리데이션
8 min readMar 3, 2017

--

들어가기에 앞서…

Airbnb는 게스트와 호스트의 연결해주는 서비스입니다. 게스트가 원하는 숙소를 찾고 호스트에게 연락을 한 후, 호스트가 동의를 하면 계약이 이루어지는 방식입니다.

여기서 중요한 포인트는 Airbnb의 경우 전형적인 양면시장의 서비스이기 때문에, 게스트와 호스트 쌍방의 의지가 있어야 계약이 성사되는 구조라는 사실이죠!

아래의 글은 Airbnb의 데이터 과학자 Bar Ifrach 이 자사 추천 시스템에 활용한 머신러닝 일화를 소개하는 내용을 이해하기 쉽게 의역한 내용입니다. 원본은 Airbnb 엔지니어링 블로그에 게재되어 있습니다.

“2012년도의 일입니다. 제 친구는 당시 가족을 만나기위해 2주간 집을 비우게 되었습니다. 집을 비우는 동안 Airbnb를 통해 하루라도 공석이 생기지 않도록 게스트를 받고 싶었고, 이에따라 게스트를 선별했습니다. ”

저는 2년 뒤 Airbnb 데이터 과학자로 입사하였고, 당시 그 친구의 고민들을 종합해 어떠한 요소들이 호스트 수락을 가능케 하고, Airbnb는 어떠한 정보를 활용하여 게스트 대 호스트 매칭 성사율을 높일 수 있는 궁금했습니다.

소규모로 시작하였던 프로젝트가 이제는 호스트의 과거 행동을 기반으로 현재의 선호도를 파악하는 머신러닝 모델으로 거듭나게 되었습니다. 현재 Airbnb의 검색엔진은 사용자의 검색 요청시 사용자의 데이터를 이용하여 예약성사가 가장 잘 이루어질 수 있는 숙소를 먼저 보여줍니다. 또한 A/B 테스팅을 통해 새로운 머신러닝 모델이 3.75%의 예약 성사율을 증가시킨다는것을 확인하였습니다. 그렇다면, 똑똑한 Airbnb의 검색 모델이 어떻게 이루어 졌는지 살펴보겠습니다.

무엇이 호스트 승낙에 중요한 역할을 할까?

그의 첫 연구는 위에서 언급한 일화처럼 숙소 예약률을 극대화 하고 싶어하는 호스트들에 대한 분석이였습니다. 모든 예약은 아래 달력에서 보여지듯이, 4월 5일 ~ 10일과 같이 표시가 됩니다. 회색으로 표시된 날들은 예약이 불가능한 날들이고, 예약이 성사되면 아래 보이는 것처럼 “Checkin Gap”, “Request”, “Checkout Gap”으로 표시가 됩니다. “Checkin Gap”과 “Checkout Gap” 은 숙박이 확정되고 남은 날들이며, “Request”는 예약된 숙박 일정입니다.

일정을 가득 채우고 싶은 호스트들은 당연히 이러한 공백일을 피하려고 할것입니다. 호스트들의 게스트 수락률과 공백일 간의 관계를 보았을때, 호스트들은 공백일을 되도록 피한다는 것을 볼 수 있었습니다. 아래 그래프에서 보이듯이 호스트들은 이러한 공백을 최소화하려고 합니다.

하지만 모든 호스트가 숙박확정일 사이의 격차를 최소화하려고 할까요? 일부 호스트들은 가끔 예약을 원하는 사람들이 있을 것입니다. 또한, 어쩌면 큰 시장에 속해있는 호스트들과 작은 시장의 호스트들의 성향도 가지각색일 수 있겠죠?

맞습니다. 큰 시장에 속해있는 호스트들과 작은 시장에 속해있는 호스트들의 성향은 달랐습니다. 큰 시장에 속해있는 호스트들의 경우 공백일에 더욱 민감하게 반응하였습니다. 공백일이 없는 경우, 공백일이 7일인 경우보다 호스트의 수락률이 6% 가량 높았습니다. 작은 시장의 호스트들은 그 반대였습니다. 호스트들은 예약 간에 공백이 있는 요청을 좋아합니다. 따라서, 시장에 따라 호스트들의 성향이 다른 것을 알 수 있으며, 한 시장 내에서도 성향이 다른 호스트들이 있다는 것을 알 수 있습니다.

호스트의 수락 성향을 다른 예약요청의 특성에 빗대어 보았을때, 비슷한 패턴이 드러났습니다. 평균적으로 Airbnb 호스트들은 약 일주일 전 숙박예약을 하는 게스트들을 선호합니다. 그렇다면 마감에 임박하여 예약하는 게스트들을 선호하는 호스트들도 있을까요?

아래 그림은 호스트들의 선호도를 나타내는 분산 그래프입니다. 호스트들은 평균적으로는 미리 예약하는 게스트를 선호하지만, 일부는 숙박이 마감될 때 예약하는 게스트를 선호하는 것을 볼 수 있습니다. 다른 예약 성향(숙박 인원수, 주말과 주중 예약 등)으로 그린 분포를 보았을 때도 아래와 같은 동향을 보입니다.

만약 검색결과가 예약 성사율이 높은 호스트들 순으로 보여진다면, 우리는 호스트와 게스트 모두의 만족도를 높일 수 있습니다. 게스트에만 최적화된 추천모델이 아닌 호스트의 성향도 같이 융합된 검색추천이 고객 만족에 큰 역할을 합니다.

호스트 선호도를 어떻게 측정할까?

위 연구 결과에 힘입어 그는 다른 데이터 과학자 및 엔지니어들과 힘을 합쳐서 개인 맞춤형 검색 엔진을 만들었습니다. 그는 호스트의 요청 승인 및 거부 결정을 체크인 날짜, 체크아웃 날짜, 고객 수 등과 같은 특성과 연결했고, 그렇게 만들어진 호스트 선호 모델을 기존에 존재하던 게스트를 추천해주던 모델에 추가함으로써 더욱 정확한 연결이 이루어지기를 희망하였습니다.

언뜻 보면 이러한 상황에는 협업 필터링을 (collaborative filtering) 적용해야 하는 사례 같아 보일 수도 있습니다. (협업 필터링을 이용한 추천이란 같은 성향의 사람끼리 묶어, 공통된 추천을 하는 거에요. 예를 들어, 저와 제 친구의 음악 취향이 비슷하다면, 같은 추천이 저와 제 친구 모두에게 유효한 것 처럼요. 협업 필터링은 다음화에 구체적으로 설명해 드릴게요!)

하지만 다음의 두 이유 때문에 협업 필터링이 어렵습니다.

  1. 동일한 형태의 예약은 존재하기 힘듭니다. 모든 예약은 다른 고객이 하고, 모든 고객은 각기 다른 변수를 가지기 마련이니까요. 이러한 현상은 예약 성공 여부에 큰 변수가 되고 불확실성을 증가시킵니다. 이러한 불확실성으로 인해 비슷한 성향의 군집이 어렵습니다.
  2. 호스트 개개인의 변덕도 변수로 작용합니다. 같은 조건의 요청을 같은 날에 거절과 수락 모두 할 수 있는 것 처럼요. 이러한 경우, 호스트의 성향을 파악하기가 까다로워집니다.

위 두 조건을 고려하면서, 우리는 이 문제를 협업 필터링 적용 문제와 비슷한 방향으로 접근했습니다. 우리는 게스트와 호스트의 상호 작용에서 오는 불확실성을 줄이기 위해 해당 예약에 대한 다양한 데이터를 활용했습니다. 이를위해, 한 요청에 포함된 여행기간, 고객 수 등의 복합적인 요소의 결합 대신, 특정 요청의 특성 각각에 대한 호스트의 평균적인 반응을 고려했습니다. (여행기간 + 고객 수 = 호스트 반응은? 같은 방식 대신, (긴/짧은) 여행기간 = 호스트 반응은? (많은/적은) 고객 수 = 호스트 반응은?)

우리는 요청의 특성(기간, 고객 수 등)에 따라서 호스트의 평균적인 수락률을 산출했습니다. 이러한 방법을 통해서, 과거에 발생하였던 “변덕”과 “잡음”을 줄 일 수 있었습니다. 하지만 호스트의 데이터 부족으로 인하여, 요청 특성마다 약 26%의 호스트의 수락률을 산출해낼 수 없었습니다. 이런 경우를 처리하기 위하여, 같은 지역의 다른 호스트들의 수락률의 중앙값을 이용하여 빈 데이터를 임의로 채워 넣었습니다.

그리하여 호스트마다 요청 특성별 수락률과 지리적 요소, 호스트 개인의 특성을 이용한 로지스틱 회귀법을 (logistic regression) 사용하여 그 호스트의 전체적인 수락률을 예측하였습니다. (로지스틱 회귀법이란 여러 가지 변수를 이용하여 호스트의 수략률을 계산하는 방법인데요, 이 컨셉에 대해서는 다음에 더 자세히 소개하도록 하겠습니다.)

모델 실험

우리가 만든 새로운 모델을 실험해 보기 위하여, Airbnb 웹사이트에 기존에 존재하던 예약 알고리즘에 새로 만든 모델을 추가로 적용했습니다. 실험군에 속한 고객이 호스트를 찾을 때 해당 알고리즘을 통해 고객이 원하는 추천 호스트 목록을 보여줍니다.

결과적으로는 이 모델을 적용 한 후 매칭 성공률이 약 3.75% 상승하는것을 확인할 수 있었습니다.

이후 약간의 수정과 조율을 통하여 우리는 매칭 성공률을 1%정도 더 향상시킬 수 있었습니다.

결론

첫째로, 이 프로젝트는 예약같은 양면의 고객이 존재하는 상황에서는 맞춤형 서비스가 판매자와 구매자 모두에게 혜택을 줄 수 있는 것을 밝혀냈습니다.

또한, 때로는 상황별로 맞춤형 모델을 만들어야 한다는 것을 깨달았습니다. 상황을 진단한 후, 협업 필터링 알고리즘을 변경 / 적용시킨 것 처럼요.

마지막으로 Spencer de Mars 와 Lukasz Dziurzynski 없이는 이번 프로젝트는 성공할 수 없었을 것입니다. 둘에게 감사를 표합니다.

--

--