Как создать чат своими руками

Создание чата для сайта

Из этого материала вы узнаете:

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

Что представляет собой онлайн-чат

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

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

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

Зачем нужен чат

И это еще не все преимущества чата на сайте. В нем проще обмениваться цифровой информацией, наименованием моделей, номерами счетов. Виджет также поддерживает отправку файлов в форматах картинки, текста, голосового сообщения. Менеджеры свободно общаются одновременно с двумя и более клиентами. Чат на сайте – инструмент для повышения конверсии этапа воронки после клика по рекламе или ссылке в поиске. Трафик всегда ограничен семантикой, бюджетом на продвижение, что и приводит к внедрению решений по увеличению отдачи от каждого посетителя. Статистика пользователей чатов показывает, что их применение увеличивает средний чек, экономит время на возврат товара, снижает риски жалоб, негативных отзывов из-за длительного ожидания ответа. Клиент обрабатывается на момент «горячей» заинтересованности, а не потом, когда у него появились другие неотложные дела, или его успел забрать себе конкурент.

Преимущества для бизнеса

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

Руководитель (владелец) бизнеса получает:

• снижение затрат на обработку заказов;
• возможность онлайн-отслеживания разговоров;
• создание базы для рекламных рассылок.

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

Как сделать чат эффективным

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

1. Подготовьте список часто задаваемых вопросов. При использовании чат-бота ответы на них будут отправляться автоматически.
2. Подключите чат к CRM, e-Commerce. Интеграция канала в систему сквозной аналитики дает возможность получать оперативные данные по работе отдела продаж, подробные отчеты.
3. Используйте программный интерфейс API. Он заметно упростит интеграцию со сторонними сервисами.

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

Специальные функции онлайн-чата

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

Нужна ли интеграция с дизайном

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

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

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

Готовое решение или отдельная разработка?

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

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

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

Этапы создания чата для сайта

Перед составлением технического задания на создание чата в обязательном порядке проводится аудит бизнес-процессов. Это позволяет полностью оценить имеющуюся IT-инфраструктуру, чтобы новый продукт соответствовал концепции организации Data Driven. Такой подход дает возможность перевести бизнес на цифровой формат, когда любое решение принимается согласно точным данным.

Шаги по разработке:

1. Сбор, анализ требований.
2. Составление, согласование ТЗ.
3. Написание кода.
4. Тестирование ПО.

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

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

Источник

Как я писал свой чат

Привет, Хабр!
В статье я написал, о том как разрабатывал чат. О его архитектуре и о технических решениях принятых в ходе его разработки.

Чат представляет собой клиент-серверное приложение с элементами p2p.
С поддеркжой:

• Личных сообщений.
• Комнат.
• Передачи файлов.
• Голосового чата.

Исходный код проекта: GitHub

Итак, понеслась.

Модель

Данные и их синхронизация.

Запись и воспроизведение звука.

Данные и их синхронизация.

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

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

Идея достаточно простая: есть контекст, который приватным статическим полем содержит модель. В конструкторе он, вызывает Monitor.Enter. На саму модель, либо на отдельный объект синхронизации. Так же контекст реализует интерфейс IDisposable и в методе Dispose он эту эту модель освобождает, вызывая метод Monitor.Exit.

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

В результате, для доступа к данным хочешь-не хочешь их нужно блокировать, и уже не задумываешься о синхронизации. Главное не забывать использовать конструкцию using. Для сервера это не является лучшим решением т.к. половина команд работают с 2умя пользователями максимум, а блокируются в результате — все.

Контекст в программе может создавать только одна сущность (ServerModel — (неожиданно) для сервера, и ClientModel — для клиента). Она представляет собой класс содержащий статическую приватную модель (саму себя), API а также клиентское соединение и пир — для клиентской модели или сервер для серверной. (API, клиент и т.д. содержатся как статические поля). Также клиентская модель, в отличии от серверной, содержит еще и события. На которые будет подписан пользовательский интерфейс. В общем эти классы выступают как основные для доступа к чему либо.
В качестве примера приведу серверную модель (она поменьше). Обратить внимание следует на метод Get() создающий контекст.

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

Работает вся эта система следующим образом: как только клиент или сервер принимает пакет данных, он передает его на анализ в API. (У сервера принимают сообщения его соединения, а они в свою очередь дергают один метод у сервера, о том что данные приняты). API просто считывает первые два байта сообщения и ищет у себя в словаре команду с нужным id, и возвращает ее. Или пустую команду, которая ничего не делает, если такого id нет. Дальше команде передается полученный пакет, и id приславшего его соединения и она выполняется.

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

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

Метод сервера обрабатывающего принятые пакеты:

Полный код класса API (в данном случае — серверного):

Каждая команда реализует интерфейс команды. Для сервера IServerAPICommand, для клиента IClientAPICommand, на данном этапе их можно было бы свести к 1 интерфейсу, но мне этого делать почему то не хочется. Также она содержит свой Id и данные необходимые для ее выполнения, описывающееся классом MessageContent. Впрочем команде могут быть и не нужны данные. И она сама ответственна за то, что бы десериализовать набор байт в экземпляр класса.

Пример команды. В данному случае это команда добавления файла в комнату:

Запись и воспроизведение звука.

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

Первым вариантом были WinApi функции waveIn* waveOut*. Это был самый простой вариант, поэтому начал с него. Но с ними не сложилось, т.к. на версии framework’a 3.5 неадекватно работал маршалинг на платформе x64 и при запуске приложение просто падало без каких либо исключений. При сборке под х86 все было нормально.

Дальше была попытка подключить DirectSound, но у него был найден свой баг с способом оповещения о завершении проигрывания куска данных. После гугления на эту тему выяснилось, что Mircosoft давно забросили DirectSound и работают с XAudio2. К тому же его использование привело бы к необходимости компиляции 2ух версий х86 и х64.

Так как мне не хотелось самому писать обертку для XAudio2, то я вспомнил про OpenAL. Для которого к тому же есть обертка (OpenTK), еще и с открытым исходным кодом. Из OpenTK был аккуратно вырезан только сама аудио библиотека. Которая сейчас и работает в программе.

Так как мне приходилось работать OpenGL ES 2, то и с OpenAL я подружился сразу. Особенное если учесть что по нему на официальном сайте OpenTK есть примеры.

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

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

Это было сделано просто добавлением размера сообщения в его начало.
То есть пакет представляет из себя следующее:
Первые 4 байта — размер сообщения.
5-6 байт — идентификатор команды.
Остальные данные это сериализованный MessageContent.

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

Я долго возился и пытался реализовать обход NAT используя TCP, тогда бы не пришлось парится по поводу ненадежности UDP. С ним так ничего и не получилось. После чего было решено использовать UDP и технологию UDP hole punching.

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

После этого я начал искать уже реализованные библиотеки и наткнулся на сатью на Хабре, где аналогичная проблема была решена с помощью Lidgren.Network. Она и была выбрана.

Обход NAT реализован на уровне API. Схема простая, нужно всего лишь, что бы пиры узнали реальные адреса, по которым их видит сервер. После этого один пир должен кинуть сообщение другому. Это сообщение возможно не дойдет, но создаст правило на роутере, что сообщения от того адреса, по которому оно было отправлено нужно доставлять именно этому компьютеру. После этого с помощью сервера другой пир узнает, что ему уже можно подключатся и, собственно, подключается.

И так, последовательность действий:

1. Клиент 1 говорит серверу, что хочет подключится к Клиенту 2. (Команда ServerP2PConnectRequestCommand)
2. Сервер делегирует свою задачу классу P2PService
3. P2PService смотрит не подключались ли к нему уже такие клиенты и не знает ли он уже их адреса. Если нет — просит подключится тех кто подключен небыл (Команда ClientConnectToP2PServiceCommand)
4. После их подключения, P2PService отправляет одному из них команду ожидания подключения. В данному случае это Клиент 2. (ClientWaitPeerConnectionCommand)
5. Клиент получивший команду, также получает адрес который будет к нему подключатся, и отправляет на него сообщение. Начинает ожидать подключение и отправляет серверу команду о том, что готов принять соединение. (ServerP2PReadyAcceptCommand)
6. После получения команды готовности, сервер говорит другому клиенту (Клиент 1), что тот может подключатся. (ClientConnectToPeerCommand)
7. Связь между клиентами установлена.

Черными стрелками обозначены отправки команд. Красным инициализации Lidgren.Network соединений.

Весь этот алгоритм спрятан в AsyncPeer, и достаточно вызвать метод SendMessage, и если клиент не подключен, он сам подключится, и отправит сообщение. Либо сразу отправит, если уже подключен.

Команды голосовой связи инициируют соединение немного иначе. При создании голосовой комнаты сервер создает в комнате карту подключений. В которой записано куда должен подключится каждый пользователь в комнате. А команды воспроизведения голоса отправляются с помощью метода AsyncPeer.SendMessageIfConnected, который просто выкидывает сообщение, если соединения нет.

Пользовательский интерфейс.

Напоследок немного об интерфейсе программы.
Он разработан с помощью WPF и паттерна MVVM. Очень гибкая технология, правда в версии 3.5 немного сыровата, но тем не менее позволяет обойти сыроватые места. Как на пример некоторые свойства Command все еще не зависимые, и для них пришлось написать обертку CommandReference.

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

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

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

В прочем, об интерфейсах написать больше нечего, WPF как WPF.

Источник