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

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

Продолжили работу над функционалом динамической маршрутизации, о котором рассказали в предыдущем материале про 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-уведомлениях.

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

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-трафике. 

Информация о проекте

• сроки реализации: с 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.