О том, что делает продуктовый аналитик мы уже говорили. Давай сделаем шаг назад и посмотрим где эта фантастическая тварь вообще обитает. Как устроен, откуда вырос и как развивается аналитический департамент.
Сразу поясню, что IT — штука довольно гибкая, и у тебя может возникнуть острая боль в нижней части спины, потому что вот конкретно у тебя в компании не так. Это нормально. Но всё же есть относительно общая универсальная схема.
🌸 Ноги это дела всегда растут из маркетинга. В какой-то момент MVP стартапа запускается и появляется потребность обкатать его на реальных юзерах. Маркетологи создают рекламные кампании и зарождают первый аналитический артефакт — разметку. Их цель глобально в повышении стоимости потраченных денег, а локально в оценке эффективности кампаний и источников траффика, поэтому глубокую продуктовую разметку они не делают. Эта история скорее про UTM-метки и ключевые конверсии.
Тут подрубаются коробочные решения типа GA, AppsFlyer, AppAnnie и т.д., всё что умеет считать инсталлы и базовые ивенты.
🌸 Если MVP с треском не провалился, можно озадачиться повышением качества точек входа в продукт — рекламных лендосов и всего околомаркетингового. Это самая простая точка роста на стартовом этапе развития. Но т.к. маркетологам на это тупо не хватает времени, то в команде может появиться первый веб- (или маркетинговый) аналитик, который начинает крутить лендосы, чтобы повысить конверсии в регу.
Он притянет GTM, GA, Firebase, AppMetrica — кароч всякое для веб-аналитики.
🌸 Бизнес потихоньку растёт, бэклог активно наполняется продуктовыми задачами из головы ведущих лиц бизнеса и в целом всё хорошо. Вот тут уже появляется потребность в оценке эффективности самого продукта. Но прежде чем начинать его анализировать, нужно подготовить, так сказать, рабочее место. Идеальный момент чтобы нанять дата-инженера и инвестировать в будущее. Это важный ключевой момент в развитии аналитики. Задача инженера собрать все источники данных, которые уже нагенерили предыдущие ребята, и построить единую платформу для работы с данными.
Сквозная аналитика, warehouse, dataLake — вот это набор слов отсюда. Тут инфра сильно увеличивается на сервера, оркестраторы и всякую инженерную магию.
🌸 Когда инфраструктура более-менее подготовлена, можно расширяться на аналитиков — дата- для отладки качества данных, подхвата адхоков и построения всякой базы типа начальных BI + продуктового, для подготовки почвы под дальнейшую работу по улучшению продукта. Тут мы обычно начинаем с разметки событийки и отладки того, как это всё работает.
Подключаются user-based трекеры типа Segment (или пишутся свои), настраиваются ETL-процессы, ставится какая-то простая SQL-based BI-система вроде Redash или Superset.
🌸 В целом, базовый набор готов, параллельно с этими этапами (где-то ближе к началу) прикручиваем CDO, чтобы питчить идеи в C-level, выбивать бюджеты и содержать весь этот зоопарк.
🌸 С ростом объёмов обрабатываемых данных, бизнес начинает смотреть в сторону более узких специалистов, тут появляется BI-аналитик, который забирает на себя витрины и дашборды, параллельно плюясь, матерясь и переделывая то что уже наворотили.
Redash на этом этапе эволюционирует в какой-нибудь более сложный инструмент вроде QlickSense, Power BI или Tableau.
🌸 Когда бизнес уже основательно разросся, неизбежно появляются задачи предсказаний и персонализации. Так в отделе появляется элита в лице датасайентистов.
Как-то так это устроено. Конечно, это всё схематично, на самом деле каждый чел из списка это скорее мини-команда со своим тимлидом и процессами, но логика мсштабирования примерно такая.