Большим данным большой биллинг: о BigData в телекоме

    В 2008 BigData была новым термином и модным трендом. В 2019 BigData – это объект продажи, источник прибыли и повод для новых законопроектов.

    Осенью прошлого года российское правительство инициировало законопроект о регулировании больших данных. Запрещается идентифицировать по информации людей, но разрешается делать это по запросу федеральных органов. Обработка BigData для третьих лиц – только после уведомления Роскомнадзора. Под закон попадают компании, в распоряжении которых больше 100 тысяч сетевых адресов. И, конечно, куда без реестров – предполагается создание такового со списком операторов БД. И если до этого BigData не всеми воспринималась всерьез, то теперь с ней придется считаться.

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

    Теорема


    Начнем, как в задаче по математике: сначала докажем, что данные операторов связи можно именовать BigDat’ой. Стандартно большие данные характеризуются тремя признаками VVV, хотя в вольных интерпретациях количество «V» доходило и до семи.

    Volume. Один только MVNO Ростелекома обслуживает больше миллиона абонентов. Ключевые хост-операторы обрабатывают данные от 44 до 78 миллионов человек. Трафик растет ежесекундно: за первый квартал 2019 абоненты уже насерфили с мобильных телефонов 3,3 миллиарда Гб.

    Velocity. Никто лучше статистики не расскажет о динамике, поэтому пройдусь по прогнозам Cisco. К 2021 году 20% IP-трафика достанется мобильному трафику – он вырастет почти в три раза за пять лет. Треть мобильных подключений придется на M2M – развитие IoT обусловит шестикратный рост соединений. Интернет вещей станет не только прибыльным, но и ресурсозатратным направлением, поэтому некоторые операторы сосредоточатся только на нем. А те, кто разовьет IoT отдельной услугой, получат двойной трафик.

    Variety. Многообразие – понятие субъективное, но операторы связи действительно знают о своих абонентах почти все. От имени и паспортных данных до модели телефона, покупок, посещаемых местах и интересах. Медиа-файлы по закону Яровой хранятся от полугода. Так что примем за аксиому, что собираемые данные разнообразны.

    Софт и методология


    Провайдеры – одни из главных потребителей BigData, поэтому большинство методик анализа больших данных применимы к отрасли телекома. Другой вопрос – кто готов вкладываться в развитие ML, AI, Deep Learning, инвестировать в ЦОДы и data mining. Полноценная работа с БД складывается из инфраструктуры и команды, затраты на которые не все могут себе позволить. Делать ставку на BigData стоит предприятиям, которые уже имеют корпоративное хранилище или развивают методику Data Governance. Тем же, кто еще не готов к длительным инвестициям, советую постепенно наращивать архитектуру ПО и ставить компоненты по очереди. Тяжелые модули и Hadoop можно оставить напоследок. Мало кто покупает готовое решение для задач типа Data Quality и Data Mining, в основном компании подгоняют систему под свою специфику и потребности – сами или с помощью разработчиков.

    Но не любой биллинг можно модифицировать под работу с BigData. Вернее, модифицировать могут не только лишь все. Мало кто может это делать.

    Три признака, что у биллинговой системы есть шанс стать инструментом обработки БД:

    • Горизонтальная масштабируемость. Софт должен быть гибким – мы же говорим о больших данных. Увеличение количества информации должно лечиться пропорциональным увеличением «железа» в кластере.
    • Отказоустойчивость. Серьезные prepaid-системы обычно по умолчанию отказоустойчивы: биллинг разворачивается в кластере в нескольких геолокациях, чтобы те автоматически страховали друг друга. Компьютеров в Hadoop-кластере тоже должно быть достаточно на случай поломки одного или нескольких.
    • Локальность. Данные должны храниться и обрабатываться на одном сервере, а иначе на передаче данных можно разориться. Одна из популярных схем подхода Map-Reduce: HDFS хранит, Spark обрабатывает. В идеале софт должен безболезненно интегрироваться в инфрастуктуру ЦОД и уметь три в одном: собирать, организовывать и анализировать информацию.

    Команда


    Что, как и для какой цели программа будет обрабатывать большие данные – решает команда. Часто она состоит из одного человека – data scientist’а. Хотя, на мой взгляд, минимальный пакет сотрудников для BigData включает в себя еще и Product-менеджера, Data Engineer’а, руководителя. Первый разбирается в услугах, переводит технический язык на человеческий и обратно. Data Engineer воплощает модели в жизнь с помощью Java/Scala и экспериментирует с Machine Learning. Руководитель координирует, ставит цели, контролирует этапы.

    Проблемы


    Как раз со стороны команды BigData обычно возникают проблемы при сборе и обработке данных. Программе нужно объяснить, что собирать и как обрабатывать – для того, чтобы это объяснить, нужно сначала самому понять. А у провайдеров не все не так просто. Рассказываю о проблемах на примере задачи по сокращению оттока абонентов – именно ее операторы связи пытаются решить с помощью BigData в первую очередь.

    Постановка задач. Грамотно составленное ТЗ и разное понимание терминов – многовековая боль не только для фрилансеров. Даже «отвалившихся» абонентов можно интерпретировать по-разному – как не пользующихся услугами оператора месяц, полгода или год. А для создания MVP на исторических данных нужно понимать частоту возвратов абонентов из оттока – тех, кто пробовал связь других операторов или уезжал из города и пользовался другим номером. Еще один важный вопрос: за сколько времени до предполагаемого ухода абонента провайдер должен это определить и принять меры? За полгода – рано, за неделю – уже поздно.

    Подмена понятий. Обычно операторы определяют клиента по номеру телефона, поэтому логично, что признаки нужно выгружать по нему. А что насчет лицевого счета или номера обслуживающего приложения? Нужно определиться, какую единицу следует принимать за клиента, чтобы данные в системе оператора не разнились. Оценка ценности клиента тоже под вопросом – какой абонент более ценный для компании, для удержания какого пользователя нужно приложить больше усилий, а какие «отвалятся» в любом случае и нет смысла тратить на них ресурсы.

    Недостаток информации. Далеко не все сотрудники провайдера способны объяснить команде BigData, что конкретно влияет на отток абонентов и как считаются возможные факторы в биллинге. Даже если назвали один из них – ARPU, – оказывается, что и его посчитать можно по-разному: или по периодическим платежам клиента, или по автоматическим начислениям биллинга. А в процессе работы возникает миллион других вопросов. Всех ли клиентов охватывает модель, какова цена за удержание клиента, есть ли смысл продумывать альтернативные модели и что делать с клиентами, которых стали по ошибке искусственно удерживать.

    Целеполагание. Я знаю три вида ошибок, связанных с результатом, которые заставляют операторов разочаровываться в БД.

    1. Провайдер вкладывается в BigData, обрабатывает гигабайты информации, но получает итог, который мог бы получить и дешевле. Используются простые схемы и модели, примитивная аналитика. Себестоимость в разы выше, а результат тот же.
    2. Оператор получает на выходе многогранные данные, а как их использовать – не понимает. Аналитика есть – вот она, понятная и объемная, а толку от нее – ноль. Не продуман конечный результат, который не может состоять из цели «обработать данные». Обработать мало – аналитика должна стать базой для обновления бизнес-процессов.
    3. Препятствием для использования аналитики BigData могут становятся устаревшие бизнес-процессы и неподходящий для новых целей софт. Значит, сплоховали на этапе подготовки – не продумали алгоритм действий и этапы внедрения BigData в работу.

    Зачем


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

    1. Анализируется информация о перемещении абонентов, активности и частотных сервисах. Результат: снижение количества перегрузок за счет оптимизации и модернизации проблемных участков инфраструктуры,.
    2. Информацию о геолокации абонентов и плотности потока операторы связи используют при открытии точек продаж. Так аналитику BigData уже используют МТС и Вымпелком для планирования расположения новых офисов.
    3. Провайдеры монетизируют собственные большие данные, предлагая их сторонним фирмам. Основные заказчики BigData операторов – коммерческие банки. С помощью БД они отслеживают подозрительные активности SIM-карты абонента, к которой привязаны карты, пользуются сервисами рискового скоринга, верификации и мониторинга. А в 2017 динамику передвижения по данным BigData запросило у Tele2 правительство Москвы – для планирования технической и транспортной инфрастуктуры.
    4. Аналитика BigData – золотая жила для маркетологов, которые могут создавать персонализированные рекламные кампании для целых тысяч групп абонентов, если захотят. Телеком-компании агрегируют социальные профили, потребительские интересы и поведенческие модели абонентов, а потом используют собранную BigData для привлечения новых клиентов. Но для масштабного планирования продвижения и PR у биллинга не всегда хватает функционала: программа должна одновременно учитывать множество факторов параллельно с детальной информацией о клиентах.

    Пока кто-то до сих пор считает BigData пустым звуком, «большая четверка» уже делает на ней деньги. МТС за полгода зарабатывает на обработке больших данных 14 миллиардов рублей, а Tele2 увеличил выручку от проектов в три с половиной раза. BigData превращается из тренда в must have, под который будет перестраиваться вся структура операторов связи.

    Комментарии 5

      +1
      Стандартно большие данные характеризуются тремя признаками VVV, хотя в вольных интерпретациях количество «V» доходило и до семи.

      42 V’s.

        +3
        Сергей, 23 упоминания уже похабного термина Big Data на такую маленькую маркетинговую статью… Не много?

        Будет круто если наконец-то расскажете о своей реализации биллинга с техническими подробностями (во всех Ваших статьях — ни слова). Все-таки это Хабр, а не LinkedIn/Facebook :-)

          –1
          Спасибо за замечание. Постараюсь подготовить такой материал, не обидев клиентов упоминаниями того-что-нельзя называть (а оно в разных кампаниях — разное:)
          0
          Было бы интересно рассмотреть реальные кейсы. Например, рассмотреть одну из реальных моделей, которая применялась для снижения оттока абонентов.
            0
            Постановка задач — чаще всего, всё начинается с «я тут видел у соседей любопытную штуку, давайте сделаем так же! Начинаем пилот» — именно в это месте нужно понять, что хочется и какие конкретно результаты и показатели будем оценивать: что можно поднять кластер с hadoop даже на бесплатных виртуалках — не вопрос.
            Что этот кластер будет как-то работать — ну, в общем, будет. И данные хранить будет.
            И что дальше?
            Зовите хороших аналитиков ( хотя б в аренду), смотрите похожие случаи внедрения — люди любят пиариться не только по теме «а вот мы с помощью больших данных зарабатываем 100500 денег в неделю!», но и с техническими деталями, прикидывайте, сколько будет требовать команда + железо — возможно, вы не окупите всё это или хватит 2 аналитиков, pandas и Excel на хорошем ноутбуке, анализировать срезы данных.

            Подмена понятий — туда же: никто не мешает сделать 1 срез данных с ключом по телефонному номеру, второй — по сложному ключу, например, по всем номерам, связанным с паспортом абонента на определённой территории, ещё пяток — на разные временные рамки и заниматься анализом.

            Недостаток информации: честное слово, не нужно объяснять всем сотрудникам команды, как считать APRU 8 способами — объясните это аналитикам ещё в 1 пункте, те напишут внятное ТЗ и будет у вас 8 типов APRU по клиентам /областям / периодам / сексуальной ориентации и предпочитаемой марке машины ( если железо позволит — в реальном времени и при желании — в 3d)

            Ну а если вы не можете даже поставить цели — лучше не начинайте это долгое, дорогое и неблагодарное дело.

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое