Кто отвечает за качество данных? Матрица ответственности для аналитических команд

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

Кто отвечает за качество данных в компании? Вопреки распространенному мнению, дело не только в аналитиках. Например, маркетологи работают с UTM-метками, инженеры — трекинг-кодами и т. д. Поэтому неудивительно, что при работе с данными возникает хаос: у каждого сотрудника много задач, и непонятно, кто чем занимается, кто за что отвечает и кого следует спросить о результате.

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

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

1. Настройте сбор первичных данных.
2. Собирайте необработанные данные в хранилище данных или базу данных.
3. Превратите необработанные данные в готовые для бизнеса данные с разметкой, очисткой и структурой, понятной для бизнеса.
4. Подготовьте витрину данных — плоскую структуру, которая служит источником данных для визуализации данных.
5. Визуализируйте данные для приборной панели.

Тем не менее, несмотря на всю подготовку, лица, принимающие решения, часто сталкиваются с отчетами или информационными панелями с данными низкого качества. И первое, что они делают, — обращаются к аналитику с вопросом: Почему возникает несоответствие? или Данные актуальны здесь?

Однако реальность такова, что в этих процессах участвуют разные специалисты: дата-инженеры занимаются настройкой системы аналитики, маркетологи добавляют UTM-метки, пользователи вводят данные. Давайте подробно рассмотрим, какие этапы нужно пройти и как их реализовать, чтобы предоставлять пользователям качественные данные.

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

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

• Не на всех страницах установлен контейнер GTM, поэтому данные не отправляются в Google Analytics.
• Создается новый аккаунт на рекламной площадке, но аналитики не информируются и данные с него не собираются.
• API не поддерживает динамические параметры в тегах UTM, не собирает и не передает их.
• На карте, подключенной к проекту Google Cloud, недостаточно средств или кредита.
• Неверная проверка данных, введенных пользователем.

На этом этапе, помимо всех других проблем, вы должны рассмотреть возможность управления доступом к данным. Для этого мы рекомендуем использовать классическую матрицу RACI, которая определяет роли для процессов и подчеркивает, кто делает, контролирует, управляет и за что отвечает. Вот возможные роли:

• R (Ответственный) — кто-то, кто отвечает за конкретный процесс и является его исполнителем.
• C (Consulted) — человек, который консультирует и предоставляет необходимые данные для реализации процесса
• A (Accountable or Approver) — тот, кто отвечает за результат работы
• Я (информированный) — лицо, которое должно быть проинформировано о ходе работы

Согласно матрице RACI роли и обязанности по сбору данных выглядят следующим образом:

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

Лучшим вариантом для этой задачи является Google BigQuery, так как он учитывает потребности маркетологов и может использоваться для хранения необработанных данных с веб-сайтов, CRM-систем, рекламных площадок и т. д. На сегодняшний день существует множество маркетинговых программных решений. Мы рекомендуем OWOX BI, который автоматически собирает данные в хранилище данных (или озеро данных) с разных сервисов и сайтов.

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

• Изменился API рекламного сервиса. Соответственно изменился и формат данных.
• API внешней службы недоступен. Стейкхолдер видит в личном кабинете одни цифры, но API того же рекламного сервиса дает другие данные. Эти данные не совпадают, потому что, как и в любой распределенной системе, источник данных для API рекламного сервиса отличается от источника данных для веб-портала.
• Данные в веб-интерфейсе и API внешнего сервиса отличаются. Форматы документации и обработки данных могут быть различными. Например, интересная ошибка в одном из популярных рекламных сервисов заключается в том, что расходы равны нулю как тогда, когда их нет, так и тогда, когда они фактически равны нулю. Все инженеры данных и аналитики знают, что ноль и Null — разные значения и обрабатываются по-разному. В одном случае эти расходы могут появиться и их нужно запрашивать заново, а ноль означает, что их действительно нет и они считаются за ноль.
• API внешнего сервиса предоставляет неверные данные.

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

Есть также разработчики, которые хотят знать, какие изменения произойдут с контейнерами, если использовать Диспетчер тегов Google, поскольку они отвечают за скорость загрузки веб-сайта.

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

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

Подготовка данных – следующий шаг. Его часто называют подготовкой витрины данных — это плоская структура, содержащая те параметры и метрики, которые будут представлены на дашборде. Аналитик, ограниченный в инструментах, бюджете и времени, часто пропускает этап подготовки бизнес-данных и сразу готовит витрину данных. Это похоже на необработанные данные, собранные в хранилище данных. Потом миллион разных SQL-запросов вместе с Python и R-скриптами — и эта каша выльется во что-то на дашборде.

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

• Регулярные ошибки в первичных данных
• Бизнес-логика дублируется во всех запросах SQL
• Много времени требуется, чтобы найти причины расхождений данных
• Время на доработку существующих витрин данных сравнимо со временем на переписывание запроса
• Логика отчета непонятна заказчику

Самый простой и распространенный пример ошибки — определение нового пользователя и возвращенного пользователя . Большинство компаний не делают этого различия так же, как Google Analytics. Поэтому логика определения типов пользователей часто дублируется в разных отчетах. К частым ошибкам относится и непонятная логика отчета. Первое, о чем спросит бизнес-клиент, просматривая отчет, — как он был построен, на каких предположениях основывался, для чего использовались данные и так далее. Поэтому подготовка бизнес-данных — это этап, который точно нельзя пропускать. Создавать витрину данных из необработанных данных — это все равно, что не мыть овощи и фрукты перед тем, как съесть их.

Если распределить обязанности по матрице, то для подготовки данных получим вот что:

Готовые для бизнеса данные — это очищенный окончательный набор данных, соответствующий бизнес-модели. Это готовые данные, которые можно отправить в любой сервис визуализации данных (Power BI, Tableau, Google Data Studio и т. д.).

Естественно, разные предприятия работают по разным моделям. Например, определения «пользователи», «пользователи B2B», «транзакции», «лиды» ​​и т. д. будут означать разные вещи для разных компаний. Эти бизнес-объекты фактически отвечают на вопрос о том, как бизнес думает о своей бизнес-модели с точки зрения данных. Это описание бизнеса в его основе, а не структура событий в Google Analytics.

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

Что может пойти не так на этом этапе:

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

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

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

По нашему опыту, некоторые компании до сих пор не подготавливают готовые для бизнеса данные и не строят отчеты на необработанных данных. Основная проблема такого подхода — бесконечная отладка и переписывание SQL-запросов. В долгосрочной перспективе дешевле и проще работать с подготовленными данными, чем снова и снова бегать по необработанным данным, выполняя одни и те же действия.

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

Закажите бесплатную демонстрацию, чтобы узнать, как OWOX BI помогает в подготовке бизнес-данных и как вы можете извлечь выгоду из полностью автоматизированного управления данными уже сегодня.

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

Зачем аналитикам нужна витрина данных и почему не стоит пропускать этот этап? Маркетологам и другим сотрудникам без аналитических навыков сложно работать с необработанными данными. Задача аналитика — предоставить всем сотрудникам доступ к данным в наиболее удобной форме, чтобы им не приходилось каждый раз писать сложные SQL-запросы.

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

Основные случаи, когда что-то может пойти не так при подготовке витрины данных:

• Логика слияния данных непонятна. Например, могут быть данные из мобильного приложения и сайта, и вам нужно решить, как их объединить и по каким ключам, или решить, как объединить рекламные кампании с действиями в мобильном приложении. Есть много вопросов. Принимая эти решения при подготовке бизнес-данных, мы принимаем их один раз, и их ценность выше, чем те решения, которые принимаются специально для конкретного отчета здесь и сейчас. Такие ситуативные решения должны приниматься неоднократно.
• Запрос SQL не выполняется из-за технических ограничений хранилища данных. Подготовка бизнес-данных — это один из способов очистки данных и преобразования их в смоделированную структуру, которая удешевляет обработку и ускоряет запросы.
• Непонятно, как проверить качество данных .

Посмотрим, кто за что отвечает на данном этапе по матрице:

Очевидно, что за подготовку данных отвечают аналитики данных, а также заинтересованные стороны и инженеры данных, которые являются консультантами в этом процессе. Обратите внимание, что с этой задачей за вас могут справиться аналитики OWOX BI. Мы можем собрать и объединить данные, смоделировать их для вашей бизнес-модели и подготовить витрину данных, сопровождаемую подробной инструкцией с описанием логики построения, позволяющую при необходимости внести изменения на вашей стороне (например, добавить новые поля).

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

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

• Неактуальные данные в киоске данных. Если бизнес не уверен в качестве данных, то даже если данные высокого качества, первый шаг для бизнес-клиента — попросить аналитика перепроверить все. Это неэффективно. Понятно, что бизнес хочет уберечься от ошибок и не спешить с выводами. Поэтому высокое качество данных — это гарантия того, что ими потом кто-то воспользуется.
• Выбор неверного метода визуализации данных.
• Не правильно объясняя заказчику логику расчета метрик и параметров. Часто для того, чтобы бизнес-клиент, не знакомый с SQL и метриками, мог правильно интерпретировать данные, ему необходимо видеть, что означает каждая метрика в контексте отчета, как она рассчитывается и почему. Аналитики не должны забывать, что любой, кто использует отчет, должен иметь доступ к объяснению того, что стоит за отчетом, какие предположения лежали в основе отчета и т. д.

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

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

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

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

Для тех, кто хочет внести свой вклад в улучшение качества данных своей компании, мы рекомендуем три простых шага:

1. Создайте схему потока данных. Например, используйте Miro и нарисуйте, как ваша компания использует данные. Вы удивитесь, сколько разных мнений по поводу этой схемы внутри одной компании.
2. Составьте матрицу ответственности и договоритесь, кто за что отвечает, хотя бы на бумаге.
3. Опишите бизнес-модель данных.

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

Получить матрицу

Кроме того, команда OWOX BI может помочь вам настроить и автоматизировать все этапы работы с данными, описанные в этой статье. Если вам нужна помощь с какой-либо из этих задач или вы хотите проверить свою систему аналитики и качества данных, закажите демонстрацию.

1. Темные данные: почему то, чего вы не знаете, имеет значение, Дэвид Дж. Хэнд
2. Сигнал и шум: почему так много предсказаний сбываются, а некоторые нет, Нейт Сильвер
3. Предсказуемая иррациональность доктора Дэна Ариэли
4. Иррациональная обезьяна: почему мы поддаемся дезинформации, теории заговора и пропаганде Дэвида Роберта Граймса
5. Опыт «Экосистемы данных» Антрикша Гоэля