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

Динамическая маршрутизация трафика

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

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

• минимальное количество сообщений с задержкой
• минимальное количество не доставленных до абонентов сообщений
• максимальный допустимый процент недоставки (при превышении — перевод в резерв)

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

Например, для вас критичной является задержка 10 секунд для 80% трафика. При этом, если это ночной трафик, с минимальными объемами, даже в случае если 80 сообщений в минуту пройдут с задержкой доставки, а остальные 20 не, то Fastgate переведет трафик в резерв. При этом, 80 сообщений со сниженной скоростью доставки для вас не являются критиными.
Чтобы этого не произошло мы добавили минимальное количество сообщений. Допустим, в параметре вы укажете 800 сообщений, как минимальный объем трафика для перевода в резерв и 80% как критичное значение для общего объема трафика. Тогда, если период сбора статистики 800 сообщений из 1000 не будут доставлены, Fastgate переведет трафик в резерв.

Сервис push-уведомлений

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

• В Fastgate теперь доступна информация по подпискам пользователей. Если пользователь приложения может выбрать тип уведомлений, которые он хочется получать в push или наоборот не хочет, данные по его подпискам передаются в Fastgate. Если пользователь отпишется от маркетинговых рассылок в этом канале, такое сообщение не отправится пользователю в пуше, а уйдет в SMS или следующий после push канал в каскаде.
  На основании данных по подпискам/отпискам мы сформировали новый отчет, который поможет оценить динамику взаимодействия пользователей с приложением. В отчете отображается информация о количестве зарегистрированных абонентов, сгруппированных по приложениям, дате и времени регистрации.

• Также сделали отдельный отчет по качеству доставки push-уведомлений. Отчет дает возможность оценить уровень доставки пуш-трафика в разрезе приложений, ОС. Считает количество и процентное соотношение по статусам доставки и прочтения. Данные распределяются в том числе по подключению. То есть, если вы отправляете push-трафик через разных поставщиков, в отчете вы увидите показатели по конкретному поставщику трафика (подключению).

• Из Fastgate можно отправить одиночное пуш-сообщение со скрытым параметром. В  параметрах передаются данные, которые обрабатывает приложение на устройстве абонента. Тат могу быть: диплинки, какие-то параметры отображения пуша на устройстве — в зависимости от логики самого приложения.

Новый пользовательский интерфейс

Первый релиз с новым интерфейсом у нас состоялся в прошлом году в ноябре. Тогда появились: Журнал сообщений, Рассылки и Опросы. Часть клиентов сразу начали пользоваться доступным функционалом в новом интерфейсе – он удобный и красивый.
За 5 месяцев провели большую работу по развитию интерфейса:

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

Реализовали медиа-контент и кнопки для каналов WhatsApp и Viber при запуске любых сообщений, в том числе опросов.

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

Проработали раздел Справочники, теперь там есть
Каналы получения, Каналы отправки,Подключения, Имена отправителей, Мобильные приложения, Типы трафика, Операторы, Коды ошибок. 

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

Обновления Fastgate выходят каждые две недели – мы активно развиваем функциональность шлюза для повышения удобства работы с веб-интерфейсом и возможностей для настройки рассылок, развиваем компоненты системы, маршрутизацию трафика и упрощаем процесс поставки и обновления решения.

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

Динамическая маршрутизация трафика

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

Для чего нужна динамическая маршрутизация

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

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

Как работает динамическая маршрутизация в Fastgate

Каждую минуту Fastgate будет оценивать 2 показателя: скорость доставки сообщений до абонентов и объем сообщений, который поставщик отправляет Оператору. Если какой-то из этих показателей достигнет критического значения — скорость доставки упадет или вырастет объем не отправленных сообщений — трафик будет переведен в резервный канал автоматически.

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

В разделе настройки правил маршрутизации также заложена история маршрутизации – там будут отражаться факты перевода трафика в резерв. Используя эти сведения, пользователи Fastgate смогут оценивать надёжность канала и его работоспособность.

Доработки в создании WhatsApp рассылок

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

Дальнейшие шаги по переводу поставок в Kubernetes

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

В последних версиях мы внедрили интеграцию контейнера с репозиторием Nexus. Ранее мы использовали собственные ресурсы для хранения и обновления файлов для развертывания Fastgate. Работа в связке Nexus — Kubernetes обеспечит большую прозрачность, скорость и удобство работы.

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

Fastgate изначально создавался как коробочное решение для управления трафиком в банковском секторе, поэтому при разработке мы ориентировались на основные требования банков к подобным решениям:

• возможность развернуть шлюз в контуре банка, учитывая особенности IT окружения
• возможность провести интеграции банковских систем по привычным протоколам
• возможность просто и быстро интегрироваться с агрегаторами или операторами для отправки трафика.
• высокая пропускная способность, чтобы без задержек отправлять критичный трафик – пароли и 3D-Secure коды

Технологии шлюза 

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

Изначально стандартная поставка Fastgate была предназначена для окружения PostgeSQL+Linux или Oracle+Linux. Для развертывания административного интерфейса по умолчанию мы использовали сервер Apache. В 2016 году к нам пришел клиент, который использовал IIS (Internet Information Services) и Apache для них не подходил. Мы развернули поставку Fastgate по стандартам клиента, подготовили инструкции и настройки для запуска веб интерфейса под IIS (Internet Information Services) и передали их специалистам.

Компоненты шлюза 

Компоненты шлюза можно условно разделить на 5 элементов.

• Web-интерфейс
• За точки входа в систему Fastgate отвечает Adapter container server
• За обработку и маршрутизацию трафика отвечает Message processor
• Точки выхода — Container server
• Сбор статистики по сообщениям: Logger

Web-интерфейс

В web-интерфейсе производятся основные настройки системы: каналы отправки, подключения, настраиваются правила маршрутизации, шаблоны сообщений, определяются роли пользователей в системе и создаются пользователи. Там же есть  доступ к отчетам, с помощью которых можно проводить сверки с контрагентами, анализировать объемы трафика, который генерируют внутренние системы компании (CRM, процессинг, интернет-магазин). Из веб-интерфейса можно также формировать отправку одиночных сообщений или рассылок. 

Точки входа в систему: Adapter container server

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

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

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

Передача сообщений из Adapter container server в Messaging Processor производится в соответствии с приоритетом сообщения: High, Middle, Low.

Приоритет сообщения — это то очередность обработки сообщения в системе Fastgate

Приоритезация происходит следующим образом:

• В веб интерфейсе создаются шаблоны сообщений с заданным приоритетом. Этот шаблон прописывается в конфигурационном файле плагина, через который происходит отправка информации в Fastgate. Когда сообщение попадает в плагин, оно формируется в заданный шаблон, который уже заведен в системе, этому сообщению в том числе присваивается приоритет шаблона.
• При передаче сообщения из системы клиента в FG. Если на стороне клиента есть система, которая самостоятельно определяет приоритеты для разных типов сообщений, то мы используем приоритет, сформированный этой системой, и на этапе приема параметров «переводим» его в понятный Fastgate тип приоритета. Другой вариант – когда таких приоритетов в системе клиента нет, он присваивает сообщениям параметры, которые мы используем для приоритезации: High, Middle, Low.
• Приоритет также можно выставить при создании рассылки из веб-интерфейса.

Message processor. Обработка и маршрутизация трафика

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

Например, message processor проверяет наличие номера в черном списке, не заблокировано ли сообщение по IMSI Check, если этот сервис подключен, проверяет сообщения на дубликаты и блокирует отправку сообщения, у которого совпадает текст, номер телефона и тип сообщения.

Message processor также отвечает за управление PUSH сообщениями, которые отправляются через PUSH платформу i-Digital. В момент обработки компонент проверяет, указан ли адрес устройства абонента в объекте сообщения. В случае, если указан – абоненту уходит PUSH, если нет – отправка пуша блокируется. Message processor возвращает статус блокировки в ACS, и ACS переотправляет сообщение в резервный канал (SMS, Viber).

После обработки в message processor, сообщение уходит в подключение, заданное в правилах маршрутизации в веб интерфейсе.

Container server

Точки выхода – это транспортные коннекторы для интеграции по SMPP протоколу с операторами или агрегаторами и плагин для интеграции по HTTPS протоколу, для трафика, который уходит в подключение i-Digital. Благодаря этому компоненту мы можем обеспечить возможность интеграции с любыми партнерами в достаточно сжатые сроки.

Logger

Компонент, который собирает статистику обработки сообщений от всех остальных компонентов шлюза, в том числе статус обработки сообщения оператором и сохраняет их в базе данных Fastgate и передает её в системы клиента (CRM, интернет-магазин и тд) через ACS. При сохранении сообщений в базу logger маскирует конфиденциальную информацию.

Logger также расшифровывает коды статусов причин недоставки, которые Fastgate получает от разных операторов/агрегаторов и преобразовывает их в понятное текстовое описание.

База данных системы и взаимодействие с ней

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

• web-интерфейс – наполняет и управляет справочниками.
• adapter container –подтягивает из базы шаблоны и все, что нужно для корректного формирования сообщений для дальнейшей их обработки в системе.
• message processor – выгружает из базы информацию по правилам маршрутизации входящих и исходящих сообщений
• logger –сохраняет в базу информацию по результатам обработки и отправки сообщений.

Fastgate разработан и протестирован в связке с двумя самыми распространенными базами данных: PostgreSQL и Oracle. Благодаря использованию фрейморка Hibernate, Fastgate можно интегрировать и с другими системами (например, Microsoft SQL Server или MariaDB).

Микросервисная архитектура, горизонтальное масштабирование и «горячий» резерв

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

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

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

Поставка и эксплуатация Fastgate

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

До использования Kubernetes при поставке Fastgate IT службе клиента нужно было вручную настроить окружение для системы: выделить отдельный сервер, установить нужное окружение – базу данных, Rabbit MQ, установить Java, чтобы запустить работу компонентов. В случае обновления компонента, приходилось обновлять и окружение также в ручном режиме.

Сейчас мы поставляем Fastgate в виде набора Docker-образов, либо Helm-чарта, позволяющих при наличии у заказчика кластера Kubernetes развернуть шлюз в кратчайшие сроки без затрат на покупку, введение в эксплуатацию и обслуживание выделенных серверов. В «классическом» варианте, для использования вне облачных сред, Fastgate поставляется в виде gzip-архива с иерархией исполняемых файлов, файлов конфигурации и скриптов запуска. Для развертывания достаточно выполнить одну команду: Kubernetes автоматически поднимет сервер и развернет компонент со всем необходимым окружением и для первой поставки, и в случае обновления компонентов.

Еще одно удобство Kubernetes в том, что он контролирует работоспособность системы, отправляя запросы health check к каждому компоненту по API. Если компонент не отправит в ответ Ок, то Kubernetes его сносит и разворачивает заново.

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

Нативные push-уведомления

В основном пуши отправляют, используя технологии Apple и Google – через публичное облако. Механика такой отправки не предполагает возврата статусов доставки по отправленным уведомлений, их нельзя встроить в каскадную рассылку PUSH + SMS, и использовать как рабочий инструмент, а значит экономить.

Помимо этого, процент доставки таких уведомлений будет падать: пользователи могут сменить номер телефона или переустановить приложение на другой телефон, описаться от уведомлений – эти изменения никак не отследить, используя стандартные возможности Push Notification services.

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

Чем отличаются push-уведомления из платформы Fastgate

Основное качество таких уведомлений – стабильная доставка от 80% и возврат статусов доставки.

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

Преимущества push-уведомлений из платформы

• Можно отправлять безопасные пуши, что особенно важно при передаче чувствительных данных: паролей, транзакционных сообщений. Для защиты данных используется следующая схема отправки.
  Сначала пользователю мобильного приложение через облако отправляется short push – в нем передается заголовок сообщения, который видит пользователь в шторке уведомлений. В этом тексте нет чувствительных данных. Когда пользователей кликает по уведомлению и открывает его в приложении – показывается полный текст – long push, — который был скачан с PUSH-платформы. Чувствительные данные мы передаем с наших серверов на сервер клиента по защищенному https протоколу.

• Мобильная библиотека следит за актуальностью адреса в облаке, в случае, если он меняется – отправляет обновления в PUSH-платформу.

• Механизм отслеживания актуальности также заложен в шлюзе Fastgate: если по отправленному ранее уведомлению вернется ошибка со статусом «приложение удалено с устройства» и другими, то в следующий раз пуш этому клиенту доставляться не будет. Это ускорит коммуникацию/

• Для запуска PUSH канала мы предоставляем готовую мобильную библиотеку для быстрого встраивания в мобильное приложение – так вам не придется разбираться в специфике работы с облаками

PUSH-уведомлениями  удобно управлять через шлюз Fastgate

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

• Доступна отправка уведомления на конкретное мобильное приложение, если абонент использует сразу несколько.

• Платформа проверяет наличие установленного мобильного приложения, если его нет, такому абоненту сразу будет отправлена SMS для ускорения доставки информации.

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

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

Экономия на PUSH-уведомлениях

PUSH в разы дешевле SMS.

Если учесть, что тексты сервисных и маркетинговых сообщений часто состоят из двух и более сегментов SMS, экономия на уведомлениях будет значительной.

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

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

Как посчитать экономию на PUSH-уведомлениях.

Для расчета экономии мы используем следующую формулу:

1. «количество сообщений» * «% проникновения мобильного приложения» * «% доставки» = N.  N – количество сообщений, которое можно перевести в PUSH-канал.
2. Далее мы умножаем полученное число на среднюю стоимость 1 Push уведомления.
   N*0,36=X.

Например, вам нужно посчитать экономию на трафике в 1 млн сообщений, при этом процент проникновения приложения у вас 50%.

1 млн*0,5*0,8= 400 000 сообщений, вы можете перевести в PUSH-канал.

Они будут стоить всего 144 000 рублей.

Чтобы оценить экономию в сравнении с отправкой SMS трафика, нужно рассчитать количество сегментов в каждом сообщении, которое вы планируете отправлять в push.

Это можно сделать, проанализировав шаблоны сообщений:

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

К примеру, 400 000 сообщений в SMS объемом 2 сегмента будут стоить 1 600 000 рублей против 144 000 рублей, в случае отправки этих сообщений в PUSH-канал.

Этапы запуска PUSH уведомлений

Этап первый. Сбор бизнес-требований к работе push-канала.

На этом этапе вам важно ответить на следующие вопросы: 

• какие типы сообщений вы планируете отправлять клиентам;

• будете ли вы включать другие каналы с каскад;

• что будет отображаться при нажатии клиента на push;

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

Этап второй. Интеграция

Нужно встроить готовую мобильную библиотеку для мобильного приложения и провести интеграцию шлюза Fastgate с мобильным бэкендом, чтобы передавать в Fastgate актуальные адреса устройств, на которые будут отправляться push-уведомления.

Мы передаем требования к интеграции и готовую мобильную библиотеку для встраивания в приложение.

Этап третий. Тестирование

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

Этап четвертый. Опытная эксплуатация

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

Запуск в коммерческую эксплуатацию

Обычно мы советуем постепенно наращивать объемы PUSH уведомлений и начинать отправку с конкретных шаблонов, отрабатывать схему и внедрять новые шаблоны отправки PUSH и новые механики.

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

Почитайте об опыте СКБ-Банка, который использует Сервис PUSH-уведомлений и экономит в месяц больше 1 миллиона рублей на SMS-трафике.