В работе над продуктом данные — это главный помощник. С их помощью принимают решения на всех этапах — от создания до развития. Вместо того чтобы гадать, как поступит пользователь, смотрят на реальные факты: как люди пользуются продуктом и какие результаты это даёт бизнесу. А что на счет самих данных, если мы их рассматриваем как продукт? Как будем оценивать их ценность, как будем планировать их развитие?
В статье предлагаю экспериментальный набор UX‑метрик: они помогут увидеть, где ваш продукт реально теряет пользу для пользователя. Методика готова к тестированию — цифр пока нет, но каркас для расчётов уже работает.
Предисловие
Хочу в этой статье попробовать рассмотреть подход работы с данными как с продуктом. В продуктовом подходе важна ценность, которую продукт приносит пользователям. Встает вопрос: какими метриками можно будет определить эту ценность?
Известные источники такие как DAMA-DMBOK говорят нам, что ценность данных определяется их пригодностью для решения конкретных бизнес-задач. А именно выделяют метрики управления метаданными, качество данных, безопасность данных и интеграция данных.
Но мне было интересно рассмотреть данные немного с другой стороны - со стороны удобства их использования - User Experience (UX).
Я решила попробовать найти некоторые метрики показывающие направление развития продукта для их владельца без необходимости проведения CSAT опросов, потому как сложность взаимодействия с данными может указывать не только на потенциальные проблемы, но и показывать точки развития для продуктовой команды.
Сразу оговорюсь, что хотя в статье нет конкретных цифр и графиков, в ней есть подход, который можно применить для их расчета и построения отчётности. Этот подход экспериментальный, я скорее хочу предложить идею и вариант её реализации. Если мой эксперимент будет удачным, я опубликую его результаты в следующей статье. В любом случае я надеюсь статья станет отправной точкой для анализа.
На чём будем считать?
Базовым интерфейсом для получения данных пользователем являются sql-запросы, потому и попробуем определить метрики для подсчета удобства UX исходя из анализа этих запросов.
Такой анализ можно проводить только на базе собранных запросов за некоторый анализируемый промежуток времени. Подобные данные в больших Хранилищах собирают для анализа по различным целям: можно оценивать и прогнозировать нагрузку на базу, очереди, оптимальность запросов и другие показатели. Сбор помогают организовать админы базы из логов и т.п.
И вот допустим мы собрали такие данные хотя бы за месяц (а лучше даже за квартал), мы видим какие запросы запускали наши пользователи, сколько они длились, какую нагрузку оказали на базу, был ли это ddl или dml и пр. Попробуем определить из них удобство использования данными.
Анализируем sql-запросы
Пробуем определить их сложность
В первую очередь пользователю нужно было составить запрос для получения некоторой важной для него информации. Такой запрос мы можем попробовать охарактеризовать исходя из его синтаксиса как простой или сложный. А вернее даже посчитать его сложность как метрику.
Будем отталкиваться от того, что запрос вида select * from table - это простой запрос, потому как составить его очень легко, не требуются специальные навыки sql. Можем присвоить ему некоторый условный вес, равный 1 к примеру.
Теперь рассмотрим, что будет усложнять работу пользователя:
если для получения набора данных нужно джойнить несколько таблиц, то пользователю пришлось как-то определить список этих таблиц, понять как правильно их джойнить. А это может означать что наличие каждого join в синтаксисе запроса усложнит его. В численном эквиваленте мы можем добавить вес каждого такого джоина;
если в запросе есть агрегация данных (group by), это означает что пользователю пришлось разобраться со структурой данных в таблице, но можем предположить что подобная операция была проще чем поиск других таблиц, т.е. вес операции group by вероятно ниже веса join;
также сложность получения данных мог вызвать формат этих данных, если для составления запроса пришлось использовать replace или case.
Исходя из подобных рассуждений каждому оператору sql можем выставить условный вес. Сложение этих весов даст нам метрику - сложности запроса.
Как подобная метрика будет показывать владельцу продукта решает ли он проблемы пользователей: предполагаем, что чем сложнее запрос, тем больше времени пользователь затратил на его составление.
Но допустим это был разовый запрос, который в дальнейшем поставили на расписание. Много ли таких запросов? Насколько их больше чем других?
Учтём однообразные запросы
На такие вопросы нам поможет ответить метрика однообразия запросов. Чтобы её посчитать придется каждый запрос привести к какому-то одному формату, сделать всё в lowercase, убрать различные условия потому как для анализа сложности нет разницы какой именно id указали в условии where. Задача не очень простая, но решаемая.
И в результате мы получаем некие шаблоны sql, сложность которых мы можем посчитать по алгоритму приведенному выше.
Теперь мы можем посчитать метрику однообразия как количество запросов по одному sql-шаблону за заданный интервал.
Приведу пример, допустим у нас есть вот такой шаблон:
select * from incoming_call where telephone_num = '?'Для такого шаблона подойдут запросы вида:
select * from incoming_call where telephone_num = '123456789' limit 5;
select * from incoming_call where telephone_num = '987654321';И если в какой-то день подходящих под шаблон запросов было 100, то метрика однообразия будет равна 100.
А что ещё?
И вот у нас уже есть сложность и однообразие. Подумаем что ещё могло вызывать проблемы у пользователя при обращении к данным. На мой взгляд сложно бывает ждать выполнение самого запроса. Этот показатель тоже попробуем заложить в расчет удобства - длительность.
А также скорее всего пользователь сталкивался с вопросами получением доступа к данным. Показатель не совсем однозначный, считать его можно по разному. Но в целом мы можем попробовать отранжировать слои данных Хранилища и дать им некоторые веса. Исходим из того, что для пользователей специально были разработаны витрины данных (слой mart), доступ к которым получить было нетрудно. Но чем ниже слой данных в Хранилище, тем сложнее было обосновать необходимость обращаться именно к нему, а не к витринам. Т.е. в противовес витринам мы получаем самым труднодоступным слой сырых данных. Подобные веса можно учитывать в расчете сложности синтаксиса запроса.
Выводим формулу
Теперь для получения метрики удобства в некоторых условных "попугаях" мы можем сложить следующие усредненные за интервал показатели по каждому из шаблонов sql (обращу внимание, что оценим именно шаблоны, а не сами запросы):
Почему считаем именно так? Вот по каким рассуждениям:
Чем сложнее запрос к таблице, чем больше таких вот запросов по одному шаблону и чем дольше они выполняются, тем вероятнее всего было больше проблем у пользователя при работе с данными.
И с другой стороны простые, быстрые, разовые запросы вряд ли вызывали проблемы при обращении к данным. Это больше похоже на историю исследования данных.
Но что именно нам может показать эта метрика. Группировать её можно по разным показателям.
Так чтобы понять какие пользователи чаще всего сталкиваются с проблемами обращения к данным, выполним группировку по пользователям: чем выше показатели метрики, тем больше проблем у пользователей при обращении к данным, а значит тем вероятнее им нужна помощь с устранением таких проблем.
В тоже время, оценить с чем именно сложно работать можно при помощи группировки по таблице к которой обратился запрос. Т.е. если к таблице много сложных запросов, то это ведь повод предположить что хорошо бы сделать витрину данных.
Трактуем результаты
Приведу примеры гипотез, которые можно проверять для развития данных как продукта с целью улучшения пользовательского опыта:
Чем больше однообразных, сложных запросов, выполнения которых приходится долго ждать, тем больше поводов предложить этим пользователям помощь, создать для них витрину, к примеру, или рассказать о более простых вариантах получения данных если они уже есть, отразить это в документации.
Чем больше пользователей пишет сложных запросов к таблице по одному шаблону, тем больше поводов задуматься о реструктуризации данных.
Большое количество разнообразных запросов может свидетельствовать об активной исследовательской деятельности, которая требует больше ресурсов для выполнения рабочих обязанностей. А это может стать подходящим аргументом в пользу запроса этих ресурсов для такого отдела.
И отдельно можно рассмотреть простые запросы, которые занимают много времени на выполнение - это может стать показателем неэффективного хранения данных в базе (возможно стоит партиционировать данных, перераспределить их по другому ключу и пр.).
Заключение
В продуктовом подходе для определения пользовательской удовлетворенности используется опросы CSAT. Но увеличение количества опросов на мой взгляд лишь снижает пользовательскую удовлетворенность в целом. Текущий подход нацелен на поиск объективных метрик для подтверждение гипотез о дата продукте, которые совместно с CSAT могут показать точки роста и направления развития для команд дата-инженеров.