Привет, хабровчане!

Сегодня постараюсь рассказать о технических особенностях продукта «Максимум на первый месяц», первый вариант которого Yota запустила еще в 2020 году. Сейчас самое время поучаствовать во второй версии его реализации, когда по истечении trial-периода, проанализировав статистику потребления, Yota рекомендует не только набор минут и гигабайтов, но и безлимитные приложения, при использовании которых их трафик не учитывается в основном пакете ресурсов.

Оставив за скобками не менее интересную историю о том, как эта идея прошла через жернова отбора продуктологов, сфокусируемся на основных аспектах реализации решения.
Здесь необходимо сделать отступление для понимания картины мира. Yota, являясь Full MVNO оператором, полностью контролирует BSS стек технологий и выстраивает свой IT-ландшафт самостоятельно. То есть в нашем ландшафте есть место как различным витринам взаимодействия с клиентом, таким как мобильное приложение, сайт, цифровые и голосовые каналы, так и бэкенд системам, обеспечивающим возможности по регистрации клиентских данных, управления жизненным циклом продуктов, тарификации и многие другие. Иначе говоря, IT-ландшафт отлично соотносится с подходами доменно-ориентированного дизайна, а значит, как только аналитикам и архитекторам поступили бизнес-функциональные требования, их первоочередная задача была определить IT-домены, которые будут затронуты предполагаемыми изменениями.

Контекст решения

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

• Получение и анализ статистики по длительности совершенных звонков, объему скачанных данных и посещенным сетевым ресурсам, которые попадают в категории существующих безлимитных приложений
• Генерация продуктового предложения на основании собранных данных

В сборе и анализе данных участвуют IT-домены, которые ближе всего находятся к сетевому оборудованию:

• Домен Биллинга, а именно рейтер и биллинговая система, в которую рейтер регистрирует данные о звонке, включая его длительность
• Домен Управления сетевым оборудованием и качеством передачи данных, а именно свитчи и роутеры, через которые проходит клиентский трафик, DPI системы анализа пакетов данных и применения политик, определяемых PCRF системой, которая обеспечивает контроль использования трафика, включая накопленный объем
• Домен Аналитики данных, а именно системы сбора/регистрации данных из операционных систем, хранилище данных, а также системы, обеспечивающие поток обработки поступивших данных и подготовку продукта данных (data product) для его дальнейшего использования при генерации рекомендованного предложения

При подготовке рекомендованного предложения участвуют IT-домены, которые формируют предложение и обеспечивают его передачу в нужный канал:

• Домен Управления продуктами, а именно продуктовый каталог, системы, определяющие доступность предложений и инстанцирование продуктов в случае его принятия
• Домен Вычисления контекста состояния клиента, а именно движок бизнес-правил и набор хэндлеров, позволяющих вычислить контекст состояния клиента и объектов, с ним связанных, таких как баланс, продукты, срок жизни и т.п.
• Домен Сервисов информирования, а именно системы, обеспечивающие сборку сообщений и их отправку в нужный канал
• Домены-витрины/каналы, такие, как Мобильное приложение, CRM и другие

Давайте рассмотрим каждый из информационных потоков более детально.

Получение и анализ статистики потребления

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

Самое обычное (но не самое простое) – получить информацию об израсходованных минутах. Фактически у каждого оператора мобильной связи есть системы, производящие оценку звонка в онлайн режиме. При попытке установления соединения клиентский терминал осуществляет запрос на соединение в сеть, который поступает на Систему онлайн оценки разговоров (попросту говоря рейтер или оценщик). Задача оценщика – получить информацию о стоимости соединения в биллинговой системе, информацию о текущем балансе клиента, информацию о состоянии накопителей минут и в итоге определить, насколько долго может длиться разговор. Информация о состоявшемся звонке (CDR) регистрируется в биллинговой системе, в состав которой входит, в том числе, и длительность разговора.

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

В случае контроля интернет-трафика, с точки зрения его сбора и анализа, все оказалось несколько сложнее. Здесь есть четкая привязка к оборудованию и его возможностям, а именно поддержке протокола IPFIX. IPFIX расшифровывается как IP Flow Information Export, то есть экспорт информации IP-потока. IPFIX позволяет сетевым инженерам и администраторам собирать информацию о трафике с коммутаторов, маршрутизаторов и любых других сетевых устройств, поддерживающих протокол, и анализировать отправляемую информацию, обрабатывая ее с помощью системы анализа трафика.
Именно система анализа трафика должна поддерживать данный протокол, полученная информация по которому может быть использована при расчете предложения, включающего соответствующие безлимитные приложения для оптимизации затрат клиента на трафик. В связи с тем, что нам потребовалось обновить программное обеспечение систем анализа трафика в разных регионах, усовершенствованная версия продукта «Максимум на первый месяц» с возможностью рекомендаций безлимитных приложений была запущена уже по факту апгрейда этих систем.

Объем потребленного трафика учитывается в накопителях PCRF системы, контролирующей потребление трафика.
Информация о потоке трафика также в результате передается в корпоративное хранилище данных для дальнейшей подготовки/производства продукта данных.
Собранные данные приземляются как есть в хранилище данных, производится очистка, проверка качества. В результате чего подготовленные данные можно использовать для производства специализированных продуктов данных, имеющих определенную бизнес-ценность и произведенных для определенных конечных потребителей. В нашем случае это продукт данных, который используется движком бизнес-правил для формирования ответов о выполнении клиентом тех или иных условий, связанных с потреблением ресурсов.

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

Генерация рекомендованного предложения

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

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

Нулевой фазой продукта «Максимум на первый месяц» можно считать проект по реализации пресетов в продуктовом каталоге. Идея проекта была в том, чтобы поддержать тех клиентов, которые не готовы к тонкой настройке конструктора и предпочитают сделать выбор из конечного набора предлагаемых пакетов. Пресет с точки зрения каталога – спецификация конкретного предложения, которая может быть получена витриной (например, Мобильным приложением) и использована для предложения пакета по умолчанию.
Идея получила свое развитие в акции, выраженная в том, что на первый месяц клиент может подключить «максимальный» пресет (2000 минут и безлимитный интернет), а по истечении месяца компания будет предлагать «рекомендованный» пресет ресурсов, рассчитанный на основе статистики потребления и преднастроенных бизнес-правил.

Информационное взаимодействие по генерации предложения инициируется в биллинговой системе.
Биллинговая система и PCRF система контроля потребления трафика в нашем случае являются системами, в которых инстанцируются продукты-накопители. Но именно биллинговая система определяет, на каком этапе жизненного цикла находится тот или иной продукт у определенного клиента, актуализируя состояние накопителя интернет-трафика в PCRF через mediation device. Фактически домен Управления продуктами определяет политики инстанцирования и оркестрирует работу с продуктами на платформах, обеспечивающих жизненный цикл продукта.
Биллинговая система знает, когда наступает момент для генерации рекомендованного предложения и отправляет соответствующее событие, на которое подписан диспетчер формирования «рекомендованного» пресета.

Считаю, что движок бизнес-правил является неотъемлемой частью событийно-ориентированного ландшафта любой продуктовой компании. Это утилитарный (платформенный) высоконагруженный сервис, который слушает события на входе и быстро возвращает ответ – выполнен или нет требуемый набор бизнес-правил, исходя из контекста состояния клиента. Он также должен обладать возможностью предоставлять изолированные репозитории для настройки самих правил всем автономным продуктовым командам, таким как Смартфон, Модем, Финтех, B2B и другим.
Движок используется для определения доступности коммерческих предложений, определения выполнения клиентом условий маркетинговых кампаний и во многих других сценариях использования, являясь одной из центральных платформ IT-ландшафта.

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

Продолжим тему генерации рекомендованного предложения. Диспетчер, получая событие, сигнализирующее о необходимости расчета предложения, отправляет запрос на движок бизнес-правил, получает ответ о выполнении набора правил и формирует «рекомендованный» пресет. Движок в нашем случае не только информирует об успешности выполнения правил (true/false), но и сообщает вычисленные значения ресурсов для формирования пресета, используя правила-формулы и подготовленный продукт данных доменом Аналитики данных в качестве базисных значений для расчета.

По факту формирования «рекомендованного» пресета диспетчер отправляет событие, получаемое доменом Систем информирования. Основным компонентом данного домена является процессор динамической сборки сообщений. Процессор собирает сообщение для информирования и отправляет его по каналам взаимодействия с клиентом, таким как пуш-сообщение в Мобильном приложении и SMS.

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

Заключение

Резюмируем основные положения статьи:

1. Следование принципам доменно-ориентированного дизайна позволяет точно определить задействованные системы и границы предполагаемых изменений в каждом домене, а также понять задействованные IT-команды и оценить их трудозатраты.
2. Сбор статистики потребления зависит от технических возможностей каналов, обеспечивающих передачу голоса и «цифры», а также систем анализа трафика.
3. Решение базируется на основополагающем компоненте для определения доступности предложений – движке бизнес-правил.
4. Развитием доменов Управления продуктами и Вычисления контекста состояния клиентов движет запрос на расширение портфолио предлагаемых продуктов и связанное с этим запросом требование по обеспечению конвергентности механик управления продуктами.
5. Продукт «Максимум на первый месяц» является частным случаем на основе универсального механизма генерации предложений, которые могут быть сформированы, исходя из правил, определяемых акцией. В дальнейшем правила могут быть легко изменены. Как один из предполагаемых вариантов развития, рассматривается возможность изменения правил, когда акция будет доступна не только новым, но и существующим клиентам.