{"id":7297,"title":"\u0417\u0430\u043a\u0430\u0442\u0438\u043b\u0438 \u0432\u0435\u0447\u0435\u0440\u0438\u043d\u043a\u0443 vc.ru. \u0420\u0430\u0441\u0441\u043a\u0430\u0437\u044b\u0432\u0430\u0435\u043c \u0438 \u043f\u043e\u043a\u0430\u0437\u044b\u0432\u0430\u0435\u043c, \u043a\u0430\u043a \u044d\u0442\u043e \u0431\u044b\u043b\u043e","url":"\/redirect?component=advertising&id=7297&url=https:\/\/vc.ru\/promo\/300923-proveli-vecherinku-vc-ru-i-sdelali-ofis-uyutney-s-pomoshchyu-novogo-servisa-ot-ozon&placeBit=1&hash=1786c9dcf11a3b054c8e53004e27074664313ed4055e24064ede059ebc186db8","isPaidAndBannersEnabled":false}

Год на MVP. Как и почему мы делаем сервис кнопочных диалогов КвикСпик

Приветствую, меня зовут Вячеслав Устинов, руководитель агентства, ориентированного на мед.проекты и сферу услуг. Пишем системы аналитики, управляем проектами и IT-процессами наших клиентов. Специфика работы располагает к экспериментам. Один из таких перерос в разработку конструктора лендинг-ботов с кнопочным диалогом QuickSpeak.me (Квик), над которым активно работаем уже около года.

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

Особенности сервиса — в алгоритме диалога и в способах его сборки.

О чем этот сервис и какие проблемы решает

Технически, это механики бота с кнопочным диалогом, адаптированные под веб.

Идеологически, Квик позволяет:

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

Если есть понимание о чем писать, квик собирается за 10-30 минут.

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

И главное, ради чего и был задуман сервис — расширение возможностей в таргетинге.

О чем расскажу на примере из нашего опыта.

Медицина, с которой мы в основном работаем — сама по себе непростая тематика. Много ограничений, дорогие запросы в горячих кластерах, бесполезные запросы в холодных.

Если ну очень упрощенно, кластеры медтрафика можно раздробить на 4 группы:

  • Натив и фамилии докторов

Натив, то что напрямую связано с определенным медицинским центром. Название клиники, название + адрес, название + расписание и т.п. Трафик по докторам - фактически, тот же самый натив. Поиск по фамилии доктора с целью записи к нужному специалисту. Люди из данного кластера уже точно знают кто им нужен и в рамках своих поисковых запросов/намерений решают проблему.

Здесь вопрос плейсмента закрывается основным сайтом/сайтами + медицинскими агрегаторами.

  • Направления и приемы — основное конкурентное поле

Условно, человек уже точно знает, что ему нужен доктор определенной специальности и ведет поиск на заданном уровне без уточнения фамилий и клиник. Трафик условно горячий. Большинство МЦ активно борются за клиента на этом уровне поиска. Здесь серьезная конкуреция, хорошая конверсия в лид.

Я написал скрипт для телеги, который рассчитывает в нон-стоп режиме суточное присутствие игроков по директу во множестве тематик (по часам) — ниже скрин. Кое-кто из этого списка тратит на направление 100+ (на очень компактный пласт горячих запросов с показами в регионе), а его полоса присутствия почти незаметна (на графике чем жирнее полоса, тем больше объем присутствия). То есть - масштабировать горячий пласт — дорого, особенно для небольших клиник.

  • Фарма

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

  • Холодные запросы

Симптоматика и все что ниже. То, с чего начинается решение большинства проблем, но до конкретного лечения еще далеко. Здесь дешевый холодный трафик и хорошее поле для SEO. Но тратить эффективно рекламный бюджет в этом сегменте проблематично. А с точки зрения SEO, влияние на результат, даже в долгосрочной перспективе, не самое выдающееся. Ниже — график с приведенной SEO-динамикой за счет успехов в индексации инфо-контента по одному из мед-проектов.

Объемы (по гуглу) неплохие, но влияние на запись в клинику непропорционально этому графику.

В итоге. Есть проблема. Имеется инфо-трафик. Его много — хочется работать с ним эффективнее.

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

Появилась гипотеза и идея:

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

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

Заложенный концепт реализовали довольно быстро. Сначала - в telegram простеньким скриптом за пайтоне (для проверки и сборки алгоритма), а потом перевели в веб.

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

Идею из теста смасшбировали на другие медицинские ниши:

  • на эндоскопию начали вести людей с широким таргетом 40+ с итоговым CTR 0.45-1% в запись на первом взаимодействии, что неплохо с учетом дешевизны аудитории и высокой стоимости эндоскопии + полипэктомии;
  • на лечение геморроя — аудитории профессиональных водителей; в т.ч. куда более успешно, чем ранее, монетизировали запросы из фарм-кластера “свечи и подушки от геморроя”;
  • получили результат с трафика по часто путешествующим на самолете людям на флебологию;
  • получили запись на лечение лишнего веса к психотерапевту и т.п;
  • по итогу, нарастили объем покупки холодного трафика для ряда компаний.

Кнопочный диалог оказался не столько инструментом, который может гарантировать “шквал лидов”, сколько способом получить качественные заявки. Форму в интерактиве заполняют не ради интереса, а на основе рационального вывода. Менеджер/колл-центр получает не холодный контакт, а пользователя, которому уже понятна суть и требуется информация в рамках индивидуальных вопросов.

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

  • выстроить эффективную монетизацию холодной аудитории (зачастую, в один шаг);
  • гармоничнее распределить бюджеты между плейсментами и форматами аудиторий;
  • существенно поменял нашу работу — для многих внутренних задач мы стали использовать квик, что улучшило внутри наши процессы разработки (стали меньше распыляться, ушли в код по определенному продукту).

Как все работает внутри

Особенность диалогов, как писал в начале — в нелинейности. То есть, двигаясь внутри реплик, пользователь с каждым шагом не ограничивает себе дальнейшие варианты коммуникации, а может получить по ходу диалога (но разными путями) весь структурированный контент, который реализован в сценарии (но ветвление с невозвратными сценариями также можно настраивать - проблем нет).

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

Все это делается без особых проблем. Сами мы предпочитаем собирать интерактив в таблицах, а редактор использовать для внесения быстрых корректировок.

Чуть подробнее о матричном варианте

В диалоге реализуется принцип “ключ-значение”, где вопрос является ключом, а реплика - ответом на этот вопрос. Сам вопрос состоит из видимой и невидимой частей, что позволяет использовать одинаково звучащие вопросы в диалоге, ведущие на разные реплики. (вместо этого варианта можно было бы использовать просто дополнительные идентификаторы и ориентироваться по ним, но выбрали текущий вариант для лучшей читаемости диалогов, собранных с помощью таблиц).

Как связаны реплики (простая схема)
Как связаны реплики с учетом использования доп-идентификаторов при одинаково звучащих вопросах.

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

В дальнейшем есть желание реализовать более эффективные автоматизации.

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

Но у матричной структуры диалога есть один очевидный недостаток - возможность повтора реплик

Его решили надстройкой, скрывающей просмотренные варианты, если обратное не приведет к поломке самого диалога.

UX

UX мы не стали развивать в сторону классических чат-ботов. Здесь нет искусственных задержек между контентом (на мой взгляд, имитация человеко-печати и паузы между сообщениям — архаизм и лучше его избегать).

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

Технологии

Бэкенд крутим на Джанго. Сейчас присматриваемся к связке Django + Go + Reddis ради хороших скоростей. Также GoLang позволит нам реализовать нормальную встроенную аналитику на проекте (выше скорость — точнее данные).

Использование сервиса и дальнейшее развитие

Первоначально мы определили несколько итераций MVP:

  • Проверка гипотезы, что порционная подача контента в заданном формате действительно будет эффективной (для проверки самой идеи продукта);
  • Получение регистраций при минимальных охватах рекламных кампаний. Здесь 2 гипотезы - первая, что сервис понятен не только нам, но и холодной аудитории, и что тестовая рекламная кампания не даст условный максимум регистраций (если бы РК дала регистрации, но на большом охвате, то конечно о масштабировании в дальнейшем речи идти не может);
  • Вовлеченность в кабинет, работа внутри.

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

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

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

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

Что есть на текущий момент:

  • Завершенный MVP 2 (хотя это мы себе говорим каждые пару недель, а потом ставим в приоритет разработки очередной вагон тасков, без реализации которых нам кажется что ничего не готово))
  • Функциональный кабинет с возможностью загрузки таблиц и визуальным редактором;
  • Системы премодерации, чтобы снизить объем ручных проверок публикуемого контента;
  • Механики оформления с настройкой цветовой палитры и вспомогательных блоков;
  • Документация и все к ней сопутствующее (не всегда успевает за изменениями, но в целом, читаемая);
  • Возможность использования квика не только в качестве лендинга, но и как виджета, или встраиваемого блока на сайте. (iframe как виджет и статичный формат готовы и применяются, скрипт - в работе);
  • Тесты в нишах в т.ч. за пределами медицины (девелопмент, сфера обучения, бьюти услуги). Кстати, отдельно про бьюти услуги - зашло хорошо, но с справедливости ради — это сравнительно легкие офферы и с ними можно придумать еще миллион доступных способов эффективной работы;
  • Возможность развертывания квика на собственном хостинге (часть кода на хостинге - часть на стороне нашего сервера).

Что было реализовано, но на определенных этапах отсечено:

  • Статичное расположение кнопок (убрали в борьбе за максимальное пространство экрана под контент реплик, хотя в целом старое решение до сих пор кажется неплохим, не считая лишнего 1% отказов по тестовым квикам);
  • Тонны лишней анимации;
  • Механики историй в диалоге (заменили на кнопку “Подробнее”) под развернутый контент.

Планы

  • Придумали как внутри логики диалога и заданного шаблона таблиц реализовать интернет-магазин и легко обновлять цены. Есть гипотеза, что для бутикового формата с малым ассортиментом, или продаж сложных товаров/услуг встраивание механизма продажи в диалог может быть эффективным решением;
  • Также, с учетом формата таблиц, нашли массу поводов реализовать механику, схожую с вордпрессовыми шорткодами с возможностью создания своих функций на пользовательском уровне (придумана масса вспомогательных вещей, которые классно спрячутся в короткие команды)
  • Встроенная система анализа данных. Любим писать скрипты аналитики, и в целом много работаем с цифрами и построением предиктивных моделек, так что, надеюсь, сможем хорошо адаптировать наш опыт под Квик + крайне интересно задействовать GoLang на этом этапе (получение нами нового опыта);
  • Автоматизацию построения диалога через алгоритм с самообучением на паст-дате (пользователь пишет реплики, алгоритм сам выстраивает эффективные сценарии диалога исходя из набранных данных)
  • Как и любой стартап, работаем над выходом сервиса на зарубежные рынки) Есть стратегия и понимание процессов выхода на турецкий рынок и конечно - запад.

Собственно, пощупать квик можно по ссылке - https://quickspeak.me

Буду рад вашим тестам и обратной связи. Возможно, где-то сыровато. Если что найдется/упадет — поправим)

{ "author_name": "Вячеслав Устинов", "author_type": "self", "tags": [], "comments": 3, "likes": 4, "favorites": 11, "is_advertisement": false, "subsite_label": "tribuna", "id": 251461, "is_wide": true, "is_ugc": true, "date": "Thu, 27 May 2021 18:17:55 +0300", "is_special": false }
0
3 комментария
Популярные
По порядку

Я тоже теперь хочу такой сделать! Рассказывайте о ходе продвижения.

0

Спасибо, потом напишу по маркетингу сервиса и результатам) Ну и буду ждать обратной связи по удобству кабинета)

0

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

0
Читать все 3 комментария
Cloud CDN: что это такое, как устроено и кому нужно. Разбираем на примере бургеров

Cloud CDN — это сеть быстрой доставки статического контента в формате услуги облачного провайдера. Объяснить, как работает технология, проще всего на примере — сравнить Cloud CDN с популярным продуктом, который выглядит плюс-минус одинаково вне зависимости от того, заказали вы его в Москве, Питере или Нью-Йорке. Знакомьтесь: классический бургер.…

Роботы-курьеры «Яндекса» начнут доставлять посылки «Почты России» в Москве Статьи редакции

Пока заказать доставку можно через приложение «Почты России» на Android в некоторых районах города.

Робот-курьер «Яндекса»
КЕЙС: Как с 4000 рублей рекламного бюджета сделать продаж на 115 тысяч рублей
Рынок кикшеринга в России вырос на 200-230% за год, до 12 млрд рублей — исследование Статьи редакции

Но есть и проблемы: производители не успевают делать достаточно самокатов, компетентных сотрудников не хватает, а в СМИ кикшеринг «демонизируют».

«Крутые ИТ-стартапы запускают не только в Кремниевой долине»: путь Insider от офиса в квартире к $47 млн инвестиций

За 9 лет разработчик маркетинговой платформы из Турции открыл филиалы в Польше, Вьетнаме, Индонезии, Дубае, России, Австралии и ещё 19 странах, а в будущем планирует оценку в $2-3 млрд и выход на IPO.

Региональные аэропорты предупредили о возможной приостановке полётов из-за новых правил безопасности Статьи редакции

Чтобы соответствовать новым требованиям, аэропорты должны вложить 3-4 млрд рублей, а затраты могут не окупиться.

7 причин начать пользоваться Bright Data Proxy Manager:
ПСБ запустил личный кабинет для предпринимателей. Там можно следить онлайн за каждым своим терминалом

Сервис предоставляется бесплатно.

Как не попасть в карьерную ловушку тимлида: личный опыт

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

Как OTUS стал платформой для самореализации. История преподавателя

Наш преподаватель, специалист по Data Science, решил поделиться своей историей преподавания. Он рассказал, как пришел в эту сферу, с какими трудностями столкнулся на пути к преподаванию и что ему помогает. А еще поделился советами, как поддерживать внимание студентов и сделать занятия полезными и увлекательными.

null