Обновления Fastgate: развитие push-уведомлений, динамической маршрутизации и совершенно новый интерфейс
Рассказываем о том, что происходит с продуктом и какие доработки мы внедрили за последние полгода.
Динамическая маршрутизация трафика
Продолжили работу над функционалом динамической маршрутизации, о котором рассказали в предыдущем материале про 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. Если вам интересно узнать о продукте больше, переходите на страницу продукта или свяжитесь с нами, чтобы получить презентацию.
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-уведомлениях.
Для расчета экономии мы используем следующую формулу:
- «количество сообщений» * «% проникновения мобильного приложения» * «% доставки» = N. N – количество сообщений, которое можно перевести в PUSH-канал.
- Далее мы умножаем полученное число на среднюю стоимость 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-трафике.
Информация о проекте
- сроки реализации: с 2016 года и до настоящего времени;
- количество подключенных к Fastgate внутренних систем банка: на текущий момент 11, но в связи с внедрением новых сервисов планируется их увеличение;
- используемые технологии: Java, Angular JS, Python, Rabbit MQ.
С 2012 года СКБ-Банк работал с i-Digital, отправлял трафик через API интеграцию.
В конце 2015 года Банк провел конкурс, выбрал i-Digital в качестве поставщика СМС шлюза и подписал договор на использование Fastgate. Банку нужен был шлюз, чтобы организовать информирование клиентов через единую систему.
Цели, задачи, внутренние требования:
- упрощение интеграции для систем Банка
- возможность централизованного управления трафиком
- удобство сопровождения
- четкая оценка стоимости и возможности экономии на трафике
- дополнительные возможности безопасности (ПО в контуре банка, закрытие лишних портов на firewall’е, возможности маскирования трафика при сохранении сообщений в БД)
До шлюза
До шлюза банк использовал подключение по API через SMPP, HTTPS, FTP. Запрос на отправку сообщений клиентам банка генерировали сразу несколько систем. Основные:
- Интернет-банк
- Процессиговый центр
- Back-офисная система
Часть систем генерирует сообщения разных типов – какие-то из них можно отправлять по SMPP или SFTP плагину – маркетинговый трафик, сообщения о клиентских запросах, входа в интернет-банк. Для других можно использовать только защищенное соединение – HTTPS. Для реализации этих требований банк использовал следующую схему:
Не критичный трафик отправлялся через SMPP и FTP плагины в систему i-Digital.
Отправка трафика с чувствительными данными банк шла через процессинговый центр, в который приходили запросы на отправку транзакционных сообщений, одноразовых паролей для совершения онлайн покупок, оповещения о действиях в интернет-банке из других систем. Далее из процессингового центра по защищенному HTTPS соединению запросы уходили в i-Digital.
Богдан Черепанов, СКБ-Банк
До использования шлюза в СКБ-Банке отправка сообщений велась сразу из нескольких систем. Основными можно назвать интернет-банк, процессинговый центр, файловые рассылки, одноразовые пароли для подтверждения операций в интернете и так далее. Всего было от 15 до 20 подключений (включая резервные).
Такая ситуация, во-первых, приводила к лишней нагрузке на ресурсы банка: в каждом подразделении, которое отправляло рассылки, был сотрудник, отвечающий за работоспособность этого подключения.
Во-вторых, СМС трафик рос, потребность в инструментах, которые помогли бы сократить затраты на СМС информирование была высокой.
В-третьих, большое количество подключений несло в себе риски уязвимости.
Чтобы закрыть эти вопросы и прийти к единообразию в отправке трафика, Банк принял решение внедрить транспортный шлюз Fastgate.