Что такое Рокетбанк и зачем ему CDP
Рокетбанк это необанк с характером. Это не просто приложение для переводов и оплаты: банк строит продукты вокруг идеи осознанного удовольствия от жизни. Рядом с картой и счётом существует целая экосистема лайфстайл-сервисов: Фит (шопинг-платформа с гидом по локальным брендам), Аут, гастро-сервис для выбора заведений под настроение, плюс встроенный AI-ассистент.
Чтобы объединить банковскую и лайфстайл-части в единое клиентское пространство, команде потребовалась CDP-платформа. Задача звучала просто: собрать данные из разных источников и запустить релевантные персональные коммуникации. На деле это оказался один из самых технически плотных кейсов в российском финтехе.
С чего начинали: нулевая база коммуникаций
На старте проекта у Рокетбанка не было ни одного работающего маркетингового канала. Никаких сценариев, никаких рассылок, никакой аналитики по поведению пользователей. Всё предстояло создавать с чистого листа.
Параллельно стояла задача интеграции сразу с несколькими слоями инфраструктуры:
- ядро банка: core banking, системы антифрода, OpenAPI, RBS;
- лайфстайл-платформы: Фит, Аут, AI-ассистент;
- требования информационной безопасности и банковского комплаенса.
Дополнительная сложность это правильные частота и контекст сообщений. Одно дело отправить SMS о выпуске карты, другое: вписать рекомендацию ресторана в момент, когда пользователь открывает приложение после рабочего дня. Эти сценарии требуют принципиально разных данных и логики.
Требования к платформе
Команда Рокетбанка сформировала чёткий список требований к CDP перед выбором решения. Платформа должна была:
- поддерживать омниканальные коммуникации через CRM-каналы: email, SMS, push-уведомления, мессенджеры;
- собирать и обогащать данные о пользователях для персонализации предложений;
- подключаться к внутренним базам данных банка;
- реализовывать программу лояльности с начислением бонусных баллов через Webhooks;
- поддерживать сценарии телефонии: инициации звонков и перезвоны через интеграцию с Genesis;
- работать в on-premise-режиме в соответствии с требованиями банковской безопасности;
- поддерживать кастомные интеграции и нестандартные каналы;
- иметь встроенную аналитику и возможность передавать данные во внешние BI-системы;
- предоставлять оперативную техническую поддержку и возможность доработок.
По итогам анализа рынка была выбрана маркетинговая платформа как отечественное решение, закрывающее весь этот список.
Как проходила интеграция
Работа велась поэтапно. Сначала подготовили три серверные среды: Dev, Test, Prod. Сроки по этапам выглядели так:
- Выбор CDP и подписание договора: 2 месяца.
- Подготовка к интеграции: 1 месяц.
- Сама интеграция: 2 месяца.
- Тестирование: около полутора недель.
Суммарные трудозатраты на проект составили 473 человеко-часа. В команде работали разработчики, тестировщики и архитекторы.
Что было реализовано технически:
- API-соединения с внутренними системами банка.
- Выделенный канал в мобильном приложении: отдельное пространство на главном экране, где отображаются экшн-сообщения. По нажатию пользователь переходит в тред с подробной информацией. На такие сообщения можно ставить реакции.
- Телефонные сценарии через Genesis: по результату статуса пользователя система автоматически направляет его в следующий шаг, перезвон, перезвон в заданное время или отправка сообщения. Эта логика позволила сопровождать пользователей на этапе выпуска карты.
- Сценарии клиентской воронки: настроены ключевые этапы онбординга и активации.
Программа лояльности: рокетсы через CDP
Отдельный блок работы это интеграция программы лояльности. Рокетсы (внутренняя валюта Рокетбанка) позволяют пользователю увеличить рублёвый кешбэк. Зарабатывать их можно, выполняя задания: прохождение онбординга, установка аватарки и другие шаги.
На стороне CDP настроены сценарии, которые срабатывают при выполнении этих действий. Сценарий инициирует вебхук, передающий данные о начислении в процессинг. После успешного начисления система возвращает ответ, и CDP отправляет пользователю уведомление о полученных рокетсах. Дополнительно команда разработала собственные микросервисы для передачи данных между платформами.
Результаты: цифры и выводы
После запуска пилотных сценариев и тестовых рассылок зафиксированы следующие результаты:
- 16% клиентов вернулись на этап онбординга.
- 40% из них дошли до первой транзакции.
- Выросла доля открытых счетов за счёт возврата пользователей в воронку.
- Зафиксирован устойчивый рост конверсий в онбординг и активацию.
- Повысилась осведомлённость пользователей о продуктах банка благодаря новому внутреннему каналу в приложении.
Каналы показали разную эффективность в зависимости от этапа. SMS дал лучшие результаты на этапе возврата пользователя в онбординг. Экшн-сообщения в приложении сработали сильнее на этапе активации: их формат позволяет передавать более развёрнутую информацию прямо внутри продукта.
Благодаря новым каналам и механикам лояльности Рокетбанк добился устойчивого роста вовлечённости, удержания клиентов и их пожизненной ценности (LTV).
Что важно понять из этого кейса
Кейс Рокетбанка показывает несколько вещей, которые редко обсуждают в контексте CDP-внедрений.
Первое: лайфстайл и финансы не противоречат друг другу технически. Данные о транзакциях и данные о том, что человек ищет в гастро-приложении, можно объединить в одном профиле, если архитектура это позволяет. CDP здесь работает как связующий слой между банковским ядром и потребительскими привычками клиента.
Второе: начало с нуля бывает преимуществом. Отсутствие унаследованных систем коммуникаций означало, что команда могла выстроить правильную архитектуру сразу, без костылей и обходных решений. Не нужно было ничего мигрировать или переделывать, только проектировать.
Третье: выбор канала под этап воронки важнее выбора канала вообще. SMS и экшн-сообщения решают разные задачи. SMS хорошо работает на возврате пользователя, потому что приходит вне приложения. Экшн-сообщение внутри приложения сильнее на этапе активации, потому что человек уже в контексте продукта. Понимание этого различия позволило добиться 40% конверсии в первую транзакцию среди вернувшихся пользователей.
Наконец, on-premise-размещение в банковском контексте, не ограничение, а базовое требование. Платформа, которая не поддерживает этот режим, просто не пройдёт согласование службы безопасности. Этот фактор часто недооценивают при выборе CDP в финансовом секторе. Для Рокетбанка он был принципиальным с первого дня переговоров.
