Нулевой километр (Хекслет)

В этом видео Андрей Киров, продуктовый аналитик в ecom.tech (ex Samokat.tech), делится своим опытом работы в сферах аналитики данных и продуктовой аналитики. Мы поговорим о ключевых различиях между разными видами аналитики, а также роли аналитика данных в разработке и улучшении продуктов через эксперименты и анализ данных.

Ещё в этом выпуске обсудим процесс проведения A/B-тестирования, использование SQL и систем BI для обработки и визуализации данных, а также то, какие данные необходимо анализировать для определения статистической значимости результатов и поделимся советами для начинающих аналитиков, включая необходимые навыки работы с данными и инструментами, такими как Jupyter и Google Collab, и рекомендациями по развитию продуктового подхода и софт-скиллов.

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

Полезные ссылки:
– Комьюнити Хекслета: https://t.me/hexletcommunity
– Список тестовых заданий от ИТ-компаний: https://github.com/Hexlet/ru-test-assignments
– С чего начать учиться на аналитика данных: особенности, источники и идеи для первых проектов: https://ru.hexlet.io/link/ayp7yX
– Гид по профессии аналитик данных: кто это, чем занимается и сколько зарабатывает: https://ru.hexlet.io/link/MzvCFH

00:00 Различия между аналитикой данных и продуктовой аналитикой
03:11 Роль продуктового аналитика в разработке и улучшении продукта
07:43 Процесс проведения экспериментов и использование метрик
10:54 Инструменты для получения и обработки данных
18:25 Подготовка данных для каждого исследования
21:47 Определение статистической значимости данных
24:36 Использование дерева-метрики для локализации проблемы
26:05 Прогнозирование метрик и оценка эффекта от изменений
31:38 Разделение ответственности за аналитику в сложных продуктах
33:31 Ответственность продуктового аналитика
34:29 Метрики пользовательского опыта
35:24 Средняя выручка на пользователя
36:23 Влияние внешних факторов
39:05 Основные навыки продуктового аналитика
43:39 Развитие софт-скиллов
44:34 Понимание метрик и способы их сбора
45:57 Создание проекта на GitHub и построение дашбордов
47:23 Освоение инструментов для визуализации данных
49:40 Поиск источников данных и формирование данных
51:58 Изучение инструментов публичных сервисов

Creators & Guests

Host
Александр Усков
IT-энтузиаст
АК
Guest
Андрей Киров
продуктовый аналитик в ecom.tech (ex Samokat.tech)

What is Нулевой километр (Хекслет)?

Хекслет – лучшая школа программирования по версии пользователей Хабра. Наши выпускники уже 10 лет трудоустраиваются в топовые IT-компании. 80% выпускников находят работу в IT. Готовим разработчиков с учетом требований реальных работодателей и уверены в качестве образовательных программ, поэтому гарантируем трудоустройство.

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

Hexlet (00:00.462)
Друзья, всем привет, на связи Хекслет. С вами Александр Русков, у нас в госях Андрей Киров из ZECOMTECH, руководитель пилотировалоналитики ленских положений самоката.

Hexlet (00:19.79)
Привет. Привет. Расскажи, как судьба занесла тебя на эту позицию и что вообще из себя представляет твоя работа? В проекту аналитику я пришел не сразу. Изначально я занимался просто дата -аналитикой. Наверное, надо подробнее будет рассказать, что это такое и чем это вообще отличается, потому что понятия очень близкие и похожие. Ну давай, наверное, к этому чуть позже. Потом у меня было немножко эмэля в моем опыте.

И в итоге мне захотелось не просто заниматься моделями, а получать какой -то понятный эффект, измерять метрики, показатели, как -то ощутимо влиять на бизнес, на продукт, чтобы я мог чувствовать результат своей деятельности, скажем так, благодаря аналитике. И вот я уже три года работаю развиваемом продукте самоката Виком Тех. Ты упомянул, что ты занимался МЛ -ом. Как вообще?

одно с другим связано. Как так получилось, что ты от этого перешел в такую более руководящую позицию, скажем так? На самом деле, аналитика данных — это большая сфера, в которой можно уходить в разные какие -то стези, а AML — это про какие -то модели, про настройку этих моделей. Обычно измеряем качество самой модели, а куда -то ее отдаем, и что с ней дальше происходит, не очень понятно. По крайней мере, так было в моем опыте.

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

Дай попробуем все -таки разобраться в терминах. Вот существуют бизнес -аналитики, аналитики, данные, какие -то системы аналитики, еще и продуктов аналитики. Вот как отличить последних от всех прочих? Что непозвестно в ходе функции продуктов аналитика? Да, тут, наверное, частый вопрос, и многие вообще путают аналитики, аналитики, аналитики. И чем же это все отличается? На самом деле такой термин «дата аналитика» очень широкий, в разных компаниях это все может называться разными вещами, одни и те же роли, и наоборот разные роли одинаково.

Hexlet (02:42.606)
Конкретно Data Analytics — это ролик, в который человек занимается анализом данных, где он ищет, вообще следит за качеством данных, находит какие -то зависимости, может быть какие -то модели предсказательные строит, и там дальше уже можно углубляться в ML. Чем отличается именно продуктовая аналитика? Продуктовый аналитик больше работает с метриками, и конкретнее, наверное, продуктовыми метриками продукта. То есть это такие показатели, которые говорят нам о том, как качественно работает продукт.

В контексте смокада, конечно, продукт имеет в виду не как товар, который мы на полках покупаем или заказываем, а как какая -то некоторая функция бизнеса, то есть какой -то сервис, какое -то приложение, может быть. И Метрики должны отвечать на вопрос, как хорошо этот сервис выполняет свою задачу, как хорошо продукт выполняет свою задачу. То есть полетель приходит, он что -то делает, какое -то целевое действие, и он может там...

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

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

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

Hexlet (04:56.077)
Бизнес -аналитики это вообще другая сфера. Там ребята занимаются бизнес -процессами. Прорабатывают конкретные бизнес -требования, как должен тот или иной функционал выглядеть. есть продуктовая аналитика это для меня вообще другая сфера. Ну ты вот так описывал, как будто это некое просто расширение, ну, анализы данных. Но если я правильно понимаю, твоя работа ежедневно не включает в написание скорость запросов, выдающуюся таблицы и прочего? Или включает? Конечно включает, но...

Это инструменты. Результатом работы... То есть аналитика — не интерфейс к данным. есть задача аналитика не просто посмотреть на данных и сказать, что вот вчера какой -то показатель вырос или упал. Здесь нужно работать с метриками. Выбирать, какие конкретные метрики и показатели могут сказать об изменении более точно, более чувствительно. Быстраивание системы репортинга. То есть...

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

какая метрика наиболее точно показывает эффективность, скажем так, качество работы продукта. И, соответственно, есть верхнюрные метрики, но если она упала, мы не можем понять, что произошло. Стало лучше, стало хуже. Эту метрику можно разбивать на проксиметрики, то есть такие более точечные, но менее общие. И выстраивается такой деревометрик, то есть это целая иерархия, по которой мы можем...

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

Hexlet (07:17.229)
Как я понимаю, Product Manager также на основе данных смотрит на какие -то выгрузки такой, и у меня есть гипотезы. И как ты пытается поставить эксперимент, чтобы проверить, и так далее? Как между вами делится функция, если вы работаете вместе? Ну вот нужен эксперимент. во всех продуктах по -разному. Где -то Product приходит, говорит, нам нужен эксперимент аналитиков, челлендж. Где -то аналитик приходит и настаивает, что мы не можем там...

даже маленькое изменение катить без эксперимента. Но роль самого аналитика включает в себя именно дизайн эксперимента, есть проработка. Эксперимент, какой? На каких пользователях, какие сегменты мы хотим? Какую метрику выбрать? Что такое вообще эксперименты или вот как это называется AB тесты? То у нас есть какая -то допустим, доработка, которая нацелена на изменение функционала. И мы можем, конечно же, просто так ее выкатить.

и посмотреть, там, выросло что -то или упало. Но на эту метрику, любую, там, любую ручку конверсия пользователей средний человек могло повлиять очень много факторов, которые вообще никак не связаны с нашим продуктом. Для этого здесь используют оботестирование, то есть разделяют пользователей на две группы случайным образом и измеряют эту метрику по каждой из групп. Только в одной из групп будет это изменение, а в другой группе будет, как и раньше. И тогда мы можем четко определить, что же на самом деле произошло.

Этот АБ тест можно настраивать по -разному и получить разные результаты, то есть можно получить изменения там, где их нету или наоборот. тут очень большая вообще этим стоит математика, и очень все надо аккуратно подбирать критерии, длительность эксперимента, саму метрику, как мы будем проводить. Здесь, конечно, это все работа аналитика.

Это что касаемое экспериментов. Какие -то, наверное, сами продуктовые изменения обычно приходят от Product Manager. Вот. Но, опять же, аналитик может посмотреть на данных, увидеть какое -то узкое место и прийти к этим и сказать, ну вот у нас там упала конверсия или она вообще там низкая, ниже, чем принято, например, или что -то очень подозрительное. Давайте -ка посмотрим, покопаемся.

Hexlet (09:30.797)
И уже на данных можно найти какие -то узкие места или гипотезы для проверки, для создания новых фичей или исправления какого -то бага, А может ли Product Manager сам такие решения принимать? Или тут важно именно, чтобы он был представлен к ответственному Product Manager? Ну, я думаю, в каждом продукте все как бы по -разному происходит. Решение наверняка принимается чаще всего именно Product.

Аналитик, конечно, делает рекомендации последние слова, наверное, за продуктом. Рекомендация плюс аргументация. Вот такой результат работы одного аналитика. Понятно. А можешь приступить к каких -то инструментах, которыми ты работаешь, опять же, чтобы дать им множество контекста? есть чем ты пользуешься на ежедневном, там основы у тебя не регулярны? Никак нельзя обойтись без SQL, то есть работа с базами данных.

Это прям регулярная вещь. Анализируются иногда и визуализируются данные в Python, но на регулярной основе используем системы BI, то дашборды, в которые мы визуализируем какие -то показатели. Например, там новый проект выкатился, хочется посмотреть, как он перформит. Мы выкатываем дашборд по этому проекту. Есть у нас такие большие дашборды по каждому продукту, где там самые основные метрики уже построены, которые мы регулярно на основе смотрим.

чтобы понять, все ли у нас хорошо, что изменилось, если изменилось, уже там выясняем почему. Ну, сама система B -тестов, нас внутренний есть продукт сплетовалка. Наверное, самые основные инструменты, которые хочется выделить. По сути, это инструменты для получения данных и для обработки их, ну и для какой -то визуализации результатов. Так что SQL, Python...

системы BI. Если тебе нужно провести какое -то разовое исследование, то есть не построить dashboard с систематической отчетностью, а разово выяснить, что происходило с каким -то сегментом данных в такой период времени, это все делается руками при помощи SQL запросов, Python или есть какие -то другие инструменты для этого? ты вообще делегируешь другим сотрудникам? Обычно это делается SQL или Python в зависимости от запроса, от базы.

Hexlet (11:52.685)
того объема данных, который необходим. Чаще всего это делают сами аналитики, дашборды. Они покрывают, конечно, основные какие -то показатели, но исследования проводить очень тяжело по ним, конечно, поэтому приходится подготавливать данные для каждого исследования отдельно. Это делаем мы сами. Справедливле будет сказать, что это какие -то такие наколеночные скрипты или есть какие -то более восковырневые инструменты уже, которые позволяют этим управлять?

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

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

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

Вот этому вообще как -то можно научиться или это просто нужно увлекаться темой или попасть в свою или как это устроено? Во -первых, это, наверное, из таких отличий прямо от продуктовой аналитики, от такого среднего дата аналитики. То есть именно погружение в свою доменную область, понимание как этот продукт работает. Конечно же, опыт в этой сфере очень важен.

Hexlet (14:11.757)
сложно разбираться в продукте, когда ты ними не взаимодействовал. Поэтому здесь очень важна насмотренность. У похожих продуктов могут быть разные, скажем так, метрики или разные вообще истории. То есть одно и то же функцию вводишь в похожие, казалось бы, продукты и получаешь разный результат. Такое тоже случается, потому что у продуктов могут быть просто разные аудитории, разные сегменты, которые ведут себя по -разному. Поэтому насмотренность важна.

Чем дольше ты работаешь с конкретным продуктом, тем больше уже каких -то пониманий интуитивных, что и почему может происходить, уже какие -то понятные, куда копать, что могло произойти, что вряд ли могло произойти. Если можно, давай может, какие -нибудь примеры разберем. Мы посоветовали, что речь идет про клиентский сервис и самокат, то есть это доставка продуктов. Это же не просто, ну не чисто цифровая какая -то история, не просто какой -то...

приложение, которое работает, да, и что -то делает. Как на всем этом вообще построить какую -то аналитику? Какие метрики можно здесь выделить и почему это важно? Да, на самом деле, если говорить про аналитику просто какого -то IT -шного продукта, то там все, плюс -минус просто, померил метрики и все окей. Здесь же мы отвечаем, то есть вот когда работая в аналитике именно клиентского приложения,

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

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

Hexlet (16:33.645)
или не возвращаются. есть мы могли доставить пользователю, там, доставлять пользователю заказы всегда быстро, а потом случилась плохая погода, доставить позже, и это могло испортить ему опыт. В продолжении, ну, мы вроде ничего не делали, мы погоду не портили, но там метрика может стать сильно хуже. И такие вещи тоже важно учитывать. Вот, например, у нас есть различные проекты...

которые тесно связаны не только с крыльянским приложением, а взаимодействия с операционкой, с курьерами, партнерами или с нашими DarkStore -ами. Например, элементарное в приложении кнопочка «Оставить у двери» — это когда мы в корзине добавляем кнопку «Оставить у двери», и заказ не будет курьер, например, дождаться, пока мы выйдем, а он просто оставит его у двери, сфиксирует и все. Казалось бы, простая функция, и для чего она вообще нужна.

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

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

такой очень хороший интересный У меня вопрос в с этим. Чтобы построить аналитику на этой истории, нужно достаточно много провести работы, чтобы эти данные в целом куда -то попадали. То, что какое -то изменение в статус заказа, тем более обращение в поддержку, это отдельное по сути флоунефт. Не на 100 % аналитизированное, наверно, как у всех. Нужно все это как -то собирать. Аналитики продуктовые имеют какое -то отношение к проектированию системы сбора данных?

Hexlet (18:53.549)
Или приходится работать с тем, чем есть, и из этого как -то выкручиваться? Конечно, аналитики участвуют в этом, потому что перед запуском проекта, который ты хочешь анализировать, важно удостовериться, что тебя будут данные, по которым ты собираешься это анализировать. Например, когда мы что -то добавляем, например, в приложении, аналитики делают постановки на разметку событий. есть, пользователь делает определенное действие в приложении, и после этого должно создаться...

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

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

А если, например, это не какой -то новый функционал, а, допустим, ты пришел на работу в некоторых объективах, там уже есть какие -то данные, какой -то продукт, и ты понимаешь, что где -то чего -то не хватает. То есть хотелось бы -то отдельное взаимодействие как -то разместить или отследить. Есть мнение, что данных вообще никогда не бывает много. Как понять вообще, к чему это стоит применять? То есть это, опять же, является ли необходимым навыком для продуктового аналитика или ответственность кого -то еще? Как понять, что вот здесь нам нужно еще что -то померить?

Для меня это вся такая вещь, да, немножечко какая -то неловимая как -будто интуиция. Может быть, есть какие -то подходы к этому? Ну, каких -то устояшшихся подходов нет. Конечно, часто история, когда ты приходишь с продуктами, каких -то данных не хватает, которые необходимы. Здесь уже стоит, конечно же, уже навык аналитика понять, какие данные нужны в первую очередь. Без них вообще никак. И мы не можем там, мы вслепую, в общем -то, идем без них. А без каких -то данных можно вполне обойтись. И понятно, что...

Hexlet (21:17.741)
Данные не берутся из воздуха, и на это нужно тоже иногда время и ресурс разработки в том числе, чтобы те же события разметить. Вот, поэтому тут ответственность аналитика не просить вообще все разметить, там, вообще каждый -каждый -каждый -каждый параметр, а оставить именно вот это оптимальное набор событий, параметров или данных каких -то. Вопрос, может быть, немножко больше про аналитику данных в целом, но тем не менее, есть наверняка общая проблема, как понять, что то, что ты увидел в данных вообще то, что тебе...

ты бы пришел к этому выводу на основе этих данных, что это не мираж, что это действительно статистически значимое какое -то явление, что есть смысл об этом думать, что это не охотишься на ведьм и тому подобное. Бывает ли, может, тебя есть кейс, такая бывала и обратная? Потому мне кажется, наверняка нелеткая история. Ну, на самом деле вот подход об тестировании, он помогает почти наверняка с понятной долей ошибки, допущения, сказать, что изменение действительно...

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

чтобы исключить эту какую -то субъективность. Но, конечно же, всегда можно что -то не учесть, и это, наверное, приходит с какой -то опытом, это вся насмотренность. Мне просто хочется сразу вспомнить, мне кажется, в каждом практически крупном проекте был такой сценарий, в один светлый день прибегает CPO с шареными глазами и кричит, у нас конверсия падает. То есть, когда ты навестишь изменения...

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

Hexlet (23:42.445)
покупку продукта релизы не ежедневно по отдельным сегментам функционала. Как вообще такие ситуации разруливаются и что мы можем советовать о выдержке? Я бы даже сказал, что самое страшное, когда ничего не релизили, а что -то сломалось. Потому что когда есть релиз и что -то пошло не так, наверное можно это более судить.

Ты знаешь, когда нет релиза, это CPU не на что свалить. есть, он как бы, ну, у него нет первичной мысли, что это виноваты разработчики. А когда был релиз, а с этим каждый день, то очевидно, что первым делом проверить релиз. Вот. И как там что -то делать? Отказывать версии, тестировать, что еще? Как вообще можно это решить? Если мы говорим про случай падения конверсии, как я говорил ранее, одним из инструментов у нас это дерево -метрика, то есть это какая -то модель показателей, от начинает какого -то North Star -метрики от верхнего уровня, и который раскладывается на...

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

То есть если нас там упала конверсия в заказ из главной страницы, но не упали остальные конверсии, значит наверняка там дело в том, что пользователи перестали добавлять в корзину. И мы смотрим, ага, почему они могли перестать добавлять? И там вот в принципе можно пытаться вот так приближаться до тех пор, мы не поймаем какую -то причину, которая чаще всего вот таким образом и находится. Здесь секрет стоит за тем, что смотреть, спускаться все ниже и ниже вот это по дереву и...

пытаться поймать, что на самом деле не изменилось, а что упало вслед за конверсией. Ну то есть эта работа, скажем так, все еще аналитическая. Какого -то надежного инструментария, который позволит сказать, где изменилась метрика, потому что изменилась программа, где потому что изменилось обстоятельство. Я так понимаю, что все еще нет. Да, потому что опять же могло ничего не произойти, и ну нет какого -то инструмента, который скажет упало, потому что, не знаю, праздники завтра.

Hexlet (26:05.165)
Говоря об этом, продукталиналитики вообще занимаются прогнозированием каких -либо метрик? Выткать, бы, натянуть прогноз какой -то задачи на существующую реальность? Да, конечно, приходится делать с прогнозом. Например, есть такой подход, когда мы тем или иным причинам не проводили АБ -тест, мы можем сравнивать не с контрольной группой, а с прогнозом метрики, который вот на исторический дань смотрим, смотрим метрику, делаем прогноз и на

в какой -то группе делаем изменения и сравниваем прогноз с фактическим показателем. И это такой способ квази -эксперимента. В любом случае, все прогнозы — это какая -то экстраполяция, То есть, взяли что -то историческое и как -то помножили? Да, практически все прогнозы строятся, конечно, на исторических данных и на каких -то особенностях, на каких -то фичах, да. Я к чему -то просто задаю. Часто бывает такое, что когда есть несколько разных команд, которые занимаются разными...

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

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

имела повышение метрики на n процентах. такие, ну, значит, давайте представим, что мы катим, у нас такой же прирост. Что будет тогда? Какой денежный эффект мы этого получим? Какой эффект в метриках мы получим? Всегда есть некоторые допущения, но мы можем по некоторым методологиям оценивать, как именно будет растить метрика, какая метрика будет расти и как нам выбрать. Вот нас есть, не знаю, 50 задач.

Hexlet (28:29.997)
Мы готовы браться за любую, но надо понять за какую. И есть подходы, где мы оцениваем как раз, насколько пользователей будет это аффектить, какой ожидаемый прирост метрики, насколько мы вообще верим в этот, в то, что эта доработка реально сработает. И вот после этого, когда мы прирост какой -то метрики, даже допустимые, мы можем перевести это все в деньги, потому что, там, не знаю, увеличение конверсии, легко переводится в деньги, потому что у нас уже там есть

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

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

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

Путь правильный будет развить для любой, плюс -минус, технологической компании. Но на практике моего опыта работы я такого практически нигде не видел. есть это все красивые теории, но ее очень сложно реализовать. Как вообще обстоит с этим дело российском рынке, например? И насколько эта история реальна или все же это некоторая утопия? Нет, ну на самом деле просто это не от такого, что сидит один человек и высчитывает вот весь этот большой процесс. Тут все разбивается по частям.

Hexlet (30:44.429)
Например, этапа привлечения до этапа появления пользователей в приложении вообще там может заниматься отдельная команда. Обычно этим занимаются маркетинговые аналитики. есть вот само привлечение, как качественно пользователь приходит к нам из разных каналов. А когда пользователь пришел, опять же, продукт в широком смысле самокат на самом деле разделяется на какие -то разные, скажем так, контексты приложения или экраны.

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

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

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

Количество этапов, которые он убьется, назначено большой, поэтому и отдельная команда соответственно, водится под каждое это звено. Каждый как бы занимается своим участком от входа какого -то до какого -то выхода. Практически как некоторая функциональная единица в программировании самом. Если из этого всего конвейера выделить инопродуктовую аналитику, что на входе, что на выходе? То есть, где начинается и заканчивается зона ответственности инопродуктовой аналитики? Опять же, я могу говорить, как мы работаем сейчас, где ответственность инопродуктовой аналитики. есть, продуктовый аналитик...

Hexlet (33:04.813)
он есть в каждом этом блоке, например, если отдельная команда занимается авторизацией, то там будет отдельный продуктовый аналитик. Ну и в широком смысле, на самом деле нет такого, что над каждой функциональностью свой продуктовый аналитик, но вот в таких блоках, как отдельный каталог или навигация, в этом, скажем так, этом сегменте отдельная команда, отдельный продуктовый аналитик, и его ответственность начинается вот когда...

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

не все равно, что будет с ним дальше, но обычно продуктоналитика занимается более точечными вещами. Это, наверное, таких больших компаниях. Это какой -то фрагмент политического пути, Здесь некоторые юниты, которые отвечают за какой -то политическую пути, и в каждом из них свой продуктоналитик отвечает за соответствующие этому пути, метрики. То есть, наверное, если говорить там про какую -то супер, не знаю, верхнеуреннему метрику, типа, не знаю, ever -enshaving, hyperuser, довольно типичная.

средняя выручка на пользователя. За нее отвечает какой -то один продуктал -аналитик во всем продукте или у каждого она там где -то как -то преобразуется в свой какой -то вариант? На эту метрику влияет очень много факторов. Прям вот вообще все, все что можно придумать влияет на эту метрику. То средняя выручка на пользователя там, не знаю, влияют цены, влияет погода, влияет изменение в приложении. Поэтому за такую высокую метрику, наверное, ответственно там либо какой -то там...

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

Hexlet (35:24.269)
Вот, и эту метрику тоже на самом деле можно разбивать, то есть на средний чек может влиять, вот если мы говорим про тот же каталог, то на средний чек, чем качественнее каталог, тем выгоднее какие -то предложения, тем больше чек наберет пользователь скорее всего, ожидается. Вот, поэтому в этом синтетическом примере влияние протоколоналитика или в целом ответственности, как бы на определенную метрику

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

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

Тут все очень сложно. Сложно, но, похоже, интересно. Что вообще нужно изучать, как к этому профессии подойти? Что бы ты посоветовал людям, которые хотят для себя эту профессию рассмотреть? Чему и как учиться? Тут, смотря какой уровень, в первую очередь, если вообще с нуля подходить, то нужно научиться каким -то базовым навыкам получения данных, то есть SQL, какая -то...

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

Hexlet (37:42.477)
приходится, придется так или иначе этот топ где -то получить. Можно, не знаю, найти какой -нибудь датасет или там попросить с нейросети генерить или там в открытых источниках на каком -нибудь кегле найти датасет и можно его самому покрутить, нагенерить каких -то гипотез и даже там, не знаю, если там есть временные отрезки, даже можно свой ABTest попробовать провести ну, такой искусственный. Вот, поэтому...

стоит сфокусироваться, наверное, на инструментах. А когда с инструментов все хорошо, погружаться в эту область, на продуктовой аналитики. Харды здесь, не знаю, какие -то методы, есть обетестирование. Сам этот сегмент достаточно большой. Стоит начать с изучения критериев. Подожди, пожалуйста. Давай еще разобьем это на части. Я просто, я в твоих речах слышал, как бы,

бывшего мэльчика. ты совершенно как будто бы оставил за скобками, а я хочу понять, а нужно ли вообще знать такую страшную вещь, как Матстатшу этим заниматься. То скажем, я как разработчик могу написать расколи запроса и на Питоне там какие -то CSW 'шки переложить. что как бы меня, это не сделают же меня аналитиками, тем более про аналитика, да? Нужен какой -то вот, какой нужен фундамент именно теоретически? Да, нужны базовые знания Матстата, это сто процентов, потому что...

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

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

Hexlet (40:01.805)
Если мы освоили базовый аппарат Модстата, мы учились вызывать функции в NumPy, в пандесе, какие -то запросы, что дальше? зависимости от того, какую глубину человек хочет развиваться? Есть ли какая -то специфика именно у продуктовой аналитики по сравнению с маркетинговой и датаналитикой? Очевидно, что развитие из датаналитиков в маркетинге или в продуктовую, здесь надо...

как бы начать уже наверное работать и решать реальные задачи вот скорее всего мне кажется чаще всего путь должен начинать создать аналитики и в целом каким -то образом поступаться к данным а затем уже определяться что интереснее всего какой тип задач наиболее как бы интересно им заниматься с этой точки зрения будут ли отличаться hard skills или дальше уже вопрос на знание приметную область база не будет отличаться на мой взгляд здесь то есть

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

Тяжело сказать, что если ты маркетинговый аналитик, тебе нужно то -то и то -то, потому что в разных компаниях они могут и об BTS -тим заниматься, и делать какие -то просто выгрузки на SQL. Вот, поэтому если хочется получить навыки для входа, нужно получить вот эту базу, то есть SQL, Python, знания там MatStats, и уже там трогать инструменты там для визуализации, и погружаться вот в ту математику, которая наиболее интересна, то есть это об отестировании.

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

Hexlet (42:27.149)
направления на основе данных. Какие с этим ты бы посоветовал приобретать софт -скилы? Что ты считаешь важно, что отличает игроков в аналитике с точки зрения каких -то навыков, не являющихся?

Софт -скилы на самом деле очень сильно важны. Мы сейчас обсуждали, что для харды, наверное, на входе нужны всем плюс -минус одинаковые. Дальше очень важно расти по софтам. Здесь о чем именно речь? Для продуктового аналитика важно отстаивать какой -то продуктовый подход и делать именно аналитику не для аналитики, а...

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

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

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

Hexlet (44:34.221)
в основном, то есть уверенные хорды и дальше все это придется опытам. Кажется, кажется, что достаточно, чтобы вот для начинающего уровня понимание, какие метрики в принципе существуют, как они друг на друга влияют, как их можно собрать, умение их собирать. Вот. Все остальное, мне кажется, уже развивается на более высоких краядах. Как бы ты бы советовал вот этому обучаться? То есть как новичку, пусть только он прочитал какие -то базовые вещи по...

статистики SQL, а вообще что ему дальше делать? Если он хочет найти работу или если он хочет просто прокачаться? есть мы говорим про того, кто учился SQL и еще не работает, правильно? Ну, допустим, про человека, который хочет быть именно аналитиком, желательно продуктовым, но при этом он по факту сейчас такой джунер -разработчик. Конечно же сейчас большая проблема, что без опыта тяжело попасть в сферу, поэтому

Нужно получить эти навыки, но получать эти навыки нужно где -то оставить артефакт в том, что ты действительно это умеешь. Поэтому мой совет будет такой, что свести себе какой -нибудь GitHub, куда можно складывать свои iPad и ноутбуки, и сделать какой -нибудь проект, который будет как и обучать, то есть можно взять тот же датасет и построить из него дашборд.

который будет показательный, который можно постепенно тюнить, делать, добавлять какие -то новые вещи, выделять, расставлять нужные акценты, и этот файл dashboard 'а можно прикрепить к своему резюме. Потом можно самому сделать какую -то систему на коленке обы тестирование, то есть научиться, как вообще это работает на самом деле, как разделять пользователей на две группы, какие критерии применять, как эти критерии работают, все это реализовывать. Если...

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

Hexlet (46:55.245)
от всех остальных, потому что уже видно, что работал, знаешь, как это работает, какие -то скрипты уже есть, то есть это бы два в одном получается, и обучение, и какое -то портфолио. Ты упомянул такой момент, который мы как -то не вскрыли, когда обсуждали инструменты. Аналитики данных часто пользуются такими штуками, как записные книжки, эти ноутбуки. Есть Jupyter, да, популярный довольно инструмент. Есть еще меня известный Google Collab.

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

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

PYNB, IPyTN Notebook, точнее, InterActive Python Notebook, то есть это просто такой удобный способ визуализации, хранения передачи, все действительно очень удобно. Collab это что -то, аналог на самом деле. Правильно я понимаю, что это важный инструмент, и стоит его тоже освоить. есть если ты просто Python разработчик, он будет типа баловаться хитрадками, чтобы было дальше жить с этим тем.

Думаю, да, потому что это очень популярный инструмент и им удобно пользоваться. Мне кажется, большинство пользоваться им не на нем. Они запускают там в консоли Python, потому что... Ну, в том числе используется Python для визуализации данных, и там все очень удобно и трактивно, поэтому этим и пользуются, поэтому это очень важный инструмент. Я почему принес вовремя? Потому что я сам, как бы, приискиваюсь пользуясь для схожей задачи. И, конечно, это суперудобно, когда тебе не нужна следа, не нужно ставить пачку...

Hexlet (49:11.757)
не нужно там что -нибудь собирать, обвязывать, нокера мне просто взял, написал, запустил, получил графики, таблички и радуешься. На самом деле, естественно, просто для разработчиков, для плохого инструмента, чтобы -то вещи там попроцепировать. Что -то типа репла на максималку. Скажи, по поводу вот этих, ну скажем, первой работы. То есть человек прошел обучение, -то навыки базовые схватил, что -то там поделал, сделал все эти тратки, вложил их на GitHub. И на первую работу, ну, вероятней всего, он не устроится в какой -то супер крупный...

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

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

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

синтетический случай.

Hexlet (51:30.381)
Куда кобить тревогу? Надо искать документации, слишком много данных. Слишком много данных, Если у нас есть конкретные задачи, то есть мы понимаем, что именно мы хотим, надо пытаться найти тот самый источник, который нам нужен, и использовать его. То есть наверняка есть документация, если есть много данных. Если ее нет, то это очень плохо, и стоит разобраться в данных.

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

Ну, мне кажется, типичная история для любой программы системы, о которой кто -то писал. Далеко не везде, не всегда она есть. Если нет, конечно, что сразу сделать. А что касается сбора данных? я, как молодой аналитик, прихожу в компанию, понимая, ух, сейчас я бы тут развернулся, каких -то данных нет. Как аналитик может ли вообще инициировать задачу? Сказать, блин, ребят, мне нужны такие -то данные. Или как этот процесс обычно решается, как бы он выглядел в идеальной компании?

Да, это вообще нормальная история, когда не хватает каких -то данных, которые мы можем собирать. Во всех компаниях свои процессы, но обычно ставятся задачи на датокоманду, либо ставится конкретная, что вот нас есть такая вроде таблица, нам нужна ее копия, либо непосредственно набор полей и дипформатов. Это вообще нормальная практика. То есть, оставим постановку и там ищем...

те, кто этим занимаются и обычные отдельные команды помогают как раз формировать данные. Такой еще вопрос, может быть, тоже в тему инструментов. Не все компании, наверное, обладают потенциалом инстраструктуры, чтобы сделать себе свои даже борды, собрать логи, построить DWH и прочее. Есть же, компании, которые живут на каких -то публичных сервисах, будь то там Яндекс .Метрика, Апметрика, много таких разных придуманных. Стоит ли изучать эти инструменты, если да, то какие в первую очередь? Мне кажется, что изучение таких инструментов, оно...

Hexlet (53:55.405)
не занимает много времени. есть отдельно специально изучать все инструменты на свете, наверное, не самая лучшая идея, потому что важно понимать, что именно нужно сделать, а к инструменту можно быстро освоиться. Наверное, слишком много инструментов, которые могут потенциально попасть в компании. Я не вижу смысла специально...

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