Запилить сервис push-рассылки без пап, мам и кредитов

Менеджер цифровых проектов Маша из Tele2 рассказывает, как команда запилила сервис push-рассылки «почти что из пластиковой бутылки и скотча».

Итак, у нас было: 267+ млн push-уведомлений в мобильном приложении в год, один подрядчик (с собственным сервисом рассылки, истекающим сроком договора и запросом на повышение стоимости контракта) , 8 альтернативных партнеров разных компетенций, один Босс, команда из 4 человек. Задача: всё переделать.

Теперь сама история.

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

Мы отправляли массовые коммуникации, используя таргет на платформе партнёра, и таргетированные рассылки совместно с командой campaign management. CM, в данном контексте, система хранения и отправки на вход фронтовым системам полезной информации. Например, предложений, помогающих клиенту оптимизировать тариф. А для массовых рассылок без таргетинга, таких, как сообщение о необходимости обновить приложение, использовали AppMetrica.

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

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

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

Затем наш push-сервер вычитывает сообщение, проверяет активные сессии у абонента, из них берет актуальный девайс токен (в данном контексте это «адрес» для отправки push-уведомлений). После он соотносит нотификации и девайс токен, чтобы следом отправить данные в облачное хранилище — firebase. Оттуда уже сообщение уходит абоненту. Сделали свою магию!)

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

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

На внедрение внутреннего технического решения понадобилось 3 месяца, это гораздо оптимистичнее сроков, которые называли сторонние подрядчики. Для работы компания высвободила часть команды digital… очень маленькую часть в четыре человека, которая 70% рабочего времени посвятила разработке функционала.

Затраты на разработку отбились примерно за 8 месяцев, и за счёт экономии на использовании сторонних инструментов, и за счёт увеличенной конверсионности отправляемых нотификаций.

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

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

Сейчас push-уведомления получают 80% абонентской базы.