14 марта в 18:43

Хорошо ли подсказывают сервисы подсказок: измеряем полезность веб-сервисов автодополнения из песочницы

Примерно месяц назад со мной произошёл один эпизод, который заставил задуматься на тему полезности функций автодополнения, которые часто встраиваются на сайтах интернет магазинов. Обычно это выглядит так: начинаешь оформлять заказ, вводишь своё имя, телефон и адрес доставки, и пока ты неспешно набираешь адрес, перед тобой выскакивают подсказки с названиями улиц, чтобы ты не напрягал клавиатуру и выбирал нужный адрес из предложенного списка.

Так вот, в феврале мне потребовалось оперативно накормить дома большую компанию друзей, и я решила заказать пиццу в одном достаточно популярном заведении. Вообще обычно я придерживаюсь принципов здорового питания, но ситуация была исключительной…

Вы скажете Хабр – не место для историй про пиццу, и будете абсолютно правы, но данная история не совсем про пиццу, она в большей степени про моделирование поведения человека, про нагрузочное тестирование, немного про программирование, и в большей степени про числовую оценку полезности нескольких современных ajax-сервисов автодополнения и подсказок.

Но толчком к написанию данной статьи была всё-таки пицца и тот факт, что мне пришлось оформлять её заказ дважды из-за того, что на сайте при заполнении поля с адресом доставки использовались подсказки. Хитрость была в том, что пока ты не выберешь улицу из предложенного списка, тебе не дадут указать номер дома. Поскольку по привычке свой адрес я набираю очень быстро, а подсказки на том сайте работали очень неторопливо, получилось так, что весь этот ajax-механизм с подгрузкой подсказок не успел отработать. Как следствие я не смогла указать номер дома. Пришлось нажимать F5, оформлять заказ заново и повторно вводить свой адрес медленно, но верно.

Вся эта история в итоге закончилась благополучно, и пицца была доставлена по адресу, но осадок остался. Я решила задаться вопросом, можно ли как-то измерить или оценить полезность использования такого рода сервисов, ведь функции автодополнения встречаются повсеместно.

Как следствие, этот вопрос вылился в полноценное исследование, с разработкой скриптов для тестирования полезности шести доступных в настоящий момент онлайн сервисов автодополнения почтовых адресов. Результатам этих исследований и посвящена данная статья.

Формула полезности


Исследование полезности нужно начать с определения формулы её подсчёта. Чисто интуитивно понятно следующее.

  1. Если ты вводишь данные, а вместо подсказок наблюдаешь крутящееся колёсико – это не очень полезно. И наоборот, если подсказки выскакивают быстрее, чем ты успеваешь набирать текст – это хорошо.



  2. Если ты долго и упорно заполняешь форму буква за буквой, но подсказки подсказывают не то, что надо, то польза от них сомнительна. И наоборот, если ввёл пару букв, а в подсказках уже материализовалось желаемое, то налицо очевидный профит от их использования.


Все эти размышления привели меня к следующей формуле, оценивающей полезность сервиса автодополнения.

$U_s=1-\frac{(T_u+T_s )}{T_o}$


Здесь $T_u$ — суммарное время, которое пользователь тратит на ввод адреса при использовании подсказок, $T_s$ – суммарное время, которое пользователь тратит на ожидание подсказок от сервиса, $T_o$ — общее время, которое пользователь потратил бы на ввод данных без использования подсказок.

Вы спросите, зачем выделять отдельно $T_s$, ведь ajax — штука асинхронная и время отклика не задерживает пользователя при наборе текста. Но, как было отмечено выше, эта статья про моделирование поведения человека. Когда пользователь видит, что ему предлагают подсказки, его работа за клавиатурой меняется, а именно – она выглядит так:

  1. Нажал на клавишу с очередной вводимой буквой.
  2. Подождал подсказок.
  3. Убедился, что подсказок правильных нет, и вернулся к пункту 1.

Как видим, вполне себе синхронная работа получается, так что время, которое пользователь тратит на ввод данных, определяется именно суммой $(T_u+T_s )$.

В нормальном состоянии, когда сумма $(T_u+T_s )$ меньше знаменателя $T_o$, значение функции попадает в диапазон [0 … 1] и, фактически, показывает процент времени, которое пользователь экономит, используя подсказки. Но есть и ненормальные состояния (вспоминаем про пиццу), которые мы рассмотрим чуть позже. А пока распишем, что из себя представляет $T_o$ и $T_u$.

Примем $T_o=N_o∙t_k $, где $N_o$ – число букв, из которых состоит адрес и которые пользователю нужно ввести, $t_k$ – время, которое в среднем пользователь тратит на поиск буквы на клавиатуре и нажатие соответствующей кнопки. Данное время зависит от умений пользователя работать с клавиатурой. Мы выделим три класса пользователей: «тихоход», «середнячок» и «торопыжка». Для каждого из этих классов позже мы зададим соответствующее значение $t_k$, в результате для каждого класса пользователей будет отдельно получено значение полезности.

Примем $T_u=N_u∙t_k+S∙(C∙t_k )$ где $N_u$ – количество букв адреса, которые пользователю фактически приходится вводить с использованием подсказок. При получении правильной подсказки пользователь перестаёт набирать адрес, вместо этого он просто выбирает его из предложенного списка. В этом случае $N_u<N_o$. Если пользователь не получил подходящую подсказку, то ему приходится вводить адрес полностью, в таких ситуациях $N_u=N_o$. Второе слагаемое $S∙(C∙t_k)$ отражает время, которое пользователь тратит на выбор из предложенного списка подходящих подсказок. В общем случае пользователь может воспользоваться подсказками $S$ раз, например, при вводе города – первый раз, и при вводе улицы – второй раз. При выборе подсказки пользователь, как правило, нажимает несколько раз на клавиатуре кнопку со стрелкой «вниз», чтобы выбрать нужную подсказку, после чего нажимает на какую-то кнопку (например, Enter), чтобы подтвердить свой выбор. Эти действия не требуют поиска нужных кнопок на клавиатуре, поэтому данное время можно принять за константу, которая зависит от класса пользователя: «тихоход» плохо владеет клавиатурой, поэтому стрелки нажимать он будет медленнее в сравнении с «торопыжкой». Поэтому данную константу я привязала к $t_k$, а коэффициент $C$ был подобран эмпирически (см. результаты экспериментов в конце статьи). Важно помнить, что $S=0$ в ситуациях, когда сервис не вернул подходящих подсказок и, как следствие, пользователь не выполнял действий, связанных с выбором подсказки из списка.

Подставив все эти выражения в формулу полезности, получим следующее

$U_s=1-\frac{N_u+S∙C}{N_o}-\frac{T_s}{N_o∙t_k}$

Итого, чтобы оценить полезность сервиса автодополнения, нужно измерить его время $T_s$, которое он тратит на генерацию и выдачу подсказок, получить число букв $N_u$, которые пользователю фактически приходится вводить при наборе адреса, а также количество раз $S$, которые пользователю приходится выбирать подсказки. Из формулы следует, что чем меньше эти показатели, тем выше будет полезность подсказок. В идеальной ситуации, когда пользователь ещё ничего не начал вводить, а форма с адресом уже заполнена правильными данными, имеет место $N_u=0$, $T_s=0$ и $S=0$. В этом случае полезность равна 1. Эта ситуация идеальна и на данный момент, вероятно, достичь её с использованием земных технологий не представляется возможным, однако есть к чему стремиться.

В самом худшем случае, пользователь вводит адрес целиком, при этом после ввода каждой буквы он дополнительно ожидает подсказку в надежде, что она избавит его от дальнейшего ввода. В этом случае $N_u =N_o$ и $S=0$, как следствие получаем отрицательную полезность $U_s=-\frac{T_s}{N_o∙t_k }$, которая отражает дополнительные затраты времени, которые пользователь понёс из-за бесполезного ожидания подсказок. В такой ситуации, если бы подсказок вообще не было, пользователь ввёл бы адрес быстрее.

Обзор сервисов автодополнения


Итак, изобретённую мной формулу нужно было на чём-то проверить. Поискав в интернете, я нашла шесть подходящих сервисов, позволяющих через REST API отсылать фрагменты адресных данных и получать для них подсказки (ещё один сервис мне порекомендовали в комментариях, так что в итоге их получилось семь штук). Все рассмотренные мной сервисы работают однотипно, а именно:

  • Методом GET или POST получают HTTP запрос с уже введённым фрагментом адреса.
  • Возвращают в JSON формате массив с предлагаемыми подсказками.

Конечно структура JSON-ответа у каждого сервиса своя, но семантика более менее одинаковая. Чтобы промоделировать работу пользователя с каждым из этих сервисов, я написала соответствующий скрипт. Этот скрипт имитирует набор почтового адреса на клавиатуре, а в процессе такой имитации анализирует возвращаемые подсказки на предмет их адекватности. Исходники всех скриптов можно взять на гитхабе, ссылка прилагается в конце статьи.

Все рассмотренные сервисы, за исключением Яндекса и Гугла, в качестве источника данных используют адресные справочники КЛАДР или ФИАС, либо одновременно их оба. Оба справочника ведутся ФНС России. Найти информацию по ним можно на следующих сайтах: КЛАДР — http://gnivc.ru, ФИАС – fias.nalog.ru. Яндекс и Гугл для генерации подсказок используют, скорее всего, данные со своих карт.

Краткий обзор всех сервисов, принимавших участие в моих экспериментах, приведен ниже. В ходе обзора и в результатах экспериментов сервисы упорядочены в алфавитном порядке.

Ахантер


Сервис доступен по адресу ahunter.ru. Судя по данным whois, сервис появился в Рунете в начале 2009 года. Подсказки для адресов предлагаются на бесплатной основе, по поводу лимитов на сайте отдельно сказано, что их нет.

Протестировать подсказки можно непосредственно в демо разделе сервиса здесь. Для внедрения подсказок на сторонние сайты веб-мастерам рекомендуют использовать плагин jQuery-Autocomplete, который можно взять на гитхабе по следующей ссылке. Для написания бот-скрипта я использовала непосредственно документацию на API сервиса, почитать которую можно здесь.

Дополнительно кроме подсказок для адресов авторы сервиса предлагают исправлять и структурировать адреса по КЛАДР и ФИАС и получать для них геокоординаты, но это уже за отдельную плату.

Google Places API Web Service


На самом деле под этим названием скрывается несколько сервисов, из которых нас интересуют «Подсказки мест». Информация по этому сервису доступна здесь. На использование сервиса установлены довольно серьёзные квоты, бесплатно можно обработать только 1000 запросов в сутки. Однако если указать в аккаунте данные своей кредитной карты, то будет доступно 150 000 запросов в сутки бесплатно. Всё что свыше этого оплачивается отдельно.

Для встраивания на своем сайте нужно использовать JavaScript библиотеку адресов в Google Maps. Информация по ней доступна здесь. Там же имеется возможность протестировать и посмотреть демо. Для написания бот-скрипта я использовала документацию на API сервиса, доступную по ссылке выше.

Дополнительно с помощью других сервисов этой группы можно отдельно запрашивать геокоординаты получаемых в подсказках адресов.

Дадата


Сервис доступен по адресу dadata.ru. По данным whois сервис появился в Рунете в конце 2012 года. Для использования подсказок нужно покупать подписку на год, либо укладываться в суточный бесплатный лимит.

Демо страница подсказок имеется, она доступна по следующей ссылке. Для внедрения на своём сайте авторы сервиса предлагают использовать jQuery плагин собственной разработки. Для написания бот-скрипта я использовала документацию на API сервиса, доступную по следующей ссылке.

За отдельную плату по части адресов на сайте предлагают такие же дополнительные опции, как и на Ахантере.

КЛАДР в облаке


Сервис доступен по адресу kladr-api.ru. По данным whois сервис появился в начале 2012 года. Авторы предлагают купить подписку на три месяца или на год, либо укладываться в бесплатные суточные лимиты.

Демо страница, где можно пощупать подсказки, доступна по следующей ссылке. Для использования подсказок на сторонних сайтах авторы предлагают использовать разработанный специально под данный сервис jQuery плагин, который можно взять на гитхабе здесь.

Для разработки бот-скрипта я использовала документацию на сайте сервиса, доступную здесь, она не очень подробная, однако разобраться можно.

Fias24


Сервис доступен по адресу fias24.ru. Судя по данным whois, это пока молодой сервис, он появился в Рунете в конце 2016 года. Для использования подсказок нужно покупать подписку на год.

Демо страница подсказок имеется, она доступна на главной странице сервиса. Для внедрения на сайтах авторы сервиса предлагают использовать jQuery плагин собственной разработки. Полноценной документации на REST API на сайте нет, поэтому для написания бот-скрипта мне пришлось включить интуицию и накопленный опыт по работе с другими сервисами.

Яндекс Карты


Здесь, я думаю, дополнительных описаний не требуется, поскольку сервис хорошо известен даже среди домохозяек. Явных лимитов в условиях использования данного сервиса замечено не было, однако Яндекс предупреждает, что для больших проектов нужно договариваться отдельно, ну и в случае чего может в любой момент ограничить доступ на своё усмотрение. При проведении моих экспериментов отказов в доступе замечено не было.

Как работают подсказки в Яндекс Картах, можно посмотреть на… Яндекс Картах, поэтому ссылку на «демо» давать не буду. Для встраивания на сторонних веб сайтах у подсказок Яндекса есть отдельный API, документацию можно найти здесь https://tech.yandex.ru/maps/doc/jsapi/2.1/ref/reference/SuggestView-docpage/.

Невероятно, но факт, кроме подсказок сервис предлагает дополнительные опции по работе с координатами, правда для этого нужно использовать другой API.

Iqdq


Данный сервис был добавлен в статью по просьбе его авторов уже после публикации статьи на Хабре. Сервис доступен по адресу iqdq.ru. По данным whois сервис появился в конце 2013 года. Подсказки для адресов предлагаются бесплатно.

Демо страница, где можно пощупать подсказки, доступна по следующей ссылке. Для использования подсказок на сторонних сайтах авторы дают примеры JavaScript кода с использованием jQuery. Для написания бот-скрипта я использовала документацию на API сервиса, доступную здесь.

За отдельную плату по части адресов на сайте предлагают дополнительные опции, такие же как и на сервисах Ахантер и Дадата.

Описание эксперимента


Для каждого сервиса из этого обзора нам нужно измерить время отклика $T_s$ и число букв $N_u$, которые пользователю приходится вводить прежде, чем он получит подходящую подсказку, либо пока адрес не будет набран целиком. Для этого я подготовила тестовую выборку. В неё суммарно была включена 3591 улица из 406 городов России. Для каждого города отбиралось не более 10 улиц, причём улицы выбирались так, чтобы по возможности охватить весь алфавит. В тестовую выборку не включались небольшие населенные пункты (деревни и посёлки) поскольку потенциальной целевой аудиторией сервисов подсказок являются всё-таки жители достаточно крупных городов.

Описание тестовой выборки


Тестовую выборку можно скачать вместе с исходниками. Выборка представляет собой JSON-массив, каждому элементу которого соответствует тестовый адрес, ввод которого мы будем эмулировать для получения подсказок. Пример с описанием полей этих адресов приведён ниже:

{
  "id" : 1,      
  "reg" : "Адыгея",
  "reg_type" : "Респ",
  "reg_kladr" : "0100000000000",
  "city" : "Адыгейск",
  "city_type" : "г",
  "city_kladr" : "0100000200000",
  "street" : "8 Марта",
  "street_type" : "ул",
  "street_kladr" : "01000002000003800"
}

Здесь id – уникальный идентификатор тестового адреса в пределах выборки, reg – имя региона, которому принадлежит адрес, reg_type – тип региона, reg_kladr – код по КЛАДР региона. Аналогично для города введены поля city, city_type, city_kladr и для улицы введены поля street, street_type, street_kladr.

Алгоритм тестирования


Для каждого адреса нашей выборки нужно создать имитацию его ввода, для отслеживания подсказок, получаемых от тестируемого сервиса. При этом мы полагаем, что пользователь вводит только название города и улицы, название региона ему вводить не нужно, ведь он проживает в одном из 406 достаточно крупных городов России. В нашей имитации сначала, буква за буквой, набирается название города. Каждая новая буква, добавленная в конец вводимого названия, порождает новый запрос к сервису. Среди полученных подсказок ищется ожидаемый адрес, который мы заранее знаем, ведь именно для этого он и присутствует в тестовой выборке.

Если среди первых пяти подсказок полученного списка находится вводимый город, то дальнейшая имитация набора названия города прекращается. Полагается, что пользователь увидел название и выбрал его. Поэтому дальше пользователь переходит к набору названия улицы. Для этого имитирующий скрипт последовательно, буква за буквой, наращивает название улицы и добавляет её к выбранному на предыдущем шаге городу. После каждой добавленной буквы получившийся фрагмент адреса вновь отсылается сервису.

Ну и дальше по аналогии с городом мы ищем среди первых пяти подсказок вводимую улицу, если она попала в выдачу, то дальнейшая имитация ввода улицы прекращается, иначе – переходим к следующей букве и снова отсылаем запрос.

Такой нехитрый тест позволяет измерить время отклика сервиса $T_s$ и число букв $N_u$, которые требуется ввести пользователю для того, чтобы получить в подсказках желаемый адрес. Отдельно следует оговорить ситуации, когда пользователь не получил подходящую подсказку вплоть до конца ввода названия города. В этом случае наш моделируемый пользователь понимает, что сервис не в состоянии помочь ему при вводе конкретно этого адреса. Поэтому дальнейший ввод улицы выполняется без использования подсказок. В этом случае пользователь уже ничего не ждёт от сервиса, так что время отклика перестаёт влиять на его поведение и в этом случае можно принять $T_s=0$, однако пользователю придётся набрать название улицы полностью, так что $N_u$ будет совпадать с $N_o$.

Исходные тексты


Все скрипты написаны на Perl. Исходники имеют следующую структуру.

  • Скрипт run_test.pl – основной и единственный скрипт, который нужно запускать для прогона теста для любого сервиса.
  • Пакет TestWorker.pm содержит реализацию алгоритма тестирования, описанную выше.
  • Пакет TestStorage.pm нужен для работы с хранилищем результатов тестирования. Все результаты сохраняются в базе данных sqlite, чтобы после прохождения всех тестов можно было выполнить все необходимые вычисления.
  • Пакеты AhunterAPI.pm, GoogleAPI.pm, DadataAPI.pm, KladrAPI.pm, Fias24API.pm, YandexAPI.pm и IqdqAPI.pm содержат реализацию работы с API соответствующего сервиса. Какому сервису соответствует каждый пакет можно догадаться по его названию.
  • suggest_test_full.json – файл, содержащий наш 3591 тестовый адрес.

Строка запуска тестирования для некоторого сервиса имеет следующий вид:

run_test.pl <полный путь к файлу с тестами> <Имя API-пакета сервиса> <Ключ API>

Например, для тестирования сервиса от Google нужно запустить тест следующим образом.

run_test.pl /home/user/suggest_test_full.json GoogleAPI ABCDEFG

Здесь /home/user/suggest_test_full.json – полный путь к файлу с тестами, GoogleAPI – имя пакета, соответствующего тестируемому сервису, ABCDEFG – ключ для работы с сервисом через API, который нужно получить в личном кабинете своего аккаунта. Сервисы Ахантер и Яндекс не требуют регистрации, поэтому для них можно передавать в качестве ключа API произвольную строку.

Особенности прохождения тестов


При прохождении тестов у каждого сервиса были выявлены баги особенности, которые повлияли на итоговый показатель полезности. Ниже коротко опишу их, возможно, что-то из этого разработчики сервисов учтут и улучшат в будущем.

У Ахантера в подсказках для адресов из Чувашской Республики возвращается название этого региона следующим образом «Респ Чувашская (Чувашия)». Поэтому в рамках AhunterAPI.pm пришлось особым образом реализовать сравнение подсказок для этой республики с её эталонным названием.

У Google также есть особенности в названиях нескольких регионов, например, «Тыва» возвращается как «Тува», а «Удмуртская республика» возвращается как «Удмуртия». Для них также пришлось писать отдельное сравнение. Кроме этого не удалось получить подсказки для всех адресов из Республики Крым. Все адреса из этого региона потенциальному пользователю придётся вводить целиком без подсказок, это автоматически увеличивает $N_u$ и снижает суммарную полезность сервиса. Аналогично обстоит дело с городами Новой Москвы, для которых Google возвращает подсказки из Московской области. Все эти тесты не были пройдены, т.к. формально сервис подсказывает не тот адрес, который имеет место на самом деле.

У сервиса Дадата наблюдается проблема с подсказками для городов, названия которых совпадают с названиями улиц или районов в других городах. Например, для города «Мирный» предлагает адреса типа «Самарская обл, г Тольятти, проезд Мирный 2-й», а для города «Березовский» предлагает адрес «г Краснодар, Березовский сельский р-н». При этом название города так и не удалось получить в подсказках, даже если ввести его полностью. Из-за этого $N_u$ растёт, а полезность падает, поскольку при отсутствии подсказок, такие адреса вводятся полностью.

У Fias24 были обнаружены аналогичные проблемы с городами, названия которых совпадают с районами, либо когда название города является префиксом для названия региона, которому этот город принадлежит. Например, для города «Краснодар» сервис возвращает варианты из Краснодарского края, но самого города в подсказках нет. Это можно увидеть и на демо-странице сервиса.



Из-за этой проблемы примерно для 370 тестов не было получено подсказок для названия города. Как следствие при расчёте формулы полезности, исходя из нашего алгоритма, набор улиц для этих тестовых адресов осуществлялся без учёта подсказок. Это сказывается на увеличении $N_u$.

У сервиса «КЛАДР в облаке» ситуация аналогичная, только тестов не было пройдено порядка 700. Также данный сервис не подсказывает улицы без явного указания их типов. Примеры можно посмотреть на демо-странице сервиса:



Поэтому специально для данного сервиса было сделано исключение, при формировании запросов по названию улицы перед каждым названием предварительно вставлялся её тип. Как следствие $N_u$ для данного сервиса всегда будет больше на число букв, составляющих наименование типа улицы.

Примерно столько же тестов не было пройдено сервисом Iqdq. В основном это связано с аналогичными проблемами – название города даже после полного ввода либо совсем не попадает в выдачу (например, «Ижевск), либо не попадает в первые 5 подсказок выдачи (например, «Брянск»).



Кроме этого встречаются такие же проблемы, как и у сервиса Дадата, когда вместо города возвращается одноименный район, например для «города Жуковский» получаем «Брянская обл, Жуковский р-н». Дополнительно можно выделить адреса, где вместо ожидаемого города возвращается одноименная деревня, например, вместо «город Пионерский» сервис возвращает «Респ Удмуртская, Игринский р-н, высел Пионерский». Всё это приводит к тому, что такие проблемные города приходится вводить полностью без подсказок. По условиям наших тестов улицы в таких адресах тоже приходится вводить без подсказок. В результате у всех таких адресов $N_u$ возрастает до $N_o$, а это снижает полезность.

У Яндекса также как и у других рассмотренных выше сервисов есть проблемы с некоторыми городами. Он вместо них возвращает названия улиц других городов. Например, для города «Октябрьский» возвращает «Россия, Московская область, Люберцы, Октябрьский проспект». Также была обнаружена проблема с подсказками для улиц, в названиях которых есть инициалы. Например, по запросу «Россия, Республика Адыгея, Адыгейск, Чича» можно получить ответ «Россия, Республика Адыгея, Адыгейск, улица П.С. Чича». Если этот ответ повторно отправить в качестве запроса, то Яндекс возвращает пустой результат. Из-за этой особенности пришлось из тестовой выборки исключить все названия улиц с инициалами и повторять все тесты для всех сервисов заново.

Отдельно следует сделать оговорку для сервисов, которые в качестве источников подсказок используют карты. Эти источники покрывают адресное пространство России хуже остальных участников обзора. Как следствие одной из главных причин, из-за которой эти сервисы не возвращали подсказки, является отсутствие тестового адреса на карте. Это в свою очередь автоматически увеличивает $N_u$, так как без подсказки пользователю приходится вводить все буквы адреса.

Результаты экспериментов


После выполнения теста скрипт run_test.pl выводит на экран различные статистические показатели, характеризующие результат прохождения теста. Также на экран выводятся три итоговых значения полезности сервиса для трёх соответствующих классов пользователей – «тихохода», «середнячка» и «торопыжки».

Первые четыре показателя, которые выводятся на экран, имеют следующий смысл.

  • city_avg($T_s$) – среднее время ожидания подсказок от сервиса при вводе названия города, измеряется в миллисекундах.
  • street_avg($T_s$) – аналогично предыдущему, но для названий улиц.
  • city_avg($N_u$) – среднее число букв, по которым сервис угадывает название города.
  • street_avg($N_u$) – среднее число букв, по которым сервис угадывает название улицы.

Эти показатели не участвуют непосредственно в формуле полезности, они интересны сами по себе. Ниже привожу таблицу с их значениями для всех протестированных сервисов.
Ахантер Google Дадата КЛАДР
в облаке
Fias24 Яндекс Iqdq
city_avg($T_s$) (мс) 15.98 85.93 78.55 104.05 73.88 22.46 176.73
street_avg($T_s$) (мс) 18.69 86.76 106.79 154.68 189.70 30.67 277.28
city_avg($N_u$) (буквы) 2.48 2.71 3.89 4.27 3.68 4.42 4.75
street_avg($N_u$) (буквы) 1.63 2.18 1.61 3.28 1.90 2.20 1.84

Первые два показателя отражают усреднённую отзывчивость сервиса. По ним можно судить, будет ли полезен данный сервис для пользователей с высокой скоростью набора текста на клавиатуре. Чем меньше время отклика сервиса, тем большему числу пользователей он будет полезен. Ещё здесь заметно, что все сервисы тратят меньше времени на формирование подсказок для города, тогда как подсказки для улицы отнимают у них больше сил и времени.

Но особый интерес вызывают показатели city_avg($N_u$) и street_avg($N_u$). Оказывается, для угадывания названия города достаточно менее пяти букв, поскольку для всех сервисов имеет место city_avg($N_u$) < 5. В лучшем случае для правильного угадывания названия города достаточно примерно две с половиной буквы! По крайней мере, именно столько демонстрирует Ахантер и Google, у первого city_avg($N_u$)=2.48, а у второго city_avg($N_u$)=2.71. Для правильного угадывания названия улицы требуется ещё меньше букв. Четыре рассмотренных сервиса (Ахантер, Дадата, Fias24 и Iqdq) предсказывают улицу меньше, чем за две буквы.

Теперь рассмотрим характеристики, которые нужно непосредственно подставлять в формулу полезности, поэтому приведу эту формулу еще раз, чтобы она была перед глазами.

$U_s=1-\frac{N_u+S∙C}{N_o}-\frac{T_s}{N_o∙t_k}$

Значение $N_u$ должно содержать суммарное число букв, которые пользователю пришлось набрать на клавиатуре в ходе ввода всех адресов нашей выборки. Данному значению соответствует показатель $sum(N_u)$, который скрипт выводит на экран. Данный показатель рассчитывается следующим образом.

Для всех тестов определяется общая сумма букв в именах городов и улиц, которые были набраны в ходе теста. Если для какого-то города или улицы не была получена подсказка, то в данную сумму включается длина всего названия этого города или улицы, т.к. полагается, что без подсказки пользователь вводит название целиком. В противном случае в общую сумму включается лишь то число букв, которые были фактически набраны до получения подсказки.

Дополнительно в эту сумму включаются длины регионов от тех тестов, для которых не удалось получить подсказку для города. Я исхожу из того, что если пользователь не получил подсказку для города, то ему приходится вводить целиком не только название города, но и название региона, в котором этот город находится. Для городов, по которым была получена правильная подсказка, регион вводить не надо, поэтому регионы успешных тестов не вносят вклад в данную сумму.

Далее в числителе первой дроби формулы полезности присутствует слагаемое $S∙C$. Коэффициент $C$ отражает затраты времени, связанные с самим выбором подсказки из предложенного списка. Ранее я говорила, что этот коэффициент был выбран эмпирически. Эта константа зашита в коде скрипта и имеет значение 3. То есть на выбор подсказки пользователь тратит времени столько же, сколько у него уходит на ввод 3-ёх произвольных букв адреса. Данный коэффициент умножается на $S$ — число раз, когда в ходе набора были задействованы подсказки. Для этого тестовый скрипт выдает характеристику $sum(S)$, так что имеем $S∙C=3∙sum(S)$. В идеале $sum(S)$ должен быть равен удвоенному числу адресов нашей выборки, т.к. в идеале подсказки должны быть задействованы дважды для каждого адреса – один раз при вводе города, а второй раз – при вводе улицы. Но на практике сервисы показали меньшее значение $sum(S)$.

Далее в формуле полезности встречаем $T_s$, это суммарное время, которое пользователь ждал подсказок от сервиса. Для его получения скрипт выдает характеристику $sum(T_s)$, так что $T_s=sum(T_s)$. В ходе выполнения тестов скрипт засекает время, которое уходит на ожидание ответа от сервиса на каждый отправленный запрос. Вся эта информация по всем запросам сохраняется в локальной sqlite базе данных, а в конце теста суммируется.

Последний участник формулы полезности — $N_o$, это просто суммарное количество букв всех адресов выборки. Это значение не зависит от результата теста, оно всего лишь характеризует саму выборку. Скрипт выводит это число под именем $sum(N_o)$. Для нашей выборки оно имеет значение 137704. Ровно столько букв содержится в именах регионов, городов и улиц всех тестов выборки, а также в именах их типов.

Итоговые значения описанных выше характеристик показаны в следующей таблице. Для наглядности время $sum(T_s)$ переведено в минуты.
Ахантер Google Дадата КЛАДР
в облаке
Fias24 Яндекс Iqdq
$sum(N_u)$ 14808 33191 22397 50863 32820 36549 50092
$sum(S)$ 7180 5848 7043 5588 6387 6057 5415
$sum(T_s)$ 4.20 (мин) 39.29 (мин) 29.19 (мин) 58.81 (мин) 39.29 (мин) 14.67 (мин) 82.70 (мин)
Теперь осталось подставить эти значения в формулу полезности, предварительно выбрав среднее время набора на клавиатуре одной буквы $t_k$ для каждого из трёх классов пользователей: «тихохода», «середнячка» и «торопыжки». В своих расчётах я использовала следующие значения. Для «тихохода» $t_k=1000$ миллисекунд, для «середнячка» — 500 миллисекунд, а для «торопыжки» — 300 миллисекунд. Эти значения я подобрала опытным путем, попросив нескольких моих знакомых набрать на клавиатуре их почтовые адреса, измеряя при этом, сколько времени у них уходит на поиск и ввод одной буквы. Итоговые результаты представлены в следующей таблице, для удобства значения полезности в таблице переведены в проценты.
Ахантер Google Дадата КЛАДР
в облаке
Fias24 Яндекс Iqdq
Тихоход 73 % 61 % 67 % 48 % 60 % 59 % 48 %
Середнячок 73 % 60 % 66 % 46 % 59 % 59 % 46 %
Торопыжка 72 % 57 % 64 % 42 % 56 % 58 % 40 %
Как видно из таблицы, все сервисы показали положительную полезность. Значения полезности варьируются от 40% до 73%. Чем больше данный показатель, тем лучше экономится время пользователя в процессе ввода адреса. Все сервисы, за исключением «КЛАДР в облаке» и «Iqdq», имеют полезность более 50%. Это означает, что при использовании подсказок от этих сервисов пользователь сэкономит более половины своего времени при наборе адреса. Наилучшая экономия времени составляет 73%, такую полезность демонстрируют подсказки от Ахантера.

Проблемы «КЛАДР в облаке» были описаны выше, основной вклад в низкую полезность внесло большое значение $sum(N_u)$, поскольку при наборе улицы у этого сервиса нужно вводить её тип – «ул», «пер» и т.д. Так что суммарно пользователь тратит на ввод больше времени. Тем не менее, даже с учётом этого, экономия времени в 42% является неплохим показателем.

У Iqdq на низкие показатели повлияло большое время отклика, а также проблемы с непопаданием крупных городов в выдачу с подсказками. Из-за этого все адреса из этих городов вводились полностью, это привело к увеличению числа букв $sum(N_u)$, которые пользователю приходилось набирать.

Удивило, что на полезность подсказок от Google не сильно повлияли проблемы с адресами из Новой Москвы и Крыма, по которым данный сервис не выдал правильных подсказок. Здесь сказалась общая хорошая способность к угадыванию у данного сервиса. Если посмотреть на первую таблицу (см. выше), то будет видно, что Google угадывает город по меньшему числу букв, чем некоторые из рассмотренных сервисов, которые в силу своей специализации должны делать это по идее лучше.

Получившиеся значения полезности у Яндекса в первую очередь обусловлены тем, что данный сервис угадывает город по большему числу букв, чем все остальные сервисы. Раньше я писала, что вместо подсказок для города его тянет предлагать улицы из других городов.

Если анализировать полезность сервисов в разрезе классов пользователей, то тут видно, что все сервисы имеют бОльшую полезность в отношении пользователей, слабо владеющих клавиатурой. Действительно, «тихоходы» будут рады любым подсказкам, лишь бы не вводить данные вручную. Однако для пользователей, умело пользующихся клавиатурой, полезность подсказок чуть ниже. Чтобы принести максимум пользы для них, сервис должен иметь малое время отклика.

В данном разрезе все сервисы можно разделить на три группы – быстрые, средние и медленные. У быстрых сервисов (Ахантер и Яндекс) полезность не сильно зависит от скорости работы пользователя. Действительно, даже если пользователь шустро печатает на клавиатуре, быстрые сервисы успевают вернуть правильные подсказки, в результате тот получает возможность их использовать. Средние сервисы (Google, Дадата, Fias24) чуть более чувствительны к скорости работы пользователя, «торопыжкам» эти сервисы принесут меньше пользы, чем «тихоходам» и «середнякам». Ну а у медленных сервисов этот эффект заметен ещё сильнее.

Заключение


Возвращаясь к вопросу, поставленному в заголовке статьи, можно однозначно ответить «Да», современные веб-сервисы подсказок подсказывают хорошо. Мне удалось количественно измерить пользу, которую они приносят для рядовых обывателей Рунета. Полученные цифры отражают экономию времени, которую можно достичь при подключении такого рода сервисов к веб-формам, где требуется набирать почтовые адреса. В этом случае можно сэкономить до 70% пользовательского времени.

Вместе с тем, памятуя о моей истории с пиццей, хочется напомнить, что предложенная в начале статьи формула подразумевает и отрицательные значения полезности. Мне известен, по крайней мере, один сервис подсказок, для которого полезность будет близка к нулю, а может быть даже и отрицательной. Поэтому хотелось бы обратиться с просьбой к авторам, которые уже сделали или делают похожие решения: воспользуйтесь моим тестом и проверьте, а настолько ли полезна ваша разработка, как вы думаете.

Исходники тестов и тестовую выборку можно взять на гитхабе здесь. Также хочу обратиться к тем, кто планирует повторить мои эксперименты. Если вам удастся найти неточности или ошибки в алгоритмах, сообщите, пожалуйста, мне, я с готовностью буду вносить исправления и корректировать полученные результаты.

Ну а читателей благодарю за внимание. Буду рада ответить на вопросы в комментариях.
@ConceptDesigner
карма
13,0
рейтинг 0,0
Веб-дизайн, usability
Похожие публикации
Самое читаемое Дизайн

Комментарии (25)

  • +2
    Очень хорошая статья. Прямо бальзам на душу. Всегда и везде объясняем, что лучше дать пользователю ввести адрес сразу в одну строку, а потом проверить. И что побуквенный ввод имеет ряд принципиальных недостатков. К указанным выше я бы добавил:
    1.Необратимость ошибок. Если пользователь выбрал не ту строку — то узнать что же имелось ввиду невозможно.
    2.Что делать если нет такого элемента в КЛАДР/ФИАС.
    3.Что делать с латиницей.
    4.Совершенно нет никакой методики сортировки вывода, которая б удовлетворила всех.
    Кстати почему не включили в сравнение наш сайт  www.iqdq.ru? Хотя сразу скажу — у нас где-то 300-500 мс. В середнячки по подбору. Мы на разбор целой строки нацелены.
    • 0
      Все-таки мои эксперименты показывают, что польза от подсказок есть, особенно для людей, которые печатают не очень уверенно. Взять например, улицу Орджоникидзе. Лично мне тяжело ввести название этой улицы правильно без подсказок. Или другой пример. Адрес находится в каком-нибудь районе дальнего региона и пользователю тяжело ввести все правильно. А подсказки позволяют выбрать именно нужный адрес.
      По поводу сравнения с другими сервисами, я выложила исходники на гитхабе, так что можно добавлять новые модули для других сервисов и самостоятельно проводить тесты или попросить меня это сделать.
      • 0
        Тогда прошу и нас попробовать. Что б была объективная оценка и нашего сервиса, а не мои предположения как заинтересованного лица.
        Что касается ошибок, то я как раз и говорю. Пусть человек введет как может всю строку, с ОрджАникидзе или МоскАва. И после ввода разобрать всю! строку. А вот если нет однозначности — то да мы можем подсветить варианты. Нюанс в том, что имея всю строку — я резко сокращаю количество вариантов в случае неоднозначности. Оператору гораздо проще выбирать из двух-трех, чем в случае побуквенного ввода будет вываливаться полтора десятка.
        Собственно, то что я сейчас говорю проверено на работе операторов. Через нас ежедневно проходят сотни тысяч адресов. И мы пробовали разные версии интерфейсов для работы операторов. Идею подсказок отмели. Так как оператор очень быстро устает выбирать из большого количества вариантов при побуквенном вводе. Да и в разных случаях нужна разная сортировка. Где-то сначала город, где-то улица, а где-то хотелось бы населенный пункт.
        В общем при побуквенном вводе количество ошибок на порядок больше.

        Что касается тех, кто медленно вводит, то где-то могу согласится, хотя сегодня большинство людей довольно уверенно работают с клавиатурой даже в телефоне. Но вопросы остаются: какую сортировку подразумевает пользователь? Что делать с неполнотой эталона? Что делать с латиницей?

        Ну и технически: Надо понимать, что побуженный ввод это поисковый запрос к базе при вводе каждой новой буквы и сортировка! А это дорого. Даже с учетом хешей. А разбор строки целиком даже с учетом ошибок и опечаток — это один запрос.
        • 0
          Оператору гораздо проще выбирать из двух-трех, чем в случае побуквенного ввода будет вываливаться полтора десятка.
          В статье я указала, что выбор подсказки осуществлялся из пяти, а не из полутора десятков вариантов. Согласитесь, что пять все-таки ближе к вашим «двум-трем». Поэтому полагаю, что мой эксперимент приближен к реальности.

          В общем при побуквенном вводе количество ошибок на порядок больше.
          При выборе подсказок человек перестает набирать все буквы адреса. В моем эксперименте в случае успешной подсказки для города пользователю не приходилось набирать название региона, а это уже не мало. Город попадает в топ 5 подсказок примерно по трем первым буквам. Это вы видите из моей первой таблицы. А улица выбирается в среднем по первым двум буквам. Поэтому не понятно, почему при вводе 3+2 букв адреса количество ошибок растет.

          Надо понимать, что побуженный ввод это поисковый запрос к базе при вводе каждой новой буквы и сортировка! А это дорого.
          В статье я оцениваю полезность подсказок как процент времени, которое экономит пользователь. Пользователь может сэкономить 70% своего времени на операции ввода почтового адреса, это очевидная польза для человека и для владельца интернет-магазина. Поэтому я не могу разделить с вами беспокойство по поводу излишней нагрузки на сервера. В конце концов, вычислительные системы призваны помогать человеку, а не наоборот.
  • 0
    И да, есть канальные задержки. Каковы бы ресурсы небыли. Скорость интерфейса, тормоза машины и браузера. В общем все равно 4 буквы — это 400-500 миллисекунд в сумме. А разбор пусть и грязной строки — 10-100 миллисекунд в среднем.
    • +1
      Решительно не понятно, как так получается, что у вас 400-500 миллисекунд в сумме, при сотнях тысяч запросов в день. Вы используете mysql? Почему вы не кешируете данные в память? У вас скрипты на php? Посмотрите в сторону демона на golang, который держит всё сразу в памяти.

      Я сталкивался с такими задачами, и мой результат — 20-30мс. Цена вопроса — 3-4 дня.

      К слову, сортировали мы по частоте клика в тот или иной пункт (выбор аэропорта, билетный сервис).
      • 0
        Да, что-то много 500мс. Даже на 4 подбора.
        1. пробег от клиента до сервера 3-30мс (зависит от расстояния между пользователем и сервером)
        2. выборка из кэша первой буквы 1-5 мс
        3. пробег обратно 3-30 мс (зависит от расстояния между пользователем и сервером)
        Итого 7-65 мс. в большинстве случаев.
        Так 4 раза (от 7 до 65)х4 от 28 до 260мс.

        Хотя проще клиентско закешировать адрес и всё=)
        Чаще всего мы же 2-3 адреса вводим. Дом, работа и еще что нибудь.
      • 0
        Нет, у нас не PHP и не MySQL. С точки зрения сложности — побуквенный ввод задача действительно довольно примитивная. Это может написать любой мало-мальски способный программист. Поэтому ее продажа как сервиса мне всегда была странной идеей. Проще самим написать. На месте заказчика — так бы и сделал. Цифры я приводил в один поток на виртуальной машине. Реально конечно многопочность, конечно в памяти и конечно хеши. На счет 20-30 милисекунд — это на сервере, а есть еще формирование выборки, ее вывод. Короче накладные. И не забывайте — выборка первой, она может и 5 мс, но дальше все зависит от массы условий, в том числе от методов сортировки, количестве записей на вывод, канал, тормозами скриптов клиентской части. Вот и выходит — что 10-300 мс. В среднем выливаются в 100. Да собственно, приведенная автором статистика это и подтверждает. От 20 на город, до 200 на улицу и еще на дом. Надо ж суммировать подбор по всем уровням. А еще учитывать, что человек пробует первым вводить — область или улицу или населенный пункт, сервис подсовывает свою приоритетность. Ну допустим мои написанные 400-500 — это максимум. Пусть от 200 до 500. Пусть в среднем и 300. Ну а реально нашу скорость — можно потестировать на IQDQ.RU.
        Собственно, идеологически мне кажется лучше давать вводить в одну строку с ошибками и потом разбирать. Повторюсь, это мое частное мнение и оно как и любое другое может быть оспорено.
        • 0
          В итоге на почтовом конверте человек пишет СПб., и письмо нормально приходит в Питер, а на всяких самописных сайтах нужно вбить Санкт-Петербург как регион, потом перепробовать несколько вариантов с район/область, а потом ещё и вписать Санкт-Петербург как город :-)

          Переход с формальных описаний на естественный язык и обратно — вовсе нетривиальная задача.
          • 0
            Соглашусь. Нюансы есть. Сокращения, часто употребимые топонимы надо б коллекционировать.
        • 0
           Хотя вт замерили сегодня — с сервера у нас 30-50 милисекнд на сервере. Сам на себя наговорил. Тем не менее — концепция ввода строки «как есть» остается.
    • 0
      «Хотя сразу скажу — у нас где-то 300-500 мс. В середнячки по подбору.» Что то много 3-50 мс по факту.
  • –1
    Пользуясь случаем выражаю своё фе в адрес YouDo

    Мой адрес оно не жрёт. Произвольный адрес ввести нельзя. На карту ткнуть точку нельзя. В итоге приходится вводить только адрес улицы для заданий.

    А ещё (оффтоп) в графе «начать» подсказка к времени «укажите, когда задание должно быть выполнено». Но позвольте, ведь «выполнено» — это не начать, а закончить!
  • +1

    Браво! Масштабное исследование. Дополню немного (дисклеймер: я развиваю один из рассмотренных сервисов — Дадату).


    Польза от подсказок не лежит в вакууме, а определяется сценарием использования. Так, если речь идёт об адресе в интернет-магазине, нужен правильный почтовый индекс или координаты (для курьерской доставки). Индексы отдают только Дадата, Кладр в облаке и Фиас24. Координаты отдаёт только Дадата.


    Для расчёта стоимости доставки иногда надо знать район города. Дадата его отдаёт, остальные нет.


    Человеку удобно, когда ему в первую очередь подсказываются «локальные» адреса (из того города, где он находится). Дадата это умеет, остальные нет. Кстати, именно с этим связно отсутствие города Мирного в вашем тесте — видимо, вы не в Якутии ツ


    С точки зрения минимизации лишних телодвижений для человека максимум удобства достигается, если он может ввести адрес вообще в одну строку, не прыгая по полям. Для этого подсказки должны поддерживать ввод до дома или до квартиры. До дома из перечисленных сервисов умеют Дадата, Кладр в облаке, Фиас24 и Яндекс. До квартиры только Дадата.


    Как работают подсказки в Яндекс Картах, можно посмотреть на… Яндекс Картах, поэтому ссылку на «демо» давать не буду.

    А зря, потому что SuggestView намного «тупее», чем Яндекс-карты. Демка его здесь: https://tech.yandex.ru/maps/jsbox/2.1/search_control_ppo

    • 0
      Не только Дадата делает это. И индексы и качество. Поэтому «только» это мягко говоря — преувеличение. Зачем обманывать людей?
    • 0
      Мы в Ахантере не стали вываливать в подсказки кучу дополнительной информации, о которой вы пишите, т.к. считаем, что пользы от неё именно в подсказках нет.

      Вот, например, какая польза от того, что человек в подсказках увидит индекс и район города? Это ведь лишняя информация, которая только мешает человеку искать среди подсказок свой адрес. Подсказка должна быть предельно лаконичной, именно тогда от неё будет польза.

      Координаты, индекс и прочую информацию об адресе можно получить уже после того, как пользователь завершит вводить адрес. Для этого у нас есть отдельное API. Собственно также можно поступать, используя другие сервисы, о которых здесь написано.

      По поводу «локальных адресов», чаще всего магазины доставляют по своему городу, вряд ли вы будете пиццу заказывать во Владивостоке. В этом случае правильнее не рассчитывать на геолокацию по IP-адресу, а просто зашить ограничение на город в самом интернет-магазине. Это можно сделать с любым из рассмотренных сервисов. Гораздо хуже, как мне кажется, когда в подсказках вместо «города Березовский» вываливается «Березовский сельский р-н». Не понятно, почему вы это позиционируете, как фичу?

      По поводу номеров домов и квартир. Вы серьезно считаете, что человеку нужны подсказки для его дома и квартиры? Выше я написал про лаконичность, на мой взгляд, когда перед пользователем вываливается избыточная информация, он начинает отвлекаться на неё, как результат одну-две цифры своего номера он вводит дольше с подсказками, чем без них. Интересно, у вас есть свои оценки полезности подсказок для домов, можете их привести? Может быть мы тогда тоже добавим эту возможность у себя.

      Ну а возможность ввести адрес одной строкой есть, вроде бы, у всех сервисов, про которые тут сказано. По крайней мере, в Ахантере вводить дом и кваритру в одну строку с адресом можно без проблем, поэтому с «минимизацией лишних телодвижений для человека» тут полный порядок.
      • 0
        Согласен с коллегами, мы тоже придерживаемся в этом вопросе схожей идеологии. Хотя подбор домов добавили сразу.
      • 0
        Автору спасибо за статью, она шикарная, очень интересный подход к тестированию автокомплита.
        Ребята из Ахантера, я вот ваше API тестировал для имен (и даже в похожей статье сравнения вас упоминал), а потом для адресов. С именами ладно, вот по адресам много вопросов к вам возникло тогда :) А сейчас читаю ваш коммент и, простите, не удержусь его разобрать публично:

        Вот, например, какая польза от того, что человек в подсказках увидит индекс и район города?


        Про индекс не знаю, а вот про районы очень даже знаю :) Мне были нужны районы городов, чтобы стоимость доставки считать, а вы в них не умеете.

        чаще всего магазины доставляют по своему городу


        Что значит «чаще всего»? :) Много кто доставляет по всей России, потому что отправляет товар почтой по всей России. Будем предлагать пользователю выбрать город руками?

        Координаты, индекс и прочую информацию об адресе можно получить уже после того, как пользователь завершит вводить адрес. Для этого у нас есть отдельное API.


        То есть вы мне под предлогом «избыточности» отдаете куцые данные, а если мне надо больше данных – предлагаете для решения задачи юзать ваше платное API стандартизации адресов, прикручивать на бэкенд дополнительную логику обработки адресов, и считаете что это окей и называется «можно получить»? :) Нет, нельзя, во всяком случае очень неудобно. Зато есть офигенно полезный параметр request_process_time.

        По крайней мере, в Ахантере вводить дом и кваритру в одну строку с адресом можно без проблем


        Можно узнать, как? Мне вот ваше API Подсказок отдает пустой ответ на «санкт-петербург ул 2 жерновская д 26».
        • –1
          Мне были нужны районы городов, чтобы стоимость доставки считать...
          Подскажите, а в каких городах РФ стоимость доставки зависит от района города? Я сам в Москве живу, и где бы я не находился, доставка мне всегда обходится в 300 рублей, независимо от района. Вопрос без иронии, просто хочу понять, насколько ваш кейс распространён.
          А по существу вашего вопроса, я не понял какое отношение расчёт стоимости доставки имеет к тому, что пользователь видит в подсказках? Выше я написал про избыточность информации, которая мешает пользователю искать свой адрес. Вот давайте вернемся к примеру с «городом Березовский», покупатель видит подсказку для него «г Краснодар, Березовский сельский р-н». Сколько пользы получит он от такой подсказки?

          Что значит «чаще всего»? :) Много кто доставляет по всей России, потому что отправляет товар почтой по всей России. Будем предлагать пользователю выбрать город руками?
          Я сослался на пример про пиццу, как на пример местечкового магазина, который не рассчитывает продавать продукцию в соседние города. Мне кажется, что таких маленьких магазинов по статистике больше, чем крупных, которые ориентированы на охват всей России. Возможно, я ошибся, если у вас есть иная статистика, приношу извинения. Ну а касательно крупных магазинов, в которых пользователь заказывает из другого города, то, на мой взгляд, проблемы указать свой город явно здесь нет. Цена вопроса, вроде бы, две-три буквы. Наоборот, пользователь видит явно свой город, его уверенность в том, что он делает всё правильно растёт. Это, конечно, вопрос юзабилити и здесь важно мнение конечных пользователей. Тем не менее, мне кажется, это лучше, чем получать «проезд Мирный 2-ой» вместо «города Мирный».

          То есть вы мне под предлогом «избыточности» отдаете куцые данные, а если мне надо больше данных – предлагаете для решения задачи юзать ваше платное API стандартизации адресов
          Здесь каждый для себя выбирает сам. Либо вы платите за подсказки, либо платите за проверку адресов в уже оформленных заказах.На Ахантере вам не надо платить за подсказки и не играет никакой роли, в каком количестве ваши покупатели нащёлкают их у вас на сайте. Да, в нашем случае вам придётся заплатить 10 копеек за получение координат и прочей информации об адресе. Но заказ-то уже оформлен, неужели 10 копеек сильно снизят вашу прибыль от него?

          Можно узнать, как? Мне вот ваше API Подсказок отдает пустой ответ на «санкт-петербург ул 2 жерновская д 26».

          Вот так у нас на сайте выглядит ввод вашего адреса.



          Как видно, подсказки появляются без проблем. После выбора вашей улицы просто вбейте номер дома в конце строки. Подсказки для номеров домов вы там не увидите, т.к. мы считаем их бесполезными, поскольку полагаем, что человек больше времени тратит на поиск и выбор своего дома в предложенном списке. Я об этом выше написал. Если у вас есть другой опыт, поделитесь, пожалуйста, а мы со своей стороны охотно добавим этот функционал в наш сервис.
    • 0
      Дадата как можно утверждать что вы круче всех, если не перечислили всех конкурентов. По крайней мере это не порядочно. И навивает мысли а почему умалчиваем а?

      Я понимаю что создатель данной ВЕЛИКОЛЕПНОЙ (без иронии) статьи мог про нас и не слышать, но вы то нас хорошо знаете.

      Что касается вывода доп параметров так Ахантер Вам ответил. Это дело 5 минут и выделанного яйца не стоит для программистов. Вопрос в потребности.
      • 0
        Я понимаю что создатель данной ВЕЛИКОЛЕПНОЙ (без иронии) статьи мог про нас и не слышать
        Да, ваш сервис с ходу не попался на глаза. Постараюсь включить его в обзор в ближайшие выходные.
        • 0
          Да будет интересно. Как я уже говорил сервис на ms sql написан за пол дня. посему любые замечания для нас будут очень Важны. к тому же он у нас бесплатен от слова совсем и даже не планируем его делать платным. Кому интересно могу в личку прислать исходный код
  • 0
    Автору статьи большой респект.

    Чисто из любопытства, подскажите сколько дней вам потребовалось, чтобы выполнить тест для Google с учётом обозначенных квот?

    Вообще по всем сервисам интересно, удалось ли уложиться в лимиты или тест длился несколько дней?
    • 0
      В анонимные квоты гугла уложиться, конечно, не получилось. А вот лимита в 150 000 запросов хватило, так что весь тест удалось выполнить за один день. Суммарно по остальным сервисам весь эксперимент прошел за 3 дня.
  • 0
    По просьбе нескольких читателей я добавила в статью обзор еще одного сервиса. Соответствующие исходники также залила на гитхаб.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.