В первой статье мы «срывали покровы» и рассказывали, что такое коллтрекинг. Затем подробно разобрали его настройки, теперь — о том, как мы в «Манго Телеком» создавали эту услугу и какой стек технологий используем.

Эта история началась примерно 2 года назад. Мы хотели найти новые направления бизнеса в дополнение к основному — телефонии. Долго обсуждали варианты и в результате составили список примерно из 10 потенциально интересных продуктов и сервисов. Идея коллтрекинга выглядела самой перспективной, учитывая наши возможности: мы — телефонный оператор, у нас своя виртуальная АТС (ВАТС) и мы владеем большим пулом телефонных номеров.

Итак, решили реализовать коллтрекинг.

Начало

Стали думать, как именно это сделать. Было понятно, что всю «телефонную» часть проекта нужно строить на базе нашей ВАТС. Есть один юридический аспект: по закону нельзя продавать клиентам номера, фактически мы сдаём номера в аренду. Кроме того, перенаправлять клиенту звонок по арендованному номеру можно только при условии заключённого договора на услуги ВАТС. Поэтому мы долго обдумывали биллинг — как грамотно считать расходы, какую модель выбрать. В конце концов, создали специальную техническую ВАТС, на которую назначили весь пул номеров, и построили биллинг на её основе.

Выделение номеров

Все разработчики систем коллтрекинга сталкиваются с одной трудностью: клиент подключил номер, номер отобразился для какого-нибудь пользователя, а тот взял и записал его себе на бумажку. Люди же записывают всякую полезную информацию, чтобы не забыть. Через некоторое время номер «отвязался» от конкретного клиента, и тут пользователь решил позвонить, а номер уже у совершенно другой компании.

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

Сейчас номера выделяются так:

• Клиент подключает коллтрекинг и размещает на сайте виджет.
• Как только на сайте клиента появляется посетитель, система по IP определяет его регион. Это делается по таблице, которую мы храним в PostgreSQL.
• Коллтрекинг проверяет, есть ли в регионе свободные номера, чтобы показать посетителю сайта телефон с кодом нужного города. Номерная емкость для каждого региона постоянно мониторится и по необходимости пополняется.
• ОК, номер есть — идем дальше. Система опознает маркетинговые метрики посетителя и сопоставляет их с номером, по которому он звонит.

Все описанное выше относится к ситуации, когда у клиента подключена «Мультирегиональность», то есть позвонить ему могут из нескольких городов, где он размещает рекламу.

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

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

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

Обработка вызовов

Итак, пользователь звонит на показанный ему на сайте номер. Вызов приходит на нашу техническую ВАТС. Коммутатор отправляет в базу данных (БД) один запрос с номером и получает ответ: на SIP-линию какой компании-клиента нужно перенаправить вызов. Коммутатор перенаправляет звонок, а его дальнейшее «приземление» зависит от клиентских настроек переадресации в ВАТС. Вызов можно перенаправить на какое-то подразделение компании, запустить обычное приветствие или голосовое меню любой сложности, настроить схему ожидания и многое другое. Таких возможностей нет в большинстве других систем коллтрекинга на рынке.

Когда на технической ВАТС и коммутаторе что-то приходит, в сервис коллтрекинга летят события, по которым отслеживается, откуда поступил вызов, когда он завершился и с каким статусом. Вся эта информация сохраняется в отдельную MongoDB. Потому что в основной БД по всем звонкам за много лет накопились миллиарды записей, и хранить в ней ещё и данные коллтрекинга неразумно. Именно на основании данных из отдельной БД строится отчёт по звонкам с расширенной детализацией. В этом отчёте клиент видит UTM-метку канала, по которому пришёл пользователь. То есть можно определить конкретный источник и рекламную кампанию, которая «привела» звонок. Иногда добавляются ключевые слова из поискового запроса. Бывает, что в UTM-метку рекламное объявление, заинтересовавшее пользователя, умещается целиком. Всё это позволяет строить агрегированные отчёты по каналам, источникам и рекламным кампаниям. Сами звонки записываются, и при желании клиенты могут их прослушать.

Система автоматически делит звонки по новизне и качеству. Новые — это звонки с номеров, с которых ещё не звонили в компанию. А критерий качества простой: длительность разговора без учёта времени, потраченного пользователем на дозвон и прослушивание голосового меню. Если клиент установит «Центр обработки вызовов» (наш инструмент для контакт-центров), то сможет самостоятельно присваивать звонкам категории (теги) — для более точного анализа.

Сквозная аналитика

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

• с рекламными площадками Яндекс.Директ и Google AdWords (в будущем планируем добавить интеграцию с рекламными системами соцсетей);
• с CRM клиентов (для подгрузки информации о сделках).

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

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

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

Стек технологий

При создании и развитии продуктов всегда приходится учитывать и требования рынка, и пожелания клиентов. Главное, правильно расставить приоритеты. Мы анализируем, сколько ресурсов и времени понадобится на создание той или иной фичи, и насколько она влияет на бизнес клиента, составляем план разработки и начинаем творить. Минорные обновления выходят с периодичностью раз в две недели. Раз в пару месяцев мы реализуем большие функции. На прошлой неделе мы выпустили обновление с легкой установкой коллтрекинга. Виджет теперь не нужно добавлять в строго определенный фрагмент кода (вместо телефона), он работает, даже если поставить его в конец страницы. Или в начало. Куда угодно. Для неопытных пользователей это должно упростить запуск сервиса.

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

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

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

Высоконагруженная часть, связанная с обработкой звонков, построена на базе Node.JS. Более простые компоненты написаны на PHP. Пользовательский интерфейс основан на JavaScript-фреймворке Angular. В телефонии преимущественно С++. Для внутренней интеграции всех сервисов используется сервер очередей RabbitMQ. Он выступает в роли шины обмена данными между сервисами коллтрекинга и другими продуктами компании.

Все пользовательские настройки ВАТС и коллтрекинга хранятся в PostgreSQL. Это надёжная реляционная база, обеспечивающая целостность данных. Статистика посещаемости сайтов, статистика номеров и совершённых звонков пишется в MongoDB. Эту базу данных мы выбрали потому, что она проще в сопровождении по сравнению с SQL-решениями. А для оперативного хранения данных, доступ к которым требуется в реальном времени, мы используем Redis. В ней информация о действующих номерах коллтрекинга и их привязке к клиентам.

---

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