Три недели назад мы писали о том, каким образом пользователи и владельцы жилья могут эффективнее использовать поиск на нашем сайте. Сегодня мы хотим рассказать об алгоритмах, на которых базируется наша поисковая система.
Пост подготовлен по материалам выступления Максима Чаркова:
Поиск — это сила паросочетаний. Говоря по существу, здесь мы и пытаемся стыковать запросы наших пользователей с тем, что доступно на рынке.
Сперва хотелось бы сказать пару слов о себе и своих коллегах. Я работаю в поисковой команде. Начал работать в компании я два года назад. До этого был сотрудником Google, где я провел несколько лет, занимаясь всем подряд, от функций поиска до веб-браузеров. Конечно, все то, что я собираюсь представить здесь, не было бы возможным без людей из нашей команды. Search Airbnb — постоянно действующая команда. Наши инженеры работают над проблемами поиска и потока бронирования, включая инфраструктуру, пользовательский интерфейс и т.д. Сфера нашей деятельности также включает в себя разработку оборудования, дизайн, пользовательские исследования, обработку и анализ данных.
Сперва хочу представить проблему поиска на Airbnb и как мы помогаем нашим гостям найти наилучшие позиции. Затем я расскажу о проблеме конверсии бронирования. Вы увидите, что на Airbnb не всегда достаточно позиций, удовлетворяющих всем запросам пользователей. А это представляет собой интересную задачу. Также я скажу пару слов об оценке модификаций. Работая над новыми поисковыми продуктам, очень важно учредить оценочные инструменты и факторы, которые бы давали уверенность в том, что каждое сделанное изменение будет иметь положительные эффект для пользователя.
Airbnb — это глобальная площадка для объявлений. Сегодня в нашей БД более 600 тысяч позиций, 34 000 городов в 192 странах мира. На нашем сайте вы можете найти жилье на любой вкус, от обычных квартир до домиков на деревьях, и даже частных островов.
Здесь вы можете увидеть плотность предлагаемых нами позиций в районе Сан-Франциско. Каждая точка — это соответствующее предложение.
Северная Америка:
Европа также представляет собой плотный рынок.
Азиатско-Тихоокеанский регион быстро набирает обороты.
Нам нужны новые решения для работы в глобальном масштабе, так как у нас есть все это огромное разнообразие локаций и видов предложений.
Давайте обратим внимание на поисковое поведение людей, которые успешно осуществили бронирование на Airbnb. Путешественники тратят много времени на поиск. В среднем каждый из них тратит не менее трех дней с момента первого поискового запроса до завершения бронирования. В течение этого времени они рассматривают приблизительно 20 позиций. Процесс поиска места проживания непрост сам по себе по многим причинам. Выбор места — серьезное решение. Часто люди хотят проконсультироваться с семьей или друзьями, прежде чем сделать окончательный выбор.
В отличие от веб-поиска (до этого я работал именно с ним), вы почти никогда не увидите полную картину поиска, когда пользователь просто вводит запрос, в списке результатов выбирает первый и осуществляет бронирование. Даже если первый результат объективно является лучшим вариантом для юзера, люди все равно хотят рассмотреть несколько других, прежде чем сделать выбор.
Теперь давайте посмотрим, как пользователь взаимодействует с поисковыми системами. Они обычно начинают со страницы, где вводят параметры поиска: место, дата путешествия и количество туристов. Далее они увидят наиболее подходящие позиции.
Это то, что видит пользователь, но за кулисами мы имеем сложную систему ранжирования, которая объединяет тысячи и тысячи сигналов, которые дают понять, что эти предложенные варианты — именно то, чего хочет наш гость.
Наша задача, как поисковой команды, заключается в том, чтобы помочь юзеру достичь своих целей. То есть мы должны сделать процесс поиска места проживания как можно проще. Начнем с раздела Find. Мы постоянно измеряем, насколько точно результат выдачи соответствует запросам пользователей. Наиболее эффективным является подсчет общего числа пользователей, совершивших поисковый запрос, и тех, кто закончил бронирование на Airbnb. Увеличить последний показатель можно лишь повышая качество, релевантность и персонализированность поисковых результатов для конкретного юзера.
Поэтому сначала мы должны понять концепцию качества: это, по сути, привлекательность позиции с точки зрения запроса. У нас есть модель, которая вычисляет качество для каждого результата поиска, и затем мы используем этот показатель при ранжировании компаний. В широком смысле, модель выглядит как две группы сигналов. Одна группа — это атрибуты позиций: картинки, количество отзывов, рейтинги, привлекательность локации, предположительная стоимость и т.д. А другая — поведенческие сигналы: взаимодействие пользователя и позиций на нашем сайте.
Поведенческие факторы
Они являются негласными отзывами пользователя о результатах поиска, и потому очень полезны для нас. Давайте взглянем на этот пример поисковой страницы.
Мы можем предположить, что типичный пользователь просматривает результаты сверху вниз, черные стрелки указывают на порядок рассмотрения результатов поиска юзером. Если он считает, что позиция стоит его внимания, то кликнет на нее для получение более детальной информации, или сразу перейдет к следующей. Таким образом, мы уже можем попытаться построить фактор ранжирования, подсчитав количество кликов, которые получил каждый результат, но тут стоит сделать маленькую поправку. Давайте посмотрим на результаты, а именно на номер 7.
Будет ли верно сказать, что пользователь увидел последнюю позицию и посчитал ее наиболее подходящей? Также возможно, что гость уже нашел наилучший результат среди 7 вышерасположенных. А может, он и вовсе решил отказаться от запроса или изменить его. Чтобы предотвратить несправедливое исключение из результатов выдачи, для каждой отдельной страницы мы определяем позицию последнего клика. В данном случае, это результат №7. Таким образом, при создании фактора ранжирования берется во внимание последний рассмотренный результат, а также все вышестоящие открытые юзером ссылки.
Конечно, просто клика недостаточно как такового. Мы не должны ограничивать все поведенческие сигналы при поиске. К примеру, мы смотрим на страницу и пытаемся оценить, как много времени потребовалось гостю на какие-либо действия после краткого просмотра страницы с поисковыми результатами.
Поведенческий подход к качеству может быть весьма эффективным. Есть некоторые предложения, которые получили очень низкие оценки, но, согласно перечисленным выше поведенческим сигналам, их балл был крайне высок. Сначала вы можете найти некоторые низкокачественные результаты, вроде этой пещеры в Берлине.
Это, вероятно, вовсе не настоящая позиция. Иногда тип позиции может оказаться неожиданным: типичный юзер Airbnb не ожидал найти место для парковки. Вот еще пример: у нас есть гараж.
И машина!
Теперь взглянем с другой стороны. Вы можете увидеть, в чем, как правило, отличие доступных позиций: привлекательность фотографии, конкурентная стоимость и высокий рейтинг. Конечно, иногда нам не удается сделать правильную оценку, полагаясь лишь на поведение пользователя, поэтому мы объединяем поведенческие сигналы с более явными факторами, такими как отзывы, для вычисления окончательной оценки качества.
Как ни странно, мы уделяем больше внимания качеству, чем самому результату выдачи. Для бизнесс-туристов местоположение жилья играет важнейшую роль. Мы всегда просим наших пользователей заполнить маленькую форму-опрос по завершении пользования услугой. И в одном из пунктов мы просим пользователя оценить местоположение (локацию). Таким образом, мы можем использовать эти ответы, чтобы увидеть алгоритм, а затем, если угодно, оценить качество местоположения любой позиции, просматривать оценки близлежащих позиций.
Здесь, слева, у нас отображается показатель качества для Сан-Франциско, который основан на knn. А справа у нас оценки позиций в Сан-Франциско, полученные из другой карты.
Рассматривая локацию, важно учитывать не только качество, еще должна быть релевантна запросу. Здесь мы видим позиции по запросу «Santa Cruz, CA».
Очевидно, что все предлагаемое жилье находится в Санта-Крус, но что если пользователь хотел остановится в Санта-Крус-Каунти? Вторая позиция здесь от Airbnb, у нее 500 просмотров. Но ее расположение — Аптос, который находится рядом, но все же это не Санта-Крус, и мало кто догадался бы искать именно это место. Конечно, мы могли бы сказать что-то вроде «Если запрос “Санта-Крус”, то Аптос тоже подходит». Но эта проблема остается неразрешенной только потому, что мы работаем по всему миру. Кроме того, мы действительно не хотим делать выбор за наших пользователей. Наоборот, мы хотим учиться на основании их действий, рассуждений относительно каждого запроса. Также запросы могут быть куда более сложными, чем просто названия городов. Юзер может искать окрестности поселка, пригород, почтовый адрес, страну или государство. Иногда — даже отдельную достопримечательность.
Так как мы хотим узнавать о релевантности от наших пользователей, то должны понять, что именно люди считают релевантным, подходящим именно для них. После того, как мы группируем логи пользовательских действий, возникает еще одна проблема. Отдельные юзеры могут заходить на сайт несколько раз для решения различных задач. Например, гость заходит на сайт и вводит запрос «Пасифика», потом решает осуществить бронирование. На следующий день он возвращается и ищет жилье в «Лос-Анджелес», а бронирует в «Санта-Моника». И мы пытаемся разделять такие действия.
Еще одним важным шагом является каноникализация. Необходимо очищать данные, особенно исправлять ошибки и различия в написании. Например, «SF» — это Сан-Франциско, однако корректно в запросе нужно вводить «San Francisco, CA, USA». Мы исправили орфографическую ошибку для Германии и внесли в базу японское написание запроса «Buenos Aires».
После того, как у нас есть данные по сессии, компьютер начинает генерировать сигналы. Один из них — условная вероятность заказа в данный промежуток времени, учитывая специфику определенного запроса. Это эффективно отражает, сколько людей искали что-то уже забронированное в определенном населенном пункте.
К примеру, если проанализировать бронирования в городе Аптос, то окажется, что люди находили данную позицию по запросу «Санта-Крус». Это указывает на сильную связь между этими двумя местами. А также сигналы данных, количество позиций в этой локации, и расстояние между местом бронирования и населенным пунктом в запросе.
Это реальные данные по запросу «Пасифика, Калифорния». Вы можете увидеть некоторые интересные особенности. Например, большинство людей, которые ищут жилье в Пасифика, осуществляют бронирование в Сан-Франциско. Это может показаться странным, но это связано с тем, что в Пасифика Airbnb пользуется еще не очень высокой популярностью. По запросу отображается всего около 20 позиций. А вот Сан-Франциско предложит вам огромный выбор. Даже если пользователь хочет остановится в Пасифика, зачастую в конечном итоге он все равно забронирует жилье в Сан-Франциско. Мы можем окончательно развенчать сомнения, приняв во внимание размеры городов.
Посмотрите на вторую таблицу. Большое количество пользователей, которые решили остановится в Эль Гранада, до этого хотели выбрать Пасифику. На последнем графике вы можете увидеть комбинированный балл. Не только вы можете обнаружить, что Пасифика релевантна запросу «Пасифика», у нас также есть куча альтернативных мест, как Эль Гранада и т.д.
Вы можете увидеть их все на карте. Люди, которые искали жилье здесь, также могли рассмотреть варианты в ряде других мест. Отображены все города расположенные неподалеку от Пасифика, которые вполне соответствуют запросу.
Кроме того, все результаты мы пытаемся персонализировать для конкретного гостя. Для этого мы используем социальные графы. Тот факт, что ваш друг просмотрел результаты поиска, а потом выбрал конкретную позицию, делает ее более релевантной для вас. Мы также стараемся находить результаты с наибольшей вероятностью знакомства гостя и хозяина в реальной жизни. Например, у вас может быть общий друг с хозяином, или он ходил в тот же ВУЗ, что и вы.
Конверсия бронирования
Наша задача заключается в том, чтобы максимально облегчить поиск и бронирование жилья для наших пользователей. Мы обсуждаем, каким образом мы можем помочь им найти наилучшее место. Но как мы можем быть уверены, что они действительно осуществят заказ? Airbnb похож на другие сайты для путешественников.
Вот иллюстрация потока бронирования. Сперва вы должны найти привлекательную позицию. Далее вы связываетесь с хозяином. Если он соглашается принять вас, то вы бронируете. На сайте поддерживаются горячие клавиши для быстрого доступа к отдельным функциям. К примеру, есть опция мгновенного бронирования, которую может активировать хозяин, но в большинстве случаев вам все равно понадобиться подтверждение от владельца жилья. Хозяин может отказаться принять вас или просто проигнорировать. Это действительно неприятно, когда вы ищете подходящую позицию три дня, а потом вас просто игнорируют.
Мы отслеживаем действия от момента установления контакта с владельцем жилья до подтверждения кандидатуры гостя. По существу, «Contact to Accept» — это соотношение между пользователями, пребывание которых было подтверждено владельцами, и тех, кто пытался связаться с владельцами жилья.
Мы довольно далеко продвинулись на протяжении последних лет.
Мы провели небольшие исследования, чтобы определить, почему отвергают кандидатуры некоторых гостей. И опять у нас есть два набора сигналов: один «материально-технический», второй «эмоциональный». Наиболее распространенной технической причиной является доступность. Например, хозяин не обновил календарное время или просто не отметил на календаре доступность жилье в определенные дни. Или он не в состоянии удовлетворить пожеланиям гостя: продолжительности пребывания, времени, необходимому до или после заселения. Некоторые хозяева устанавливают минимальный срок проживания, три ночи, к примеру, или въезд только по выходным. Конечно, всегда есть и эмоциональная составляющая. У каждого владельца есть предпочтения, согласно которым он решает, принять вас или нет.
Мы многое делаем, чтобы улучшить показатели. Например, пытаемся связать хозяина с таким гостем, которого он с высокой вероятностью согласился бы обслуживать. Много усилий тратится и на оптимизацию: баланс привлекательности и показателя bookability (бронируемости, бронепригодности) — того, как часто осуществляется бронирование, так как менее привлекательная позиция на самом деле может быть лучше. И, конечно, пользовательский интерфейс должен располагать к взаимодействию с сайтом.
Хост-совместимость
Это наша попытка существенно персонализировать продукт для наших владельцев. Существует несколько важных для этого моментов. Первое: только потому, что хозяин принимает в среднем 50% желающих, еще не означает, что любой запрос с равной вероятностью будет принят или отклонен. На самом деле, хозяин имеет собственные предпочтения, гость может не подходить по личным причинам и отклонен без объяснений. У различных хозяев различные предпочтения. Один из примеров, наш владелец жилья из Майями. Он предпочитает принимать гостей на протяжении длинных промежутков времени и отклоняет все запросы на проживание в течении нескольких дней. Он не согласится принять человека на 2 ночи, если это помешает ему принять других туристов на более длительный срок.
Еще одним важным фактором для принятия решения является то, вписывается ли конкретный запрос гостя в календарь хозяина.
Предположим, что это мой календарь. У меня есть бронирование с 21 по 24 число. Есть и еще одно бронирование. Между ними у меня есть три свободных дня, с 25 по 27 февраля. Предположим, что у меня есть запрос на однодневное проживание на 26 февраля. Если я приму его, это будет означать, что у меня окажутся пробелы в графике и придется искать еще двух жильцов на два свободных дня и ночи. Только по этой причине вполне целесообразно было бы отклонить данный запрос. Хотя другой владелец, возможно, предпочел бы иметь свободное время между бронированиями и принял бы данное предложение.
В Airbnb мы используем информацию о прошлом поведении хозяина, отказах и принятых запросах для персонализации модели отклика сайта на то или иное действие. Мы учитываем предпочтения каждого хозяина и потом применяем данную модель при поиске, чтобы подсчитать вероятность принятия запроса на заселение, учитывая все имеющуюся информацию о поездке, госте и текущем статусе владельца. Некоторые из них не имеют четких предпочтений.
А вот еще один пример того, как изменение AUI может иметь довольно больше влияние на показатели. Мы использовали данную функцию несколько лет назад, что позволяло осуществлять поиск по определенным атрибутам: расстоянию, цене и т.д. Опция была довольно популярна. На самом деле, около 10% запросов делалось по стоимости аренды. Проблемой было то, что цена являлась единственным атрибутом. Как ни странно, самая дешевая позиция могла выглядеть весьма привлекательно для гостя, но он не осознавал того, что, вероятнее всего, хозяин его отвергнет. Таким образом, мы отказались от этой возможности и добавили конверсию по контрольному эксперименту.
Оценка
В Airbnb мы тестируем и оцениваем каждое, даже малейшее, изменение, которое мы делаем в поисковом интерфейсе, потоке бронирования или алгоритмах. Важно иметь набор инструментов, которые позволили бы нам быстро получать представление о работе экспериментальных функций, о продуктивности. Поэтому мы создали ряд инструментов, например, для офлайн-тестирования, которые мы используем перед тем, как внедрить новый алгоритм. Также у нас есть и мощности для онлайн-оценки. Иногда мы проводим эксперименты на уровне рынка.
S x S
Side by side, один из важнейших инструментов. Он позволяет инженерам получать быстрые ответы на вопросы вроде: «На какой процент запросов это повлияет», или «Как изменение в моем ранжировании изменит распределение цен на данной странице», или «Предоставьте мне несколько примеров запросов, которые дают разные результаты в этом эксперименте по ранжированию». Инженер также может получить ответы на вопросы о трафике. К примеру, «Как мои изменения влияют на топовый или менее популярный запрос». На ночь мы запускаем обработку подобных запросов от разработчиков, анализируя примеры реальных запросов. Результат представляет собой список запросов с разным распределением вероятности. После этого можно производить сравнения, мы просто указываем, что именно мы хотим сравнить, эксперименты по ранжированию, опции оценивания, образцы запросов, то, сколько примеров нам требуется.
Мы сравниваем различные наборы результатов, используя специальную функцию, которая основана на методе корреляции Kendal’s tau rank. Это весьма простой метод, с помощью которого подсчитывается количество пар результатов, которые изменяют позиции. Мы внесли некоторые изменения в алгоритм. К примеру, модифицировали его для работы с топовыми запросами, так как на сайте пользователь видит лишь топовые позиции. Мы уже получили некоторую статистику. Например, изменение ранжирования влияет на более чем 30% запросов.
Инженер может также углубиться в поиск и анализ данных. Если вы хотите узнать, почему результаты ранжированы определенным образом в вашей контрольной группе, то можете просмотреть значения всех сигналов, все оценки, полученные в результате ранжирования, и так далее. Не все данные можно отобразить, так как они могут содержать конфиденциальную пользовательскую информацию, однако эта информация очень значима для внесения быстрых изменений.
Основным правилом здесь является: всегда проводить эксперименты на реальных пользователях. Таким образом, мы можем внедрить изменения в пользовательский интерфейс или модифицировать алгоритм ранжирования, а потом сравнить конверсию в различных группах юзеров.
Также я хочу рассказать об одной проблеме, которая делает взаимодействие на сайте весьма затруднительным.
Возьмём пример, когда у нас есть две позиции в одном городе. Оба варианта имеют приблизительно одинаковую цену и множество отзывов. Первая позиция стоит выше, так как имеет более высокий процент принятия гостей, 90%, а у второй лишь 50%. Давайте предположим, что мы проводим эксперимент по подбору хозяина. Видимо, второй владелец предпочитает семейные пары. Если это не пара, он просто отвергает кандидатуру. Мы разрабатываем следующий эксперимент: говорим, что группа увидит обычный рейтинг позиции, но если количество гостей в запросе равно двум, то второй результат выйдет в топ, так как рейтинг подтверждения гостей составит 100%. Позиция начнет получать заказы, календарь хозяина начнет заполнятся, результат будет реже отображаться для контрольной группы людей. Таким образом, меньше людей из контрольной группы попадут в ловушку и будут связываться с владельцем жилья, что даст возможность контрольной группе работать лучше на благо эксперимента.
Есть и совершенно противоположные примеры. Тот факт, что это эксперимент, может ослабить ваш контроль над ситуацией. Определенные аспекты могут быть недооценены. Проблема в том, что вы можете изолировать гостей друг от друга, однако они все еще взаимодействуют на рынке. И что более важно, они влияют своими запросами на его развитие. К примеру, если гость бронирует жилье на определенную дату, это означает, что другой пользователь уже не сможет его забронировать.
Для нас это большая проблема. Конечно, это не проблема для продукта, как Google Search, ведь веб-результаты не исчезают, когда люди нажимают на них. Однако все намного сложнее, когда вы имеете дело с локациями. Один из путей решения — отделиться от рынка насколько возможно. Если вы проводите эксперимент в Бостоне, к примеру, то это не должен влиять на рынок в Чикаго. Мы можем создать контрольные группы внутри этих отделений. Теперь это пользователи не на уровне местного рынка, а целых географических областей. И мы можем запустить эксперимент для всех юзеров в определенной области, а потом сравнить результаты с данными по контрольному региону.
Проблема здесь в том, что для Airbnb очень затруднительно найти рынки, которые мы бы могли сравнить друг с другом. Во-первых, туристический бизнес имеет ярко выраженную сезонность. И на разных рынках высокие сезоны приходятся на разное время года. Таким образом, производительность и доходность каждого региона будет варьироваться в зависимости от факторов, которые трудно все учесть. К тому же Airbnb продолжает расти очень быстро, а некоторые рынки все еще не стабилизировались, и становясь больше они полностью меняют картину.
Я рассказал о том, как мы помогаем нашим гостям находить привлекательные позиции, как мы отображаем доступность позиций и оцениваем внесенные нами изменения. Напоследок немного расскажу о некоторых проблемах, с которыми мы недавно столкнулись. Если вы зайдете на наш сайт, то увидите достаточно ясный посыл: «Дайте нам дату и место поездки, и вы получите жилье». Заходя на Airbnb вы должны четко знать, куда вы хотите ехать. Но это не должно быть так. Мы хотим научиться выдавать подходящие результаты на множество запросов. К примеру, «Что если я даже не знаю, куда хочу поехать, но наверняка знаю, чем хочу заняться. Можете ли вы подобрать для меня потрясающую поездку с учетом того, что вы обо мне знаете?» Чтобы помогать пользователя с подобными запросами, нам нужно научиться «мыслить» шире и смотреть «глубже».
