Привет! Меня зовут Ольга Татаринова, я руковожу отделом аналитики в Agima.ai. Один из самых частых запросов, с которым к нам приходят клиенты, такой: «Сделайте нам дашборд c бизнес-KPI. Мы хотим найти какие-то инсайты в наших данных, чтобы понять точки роста». Проблема с такой постановкой задачи в том, что дашборды хорошо помогают следить за бизнес-kpi. Но напрямую мешают находить инсайты в данных.

Есть такой старый анекдот.

Полицейский подходит на улице к человеку, который ползает под фонарём.

— Что вы тут делаете? — спрашивает полицейский.
— Ключи ищу, — отвечает человек.

Они вдвоём какое-то время безуспешно ищут ключи, и наконец полицейский спрашивает:

— А вы уверены, что вы их именно тут потеряли?
— Нет, — говорит человек. — Я их в парке потерял!
— А почему же здесь ищете?
— А здесь светлее!

Феномен поиска под фонарем того, что потеряно в другом месте, известен как «эффект уличного освещения» (или эффект поиска пьяницы), и он на удивление распространён. Люди склонны искать ответы там, где информация легкодоступна, а не там, где на самом деле есть ответы.

В случае с анализом данных этот эффект работает так: бизнес-пользователи смотрят на дашборд и видят, что, например, средний чек заказа на прошлой неделе упал. И задают совершенно правильный вопрос: «А почему средний чек упал?»

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

Но из-за «эффекта уличного освещения» бизнес-пользователи зачастую:

• просматривают все доступные дашборды в поисках ответа, почему (и не получают его);

• ставят задачу аналитикам «добавить ещё фильтры на дашборд», ждут задачу неделю, перебирают все фильтры и не получают ответа;

• собирают менеджмент-митинг и поручают аналитикам «сделать уже дашборд, на котором будет всё понятно», и кончено, никогда его не получают (но получают дашборд на 17 экранов графиков, который запутывает окончательно).

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

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

На всех проектах для заказчиков мы обязательно готовим данные для использования в режиме самообслуживания. За пять лет практики мы поняли, как сделать Self-service-подход проще для бизнес-пользователей.

Типичные проблемы данных при Self-service-подходе

1. В Self-service-режиме доступны только данные веб-аналитики.

Самый частый пример данных, доступных для самостоятельного изучения бизнес-пользователями, это данные веб-аналитики. Зачастую продакт-менеджеры и другие бизнес-пользователи умеют следить за метриками в Google Analytics или Amplitude. Но если смотреть только в события веб-аналитики, то можно пропустить важные вещи, которые нельзя залогировать в качестве веб-событий.

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

2. В Self-service доступны только самые очевидные данные.

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

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

3. Много точек входа в Self-service, непонятно, с чего начинать исследование данных

При проектировании аналитических витрин первое, что хочется сделать, это собрать отдельную таблицу под каждое понятие предметной области (например, USERS, ORDERS, SUBSCRIPTIONS и т. п.). Отношения между этими таблицами довольно быстро становятся сложными, и приходится возвращаться к SQL или обращаться за помощью к аналитикам.

Сейчас мы стараемся свести весь Self-service к одной витрине, которую мы называем таймлайн, за который «зацеплены» все остальные таблицы (пользователи, заказы, подписки и т. п.). Это обеспечивает бизнес-пользователям одну точку входа во все данные, что сильно упрощает начало работы.

4. «Технический шум» в данных.

В любом наборе данных всегда много частичного дублирования информации и технических колонок, например, ключи партицирования, метаинформация. Часть атрибутов дублируется в нескольких таблицах.

Такой «технический шум» отвлекает внимание и мешает исследовать данные.

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

5. Отсутствие документации.

Чтобы бизнес-пользователи могли работать с Self-service-слоем, каждый атрибут, вынесенный в Self-service, должен быть:

• уникально поименован;

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

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

Выводы

Подводя итог всему вышесказанному, хочу сформулировать несколько тезисов:

1. В компаниях сейчас много данных, но зачастую мало инсайтов. Отсутствие инсайтов во многом обусловлено «эффектом уличного освещения»: все ищут инсайты там, где светлее (на дашбордах), а не там, где они на самом деле есть (в полном наборе данных).

2. Полные наборы данных в BI-системах сейчас доступны только «элите»: аналитикам и Data-scientist’ам. И недоступны людям, которые должны принимать бизнес-решения на основе данных: продакт-менеджерам, маркетологам, финансистам. Зачастую люди, принимающие конкретные проектные решения, не знают, какие данные доступны в принципе и поэтому принимают бизнес-решения интуитивно.

3. Основной задачей аналитиков должна стать не «подготовка отчетов по запросу бизнеса», а подготовка такой среды, в которой бизнес самостоятельно мог бы получать ответы на свои вопросы.

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