Меня зовут Виктория Агейкова, и я занимаюсь аналитикой 7 лет. Работала в найме и на фрилансе, в маркетинге и в продукте, преподавала в Международной школе профессий. В первые годы работы я сама совершала ошибки, а теперь встречаю те же проблемы у младших коллег, даже у аналитиков с опытом.
Дело в том, что в университетах и на курсах аналитики обычно учат хард-скиллам: как группировать и анализировать данные, как строить отчёты и делать из них выводы. Но никто не учит вести переговоры с заказчиком, грамотно оценивать риски и учитывать другие детали, которые напрямую влияют на репутацию аналитика.
Эти навыки приходят с опытом. Но гораздо проще стартовать в профессии, изучив чужие ошибки, чем набивать шишки самостоятельно.
В этой статье я разбираю 4 реальных задачи, с которыми сталкивалась в работе. Здесь не будет очевидных советов в духе «делайте хорошо, а плохо не делайте», только реальные решения, которые удобно использовать в работе.
Итак, начнём.
Делать задачу, не разобравшись, выгодна ли она компании

Задача: собрать дашборд, чтобы выводить все данные на один экран
Компания хранит данные по аналитике в разных источниках: отчёты по сайту в одной системе, по рассылкам — в другой, по маркетплейсам — в третьей. Руководитель поручил объединить эти данные в одном дашборде, чтобы менеджерам было проще работать.
Как не надо делать: браться за задачу, не оценив выгоду для компании.
Данные в разных инструментах |
Создание дашборда |
менеджер тратит 2 часа в неделю |
менеджер тратит 1 час в неделю аналитик тратит 40 часов на разработку дашборда аналитик тратит 1,5 часа в месяц на поддержание отчёта |
Дашборд мог бы окупиться на очень долгом промежутке времени, но, как правило, он становится неактуальным уже через год. Меняются инструменты, специалисты, структура продаж — и нужен новый инструмент, более подходящий под текущие реалии.
Как надо сделать: посчитать затраты и принести заказчику расчёт, почему дашборд не выгоден для компании. Да, аналитик не выполнит поставленную перед ним задачу. Зато придумает, как компании не потратить деньги зря и направит свой ресурс в более полезную задачу. А значит, проявит себя как более профессиональный специалист.
Выполнить задачу строго по ТЗ, не осмыслив её критически

Задача: Продуктовая команда онлайн-магазина хочет проверить, поможет ли новая фича поднять конверсию на сайте.
В прежней версии сайта товарные карточки располагались списком друг за другом, на экране пользователь видел всего 5 товаров. В новой версии карточки стали отображаться матрицей: на экране умещалось уже 15 товаров.
Команда хотела запустить новую версию сайта только на часть пользователей и провести a/b-тестирование, чтобы сравнить, увеличится ли конверсия. Ключевой метрикой выбрали «конверсию в заказ» по всему сайту. Это было ошибкой.
Как не надо делать: выполнять задачу строго по ТЗ, рискуя получить неверные данные. Разберём несколько примеров.
Ложный вывод |
А как на самом деле |
Цена ошибки |
Конверсия не меняется, значит, фича ни на что не влияет – не внедряем |
Люди чаще добавляют товар в корзину, но на сайте неудобная форма оформления заказа с десятком полей для заполнения. Пользователи ленятся их заполнять и уходят с сайта |
Магазин теряет выгоду, лишая себя фичи, которая помогла бы увеличить продажи |
Конверсия падает, значит, фича вредит – не внедряем |
Люди чаще добавляют товары в корзину, сайт перегружен и зависает, люди не дожидаются, когда загрузится корзина и уходят с сайта |
|
Конверсия растёт, значит, фича полезная – запускаем на всём сайте |
Конверсия в заказ растёт из-за внедрения нового флоу покупки. При этом непонятно, как в действительности повлияла новая товарная сетка |
Магазин впустую тратит время работы нескольких команд: дизайнеров, разработчиков, тестировщиков, аналитиков. Они внедряют фичу, которая не влияет на продажи |
Как надо сделать: критически оценить данные задачи и выбранные метрики.
Правильный выбор метрики — ответственность аналитика. Поэтому первым делом он должен понять, на какой этап воронки влияет тестируемая фича. В нашем случае расположение товарной сетки напрямую связана с тем, как быстро человек найдёт нужный товар и положит в корзину. То есть нужная нам метрика — «конверсия в добавление в корзину».
«Конверсия в заказ» может быть второстепенной метрикой, которая поможет обнаружить проблемы на сайте.
Сразу отправить клиенту полученные данные

Задача: Компания хочет получить финмодель, чтобы оценить доходность и маржинальность нового продукта. Аналитику предстоит изучить большое количество данных из разных источников, обработать, исключить ошибки, разработать на их основе финмодель.
Как не надо делать: как можно быстрее сделать все расчёты и отдать их клиенту, не проверив полученные данные.
Что может пойти не так: |
Цена ошибки |
Клиент изучает финмодель, сверяет со своими метриками и находит несостыковки. Выяснится, что не сходятся средний чек и выручка по годам. Аналитик проверяет свои расчёты и находит в них ошибку |
Увеличиваются сроки выполнения задачи Затягивается запуск нового продукта Портится репутация аналитика, растёт недоверие и недовольство клиента |
Как надо сделать:
При работе с большим количеством данных ошибки встречаются часто. Скорее всего, перепроверять и находить нестыковки всё равно придётся. Поэтому лучше сделать это заранее, чтобы не тратить время клиента на знакомство с неверными расчётами. Такой подход показывает профессионализм аналитика.
Как не потратить тонну времени на проверку
Чтобы не делать всю работу дважды, составьте чек-лист с нюансами, ограничениями и промежуточными расчётами. Заранее запросите у клиента значения нужных метрик и сравнивайте со своими значениями, чтобы обнаружить несовпадения на раннем этапе.
Разберём на примере шаблона данных о продажах. Его структура универсальна: вы можете взять эту таблицу за основу, подставить свои метрики, методы и ограничения, выбрать собственный период и уровень детализации — и пользоваться.
Какие метрики считаем за год в разрезе месяца: |
Метод расчёта |
Ограничения |
Чек-лист: сошлось/не сошлось |
кол-во заказов выручка средний чек кол-во покупателей кол-во уникальных товаров в чеке кол-во товаров в чеке прибыль рентабельность |
уник. кол-во order_id цена товара * кол-во товара сумма продаж/кол-во заказов уник. кол-во customer_id ср. кол-во уник. sku_id в одном чеке ср.кол-во товаров (в шт.) в одном чеке выручка - себестоимость продаж и товара прибыль/выручка |
Исключаем B2B-сегмент, считаем только онлайн-покупки. Не учитываем подарочные товары с 0 стоимостью и пакеты |
☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ |
Оценить сроки выполнения задачи по минимуму и не заложить риски

Задача: разработать программу лояльности для розничного магазина.
Как не надо делать: определить с клиентом задачи, заложить сроки на их выполнение и не оставить дополнительного времени на случай, есть что-то пойдёт не так. А что-нибудь обязательно пойдёт не так — в такой большой задаче это неизбежно.
Что может пойти не так |
Цена ошибки |
Общение с командой заказчика занимает больше времени, чем планировали. Клиент хочет провести дополнительный созвон, создать ещё один чат, подключить к работе несколько отделов. Данные разрозненные и хранятся в разных источниках, их долго и сложно связать между собой и обработать Клиент добавляет новые запросы, просит посмотреть данные в разных разрезах |
Аналитик работает ночами, потому что не успевает выполнить работу Не успевает в срок и по условиям договора выплачивает штраф |
По опыту работы более чем на 20 крупных проектах я поняла, что на риски нужно закладывать около 30% времени. Если заложить меньше, рискуешь обмануть ожидания заказчика и испортить репутацию.
Какие риски важно учесть:
Менеджмент |
Аналитическая работа |
Созвоны и переписки с клиентом Презентация работы команде Оформление документов |
Обработка и проверка данных Правки и доработки Изменение требований Мощность компьютера и производительность программ: скорость обработки данных |
Надеюсь, эта статья позволит вам избежать ошибок в работе и поможет вырасти как специалисту. А если у вас есть дополнения к моим кейсам или свои способы избежать аналогичных ошибок, пишите в комментарии, буду рада обсудить.
miksoft
В мало-мальски крупной компании это практически невозможно сделать, т.к. число участвующих лиц и длина тракта данных могут быть велики.
Или, если таки сделать, такой расчет может выйдет дороже самого дашборда.
Да и ценность часа менеджера и часа аналитика/разработчика могут быть сильно не равны. Не столько в деньгах, сколько в последствиях, например, для проекта, если он не будет выполнен в срок.
Ageykova Автор
Действительно очень сложно, особенно в крупных компаниях, точно оценить проект. Но чаще достаточно бывает верхнеуровнево оценить задачу, чтобы задуматься над её актуальностью. Бывали случаи, когда после оценки вместе с заказчиком принимали решение оставить как есть процесс, а иногда просто резали требования и делали что-то среднее - что упрощает им жизнь и не так трудозатратно