dapp

Bot ➕ ĐApp ❤️ E-commerce

9 августа, 2020
4 минут(ы) чтения

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

Ликбез

  • ю — пользователь
  • б — бот или браузер
  • а — ассистент
  • dApps — децентрализованное приложение

Шаг 1: Поиск сайта

На поисковую выдачу тратится колоссальное время разработчиков и гигантский бюджет для SEO-продвижения. Поисковые роботы учитывают все: правильность семантической верстки, время загрузки страницы, ARIA доступность, скорость выполнения скриптов.

BrowserBot
ю: <Запрос>
"купить билет на концерт в Москве"

б: <Страница поиска>

  • Sitename A
  • Sitename B
  • Sitename Z
ю: <Запрос>
"бот, хочу пойти на концерт в Москве"

б: <Ответ>

"Соединяю с московским ассистентом покупки билетов..."

От 10 секунд до 2 минут.


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

До 2 минут.

Бот детектирует запрос и перенаправляет пользователя к связанному ассистенту. Каждый ассистент подключен к «семье», которую выбирает пользователь при старте бота, что позволяет вернуть прежде утраченную функцию региональных доменных имен. Список ассистентов в «семье» прозрачен и доступен каждому. Благодаря такой архитектуре ассистенты могут быстрее определяться и в случае проблем блокироваться клиентами «семьи».

Поисковые системы давно стали влиятельными игроками. Теперь это не просто главная страница интернета, но и браузер, и ОС. Не побоюсь предположить, что технологии AMP/Turbo лишь усилят их влияние, усложнив жизнь обычным сайтам, которым придется отдавать все больше данных поисковым гигантам. Даже предположив, что поисковики все делают ради общего блага, и будут добросовестно контролировать, например, процесс оплаты (как это уже делает гугл с их роботами), система ботификации остается более гибкой. Ведь архитектура позволяет добавить множество отдельных ассистентов для дополнительной валидации, допустим, проверки контрагентов, что может заметно увеличить доверие к третьим лицам.

Шаг 2: Поиск билета на сайте

Мало найти сайт с билетами, требуется найти сам билет на сайте. А для этого следует дождаться когда произойдет полная загрузка страниц, когда пользователь изучит структуру и поведение сайта.

BrowserBot
ю: <Заходит на 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 просчеты.

BrowserBot
ю: <Изучает сайт>

б: <Шаги выбора места и оплаты>

ю: <Ввод данных с карты>

б: <Подтверждение транзакции>

ю: <Добавление пожеланий>

"давай на завтра"
«примерно к 21:00»

а: <Процесс общения с ботом>
б: <Фильтрация времени, сверка цены, учет и формирование смарт-контракта>

Ваш запрос сформирован:
  • [name; цена: $$; место: xxx, рейтинг: ★] 
    [name …]

ю: <Выбор Name 1 и отправка смарт-контракта>

От 5 минут до 20 минут.

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

До 10 минут.

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

Оплата dApp построенная на блокчейне и может достигать до 10 минут. Но стоит дополнить, что валидация той же MasterCard выполняется в течение суток. 

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

Шаг 3: Создание напоминания

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

BrowserBot
б: <Письмо отправляется на почту>
ю: <Занесение события в календарь>
б: <Получение ссылки на транзакцию и запись в пользовательскую историю>
ю: <Моментальный пуш; опциональная конвертировать в формат ical>
От 1 минуты до 5 минут.

Стандарт почтовых писем прямо скажем, устарел. Он гибкий и мощный, но работает недостаточно быстро. Бывает, отправленное письмо, проходя через кучи спам-фильтров и серверов, достигает адресата за минуты.
Получить письмо с квитанцией недостаточно, его нужно либо распечатать, либо сохранить отдельно на телефон, что требует дополнительного времени.

Мгновенно, в худшем случае до десятка секунд.

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

Я понимаю фолбэк пока еще необходим, и поэтому конвертация истории в форматы вида ical должны оставаться.

Используя IPFS получится сделать распределенный хостинг историй для каждого пользователя, на каждом его умном устройстве, будь то умные часы, планшет или мобильный телефон. Это обеспечит надежную сохранность данных в случае гибели какого-то одного устройства. Ярким плюсом такого подхода станет то, что данные не будут находиться в облаках корпораций, что в значительной мере уменьшит возможность их «слива».

Итоговые замеры времени

BrowserBot
От 6 минут до 29 минут.До 14 минут.

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

Денис Сергеевич Басковский

Философ, изобретатель и поэт.

Подписаться
Уведомить о
guest
0 комментариев
Межтекстовые Отзывы
Посмотреть все комментарии
wasting time
Предыдущая статья

Планинг управления З.А.С.О.С.

botification
Следующая статья

Что такое ботификация?