Я более двух лет в теме того, как пользователь совершает покупку билета, и постараюсь показать, насколько сильно можно сэкономить время, используя бота в связке с децентрализованными приложениями.
Ликбез
- ю — пользователь
- б — бот или браузер
- а — ассистент
- dApps — децентрализованное приложение
Шаг 1: Поиск сайта
На поисковую выдачу тратится колоссальное время разработчиков и гигантский бюджет для SEO-продвижения. Поисковые роботы учитывают все: правильность семантической верстки, время загрузки страницы, ARIA доступность, скорость выполнения скриптов.
| Browser | Bot |
ю: <Запрос> "купить билет на концерт в Москве" б: <Страница поиска>
| ю: <Запрос> "бот, хочу пойти на концерт в Москве" б: <Ответ> "Соединяю с московским ассистентом покупки билетов..." |
От 10 секунд до 2 минут. Поисковые машины хорошо оптимизировали процесс ввода, они исправляют ошибки запроса и используют историю поиска с последними наработками графовых БД. Но в то же время появились новые проблемы, которые невозможно решить в сложившейся архитектуре: обилие рекламы и утрату конфиденциальности. | До 2 минут. Бот детектирует запрос и перенаправляет пользователя к связанному ассистенту. Каждый ассистент подключен к «семье», которую выбирает пользователь при старте бота, что позволяет вернуть прежде утраченную функцию региональных доменных имен. Список ассистентов в «семье» прозрачен и доступен каждому. Благодаря такой архитектуре ассистенты могут быстрее определяться и в случае проблем блокироваться клиентами «семьи». |
Поисковые системы давно стали влиятельными игроками. Теперь это не просто главная страница интернета, но и браузер, и ОС. Не побоюсь предположить, что технологии AMP/Turbo лишь усилят их влияние, усложнив жизнь обычным сайтам, которым придется отдавать все больше данных поисковым гигантам. Даже предположив, что поисковики все делают ради общего блага, и будут добросовестно контролировать, например, процесс оплаты (как это уже делает гугл с их роботами), система ботификации остается более гибкой. Ведь архитектура позволяет добавить множество отдельных ассистентов для дополнительной валидации, допустим, проверки контрагентов, что может заметно увеличить доверие к третьим лицам.
Шаг 2: Поиск билета на сайте
Мало найти сайт с билетами, требуется найти сам билет на сайте. А для этого следует дождаться когда произойдет полная загрузка страниц, когда пользователь изучит структуру и поведение сайта.
| Browser | Bot |
| ю: <Заходит на Sitename A> б: <Отображение сайта в формате HTML> <h1>Афиша</h1><h2>Возможно вам понравится</h2><h3> The Glitch Mob</h3> <h3>…</h3> | ю: <Предоставляет ассистенту выборочную историю своих персональных данных, доступ на чтение прежде купленных билетов>
а: <Ответ> Рекомендую: "The Glitch Mob", "..." |
| От 30 секунд до 2 минут. Интернет пережил время, когда UX/UI не уделялось никакого внимания. Теперь же появился специалист по тому, чтобы сайты использовали приятные цветовые гаммы и привлекательный визуал. Структура сайтов пришла к некой общей единой форме: сайдбар, хедер, футер и блок с заголовками. Но в погоне за новыми технологиями Open Web Platform, сайтописатели стали нагружать их ненужной или даже вредной функциональностью: обилие отзывов, лайков, запросов на геолокацию, нотификацию и т.д. В связи с этим даже средний сайт стал загружаться за 5+ секунд. Новому пользователю следует потратить не менее 20 секунд, чтобы разобраться в работе сайта и еще время, чтобы найти необходимый билет. | До 1 минуты. Ассистент предлагает тебе определенного артиста, основываясь на предоставленной истории твоего профиля, на законодательных и правовые актов региона/города и даже культуры принятой в «семье». Так из коробки решаются проблемы возрастной и культурной цензуры. Идея бота в сквозной семантичной связке и постоянном машинном обучении собственной истории, позволяет выполнять поиск все более ожидаемого билета. Исторические графовые связи помогают находить наилучшие варианты артиста и организатора, проверяя его кредитный рейтинг, отзывы, сверяя портреты рекомендаций. |
Множество сайтов продолжают быть недоступными для людей с проблемами в восприятии. В любой момент сайт может «лечь» из-за наплыва пользователей, сетевого перебоя или ошибки скрипта. Тогда выйдет, что пользователь зря потратил свое время, ему предстоит вернуться снова после заплатки и никто не оповестит ему когда сайт будет работать.
В новом мире где работают децентрализованные ассистенты и боты ситуация кардинально отличается. Интерфейсом является привычный диалог. Контент становится лаконичным и информативным. Постоянное потребление информации и удержание пользователя уходит из веб-серфинга. Даже крупная ddos-атака мало что способна будет разрушить.
Шаг 3: Покупка билета
Процесс оплаты это вечная проблема для сайтодержателей. Системы мобильных платежей от Google, Apple, а также электронные кошельки вроде PayPal, в разы ускорили надежность и скорость выполнения оплаты. Но сам процесс бронирования это то, где постоянно возникают технические сложности и серьезные UX просчеты.
| Browser | Bot |
| ю: <Изучает сайт> б: <Шаги выбора места и оплаты> ю: <Ввод данных с карты>б: <Подтверждение транзакции> | ю: <Добавление пожеланий>
"давай на завтра"«примерно к 21:00» а: <Процесс общения с ботом>
ю: <Выбор Name 1 и отправка смарт-контракта> |
| От 5 минут до 20 минут. Последовательные сцены выбора места утомляют: ориентируясь на макет виртуального зала, который редко бывает информативен, фактически, пользователь выбирает все наугад. Более подкованные пользователи непременно прямо перед вводом еще раз проверят шифрование по https и рейтинг организатора, а также юридическое лицо. | До 10 минут. Процесс выбора билета становится автоматизированным. Бот обучаясь на пользовательских ощущениях и на предоставленных ассистентом анонимных данных, будет подбирать ровно то место, где пользователю будет обеспечен максимальный комфорт. В качестве фолбэка, когда существует неясность, происходит дополнение через ту же самую диалоговую систему, которая вкупе со знаниями по истории, позволит грамотно подбирать билеты таким образом, чтобы пользователь остался доволен. |
Оплата dApp построенная на блокчейне и может достигать до 10 минут. Но стоит дополнить, что валидация той же MasterCard выполняется в течение суток.
Но фишкой здесь выступает еще и то, что благодаря смарт-контрактам, деньги могут быть настроены на списывание только в момент реального получения концертной или иной услуги, что позволит на порядок увеличить лояльность пользователей и заранее наказывать нерадивых оргов.
Шаг 3: Создание напоминания
Процесс структурирования напоминаний был недавно упомянут в соответствующей новости, и потребует определенного набора действий и настройки приложений.
| Browser | Bot |
| б: <Письмо отправляется на почту> ю: <Занесение события в календарь> | б: <Получение ссылки на транзакцию и запись в пользовательскую историю> ю: <Моментальный пуш; опциональная конвертировать в формат ical> |
| От 1 минуты до 5 минут. Стандарт почтовых писем прямо скажем, устарел. Он гибкий и мощный, но работает недостаточно быстро. Бывает, отправленное письмо, проходя через кучи спам-фильтров и серверов, достигает адресата за минуты. | Мгновенно, в худшем случае до десятка секунд. Функционал напоминаний полностью вшит в функционал бота, ведь напоминания это частный случай истории. Я понимаю фолбэк пока еще необходим, и поэтому конвертация истории в форматы вида ical должны оставаться. |
Используя IPFS получится сделать распределенный хостинг историй для каждого пользователя, на каждом его умном устройстве, будь то умные часы, планшет или мобильный телефон. Это обеспечит надежную сохранность данных в случае гибели какого-то одного устройства. Ярким плюсом такого подхода станет то, что данные не будут находиться в облаках корпораций, что в значительной мере уменьшит возможность их «слива».
Итоговые замеры времени
| Browser | Bot |
| От 6 минут до 29 минут. | До 14 минут. |
Теоретические замеры дают прирост времени более чем в два раза. Немаловажным становится то, что идея бота позволит добавить конкуренции на рынок, сформировав кардинально иное взаимодействие с интернетом.
