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

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

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

Проверка идеи

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

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

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

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

Если данные показывают, что 95% пользователей всё-таки покупают товар, а среднее время между добавлением в корзину и покупкой — меньше минуты, значит, никакой проблемы нет — и можно не тратить ресурсы на дополнительные стимулы.

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

A/B-тесты

Допустим, мы подтвердили проблему: действительно, пользователи часто отваливаются после добавления товара в корзину. Заказчик рад, проблема выявлена, и он предлагает решение: «Просто сделаем баннер “Купи в ближайшие 5 минут и получишь скидку 5%”. Или лучше 10%, чтобы точно купили». Здесь мы переходим к постоянной задаче аналитика — он должен стать «отрезвляющим человеком», который напоминает, что не всё так просто. 

Иногда приходится говорить: «Стоп, подождите. Чтобы понять, как это повлияет на результат, нужно запустить A/B-тест». Это супертиповая задача, которая состоит из нескольких этапов.

1. Дизайн A/B-теста. В первую очередь нужно создать грамотный дизайн эксперимента, чтобы его результаты были корректными и достоверными. Итак, вы решаете проверить, поможет ли баннер с предложением скидки завершить покупку. Для этого делим аудиторию на две группы: одной группе вы показываете баннер со скидкой, а другой — нет. Один и тот же пользователь не должен в разные моменты находиться в обеих группах: если в первый раз человек увидит скидку, а потом вернётся на сайт и не увидит — это может повлиять на его поведение, приведёт к путанице и вызовет негатив. 

2. Наблюдение за A/B-тестом. Вы расписали дизайн теста, заказчик дал зелёный свет, начинается тестирование. Теперь важно следить за тем, чтобы всё шло правильно. Во-первых, необходимо удостовериться, что тест запущен. Это может показаться очевидным, но иногда тест действительно забывают запустить или запускают некорректно. Поэтому первое — проверяем корректность запуска A/B-теста.

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

3. Анализ результатов. Когда прошло достаточно времени для сбора данных, наступает самая интересная часть — анализ результатов. Аналитик должен дать рекомендации, помочь бизнесу принять решение: оставляем изменения и выкатываем их на всех пользователей, откатываем назад или проводим дополнительный эксперимент. 

Принять это решение не всегда просто. Если баннер со скидкой не дал ожидаемых результатов и уменьшил выгоду компании, это не значит, что нужно убрать его совсем. В такой ситуации аналитик может предложить другой подход, например: «Закажи, пока товар не закончился». И снова запустить A/B-тест.

Создание дашбордов

Предположим, что наш баннер со скидкой всё-таки показал хорошие результаты: люди чаще завершали покупки, и это компенсировало нам 10% скидки. Мы решили выкатить такой баннер. Что происходит дальше? После теста и анализа результатов мы можем выявить точки роста и определить метрики, за которыми стоит следить в разных разрезах. 

Возможно, мы обнаружили, что разные группы пользователей ведут себя по-разному: например, люди от 18 до 30 лет охотно откликаются на предложение, а люди постарше — чаще игнорируют его. Это может навести на мысль, что пора делать персонализированные предложения для каждой аудитории. Или сейчас все привыкли к скидкам с ограниченным сроком (тайм-прессингу), но со временем эта модель может начать раздражать пользователей и перестанет работать — придётся придумывать новые стимулы. 

И вот здесь появляется третья задача — создание дашбордов. Иногда это инициатива самого аналитика, иногда — заказчика. Если заказчик постоянно просит одни и те же данные, конечно, можно каждый раз делать ad-hoc запросы через SQL. Но в какой-то момент это просто начинает надоедать, и ты думаешь: «Господи, давайте я уже сделаю дашборд, чтобы вы могли сами смотреть все эти метрики». Или заказчик может прямо попросить: «Хочу видеть определённые показатели каждый день».

Аналитик вместе с заказчиком определяет цели дашборда и выбирает метрики, а затем собирает дашборд с помощью инструментов, которыми пользуются в компании. Обычно это BI-инструменты: Database, Tableau, Power BI. 

А дальше круг замыкается. Вот у нас есть дашборд, заказчик в нём ковыряется и вдруг замечает, что конверсия на iOS и Android отличается. Он удивляется и говорит: «Блин, как странно», и ставит задачу аналитику: «Исследуй воронку отдельно для iOS и Android, сравни их». Аналитик разбирается, находит проблему, снова запускает A/B-тест и делает анализ. 

Ad-hoc задачи

Иногда возникают менее типовые, но всё же важные задачи. Например, что-то сломалось на сайте: пользователи добавили товары в корзину, а они внезапно пропали. Мы замечаем это по дашборду — видим, что количество покупок резко упало. 

Заказчик прибегает с вопросом: «Почему конверсия снизилась?» Аналитик начинает разбираться, смотрит логи и видит, что корзины обнулились. В итоге он предлагает решение: «Давайте выгрузим список пользователей, которые столкнулись с этой ошибкой, снова наполним их корзины товарами и отправим им письма со скидкой, чтобы они вернулись и завершили покупку». Проблему можно решить разными способами, но чаще всего это задача для аналитика — его просят выгрузить данные. 

Когда нужно делать ad-hoc запросы или выгрузки, чаще всего хватает SQL— поэтому я всегда говорю, что это важный навык. Если задача посложнее, можно подключить ещё и Python для обработки данных.

Новичку придётся столкнуться с большинством задач из этой статьи. Разница лишь в том, что поначалу уровень ответственности и сложности будет ниже. Например, начинающему специалисту могут доверить тестирование цвета кнопки: аналитик проведёт A/B-тест и сделает выводы — это типовая задача, которая не требует обширного опыта в анализе данных. 

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

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