Мы в Mediascope считаем аудиторию ТВ, интернета, радио и прессы. Мониторим контент в СМИ. Измеряем потребительские предпочтения россиян. Фиксируем выходы рекламы во всех медиа. В результате пользователи наших данных получают огромное количество датасетов для анализа и решения самых разных задач бизнеса. Кроме того, многие наши данные лежат в основе рекламных взаиморасчетов медиарынка и являются своего рода индустриальной "валютой" в диалоге разных его игроков.

Кому все это нужно? Компаниям, работающим на российском рынке рекламы (сегмент - сугубо В2В) - непосредственно СМИ, медиа-холдингам, рекламным агентствам и компаниям-рекламодателям.

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

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

Для мониторинга ТВ респондентам устанавливают оборудование на телевизоры в домохозяйстве, передающее нам данные об их телесмотрении (устройство в активном режиме записывает отрезки аудиосигнала и передаёт нам для распознавания).

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

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

Что происходит у нас в ИТ

Если эту схему рассмотреть на примере измерений одного из медиа (ТВ), то у нас есть 3 основных источника данных:

• Данные об активности от респондентов (от измерительного оборудования);

• Данные автоматического мониторинга ТВ, чтобы понимать, какой контент идет в конкретное время на телеканалах;

• Социально-демографические (в общем виде), технические данные и текущий статус респондентов.

С очень большой высоты схема проста:

• Данные с оборудования надо объединить с данными мониторинга, чтобы получить данные медиа-контактов респондентов;

• Затем надо перейти от устройств к респондентам и подключить их соц-дем данные;

• В итоге - возможность расчета необходимых аудиторных показателей телеканала или конкретного эфирного события, например, “доля”, “рейтинг”, “охват”.

Эту концептуальную схему реализуют в Mediascope десятки систем. В ИТ над ними работают два десятка команд разработчиков, дата-сайентистов, системных аналитиков, дата аналитиков и архитекторов.

Даже укрупненная схема процесса сбора и обработки данных не помещается на картинку, поэтому тут будет постер:

В целом наши информационные потоки можно разделить на группы процессов и ИТ-систем:

• каналы измерения (input),

• процесс мониторинга эфира,

• процесс управления панелью в рамках системы управления панелью (СУП),

• основное производство в собственной Big Data Platform,

• процесс доставки данных клиентам - Delivery,

• DataLab - рабочее пространство для самостоятельного анализа данных клиентами,

• управление справочниками и мастер-данными,

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

Ниже несколько слов о группах систем, без погружения в детали.

Каналы измерения (input)

Это самая сложная и разнообразная группа систем в Mediascope. Несмотря на то, что у нас есть несколько технологий для измерений разных типов медиа, мы регулярно исследуем новые возможности для медиаизмерений, создаем новые подходы и технические решения.

Сейчас исследуем технологию аудиометки в контенте, которую могут ловить наши технические устройства.

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

В интернете и мобильных измерениях стоит такая же задача, но решается по-своему в каждом канале.

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

Input системы построены на:

• java script для счетчиков и измерительных агентов;

• мобильные разработка (Kotlin/Java, С++ Swift, Objective-C/C) и обработка данных Python, PostgreSQL, C++, CUDA C++;

• Java, python для REST API;

• Apache Kafka;

• NiFi;

• Mongo DB, Hbase.

Процесс мониторинга

Для мониторинга каждого медиа применяются свои технические решения, подходы и технологии, имеются свои сложности и нюансы.

Например, в интернете интересно то, что у части роликов (фрагменты шоу, фильмов или новая серия сериала) может быть неограниченный “срок досмотра” и время между выходом оригинала и перепостом. И тут перед нами стоит задача выявить дубли контента с помощью технологий аудио и видеораспознавания. Если подойти к ней напрямую, то количество работы по распознаванию будет расти квадратично - каждую новую единицу контента нужно сравнить с теми, что уже были. И новые добавить в библиотеку.

Чтобы объемы работ по распознаванию не росли катастрофически, у нас применяются сложные правила и алгоритмы индексации контента до распознавания с применением машинного обучения. Сам контент живет в активной (идущей в распознавание) части библиотеки ограниченное время, которое регулируется бизнес-правилами и алгоритмами.

Какие технологии и классы систем работают у нас в мониторинге:

• MS SQL, PostgreSQL

• .NET C#, C/C++, java

Основное производство данных в собственной Big Data Platform

Платформа построена на основе Hadoop кластера по схеме снежинки в подходе Билла Инмона - с условно нормализованной Корпоративной Моделью Данных, на основе которой производятся промежуточные и финальные витрины.

Вся поступающая из разных источников информация сливается в Data Lake, затем выборочно интегрируется в псевдо-реляционную Корпоративную Модель Данных, затем идет поэтапная наливка промежуточных и финальных витрин данных. Работа разделена на трансформации, запускаемые в Spark контексте. Оркестрацию выполняет Apache Airflow, контролирующий и выполняющий так называемые Direct Acyclic Graph-ы - сети работ.

Чтобы конфигурацию конвейера могли понимать и менять не только программисты, перед созданием DAG-а в Airflow происходит трансляция конфигурационных описаний из специального формата, который является компромиссом между человеко-читаемостью и машино-читаемостью и представляет из себя Domain Specific Language.

В общей сложности в производстве у нас сейчас работают ~700 трансформаций в ~70 DAG-ах, наливающих в ~400 таблиц ~2000 отдельных пакетов данных по собственному набору параметров.

Технологическая карта не самого маленького DAG-а выглядит примерно так:

Каждая заполненная ячейка - это операция - вызов трансформации с собственным набором параметров. Обычно трансформация имеет от 10 до 20 параметров, описывающих входные, выходные потоки, логические и технические параметры алгоритма.

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

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

Кроме перечисленного, также активно используем S3, собственные сервисы на java, python с БД на PostgreSQL. Внедряем Apache Flink.

Функции основного производства данных

Маппинг - это не всё, чем занята производственная платформа.

Вот основные группы функций производства:

• Взвешивание - переход от активности измерительной панели (совокупности наших респондентов) к данным по генеральной совокупности. Как это работает, знают наши социологи-аналитики, математики и архитекторы в компании :)

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

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

• Fusion - это самая сложная, капризная и загадочная процедура с точки зрения программистов. Правда в том, что по историческим, методическим и техническим причинам панелей несколько - на одних респондентах мы измеряем телесмотрение, на других - активность в интернете, на третьих - в мобильных устройствах. До какого-то момента это было нормально. Но потом стало ясно, что доля медиапотребления в интернете становится заметна, часто догоняет или в каких возрастных группах даже перегоняет потребление в телевизоре. Ясно, что если мы даём охват рекламного ролика 60% в телевизоре и 70% в интернете, то в сумме получается 130%. На самом деле часть респондентов видела ролик и там и там. Fusion - это процедура отображения активности из одной панели на другую. Сейчас наши математики, методологи и продуктовые менеджеры строят новый кроссмедийный продукт, основанный на увеличении доли пересечения телевизионной, мобильной и интернет десктоп-панелей.

• Калибровка - поскольку многие данные проходят сложные математические и эвристические преобразования, основанные на статистике, результаты могут показывать погрешность относительно реальных данных. Например, суммарная посещаемость какого-то ресурса может оказаться завышена или занижена относительно собственных счетчиков ресурса. Для коррекции таких отклонений применяется процедура калибровки. Там такая же сложная математика, которую наши математики даже пока ещё не доверяют разработке :)

• Производство индексов и формирование выходных витрин - тут всё ясно, но тоже интересно. Надо насчитать нужные клиентам срезы, представления, и т.п.

• Производство проекта Brand Pulse - это отдельное производство данных потребительских предпочтений россиян.

Процесс доставки данных клиентам - Delivery

Раньше мы просто выкладывали на FTP файлы в формате под специализированное ПО, в котором работают наши клиенты. Перед этим проходил процесс финальной проверки данных в конечном формате. Сейчас мы тоже так еще делаем. Только в телевизионных измерениях мы каждый день выкладываем ~150 разных пакетов данных разного назначения для разных групп клиентов.

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

Новая система Delivery построена на:

• Clickhouse,

• java,

• Airflow,

• REST API,

• Для распределения ресурсов между вычислительными задачами мы используем алгоритмы машинного обучения.

DataLab - это рабочее пространство для самостоятельного анализа данных клиентами. Для тех из них, у кого есть собственные дата-аналитики и желание сделать собственные расчеты на сырых данных, мы предоставляем ограниченный доступ с использованием HIVE прямо в кластер к данным и вычислительным мощностям. Клиент может взять Zeppelin или Jupiter, самостоятельно написать запросы и увидеть результаты.

Управление справочниками и мастер-данными

Огромное количество параметров, установочных данных, справочников, нужных в нескольких системах управляются через систему Reference Data Management на основе Ataccama RDM. Это нужно, чтобы математики, дата-аналитики и аналитики из бизнес-подразделений не сталкивались с километрами конфигов в Gitlab репозиториях, не заводили тикеты в разработку для загрузки справочников в виде релиза. И при этом мы видели всю историю изменений настроек и ясно понимали, в какой производственный цикл попадут измененные настройки.

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

Этим рассказом в общих чертах о наших процессах мы предваряем серию более подробных статей о некоторых наших системах, вызовах, интересных решениях, находках и открытиях.