Что появилось первым: курица или яйцо?
Статистики давно уже нашли ответ на этот вопрос.
Причем несколько раз.
И каждый раз ответ был разным.

А если серьезно, то для машинного обучения становятся все более актуальными вопросы причинно-следственного анализа (causal inference) - когда главной целью моделирования является не прогноз и его качество, а то, как мы можем принимать решения на основе нашего алгоритма. И как это повлияет на мир, в котором эта модель будет действовать. Сделает ли модель его лучше, чем он был? Или наоборот.

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

Сегодня в статье попробуем привести в порядок то, зачем мы используем разные инструменты для исследования пользователей. Что такое магический JTBD и зачем он вообще нужен?

Начало начал. Разберемся с терминологией

Как в любой истории у нас есть главный герой, давайте называть его Актор, от слова Акт. В просторечье Пользователь. Методологии так или иначе пытаются проработать что-то вокруг этого самого Пользователя/актора.

Небольшое отступление, чтобы лучше понять суть терминов:

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

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

Хабр, привет! Сегодня рассмотрим кейс, в котором классические статистические критерии не работают, и разберёмся, почему так происходит. Научимся строить свои собственные критерии по историческим данным. Обсудим плюсы и минусы такого подхода.

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

Эта статья — мои мысли на эту тему. В каком порядке и какие материалы впитывать, чтобы потом комфортно себя чувствовать в любой продуктовой компании.

Из челленджей — все материалы должны быть бесплатными, или достаточно дешёвыми, чтобы была возможность бросить учёбу на пол пути (ну не зашло, бывает) и не жалеть о потраченных деньгах на мега-курс от %big_tech_name%.

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

По итогам всех усвоенных материалов, это будет уровень знаний примерно middle+, но фактически, грейды зависят больше от опыта (особенно в программировании), чем от объёма знаний.

И последнее — я тут не пытаюсь продать курсы, поэтому обещать что будет весело, интересно и быстро, а потом вас наймут на 300к/наносек я не буду. Будет долго, местами сложно, иногда душно, пару раз вы захотите слиться и бросить эту идею. Но… нет, тут не будет но 🙂

Ладно, пожалуй хватит предисловия, поехали.

Лид продуктовой аналитики о том, как спасал свою команду от ad-hoc-задач, что получилось, а что нет и как нужно было действовать. История внедрения изменений в команде аналитики.

df.head() — с этого момента вы начинаете работу с данными и полагаетесь на увиденное? Я тоже. Так мы наступаем в феномен what you see is all there is («что вижу, то пою, что не вижу, не спою» — вольный перевод). У ограниченного набора данных, возможно, отсортированного, мы видим ещё более ограниченный набор данных. Мы сами этого не понимаем, но дальше нашу работу строим только на увиденном. 

Как починить себя? Принять как данность, что все подвержены когнитивным искажениям. От них нельзя избавиться полностью. Можно «пойти на компромисс: научиться распознавать ситуации, в которых возможны ошибки. И стараться избегать серьёзных ошибок, если ставки высоки». В этой фразе скрыт рецепт для нас: понимаем, где происходят значимые действия во время работы с данными → пробуем распознать «ситуации, в которых возможны ошибки» → придумываем, как можно избежать этих ошибок. 

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

Автор этой статьи в блоге Stack Overflow — Data QA Engineer, то есть инженер обеспечения качества данных. По его словам, у него есть друзья, занятые в сфере технологий и разработки ПО, которые не совсем понимают, что такое тестирование данных, зачем оно нужно и как оно вписывается в мир программирования.

Это вполне объяснимо: наука о данных — совершенно новая область, и даже те, кто работает с данными каждый день, должны оставаться открытыми ко всем изменениям в работе. О профессии Data QA Engineer рассказываем к старту курса по Data Engineering.

Habr, привет! Меня зовут Женя, и в настоящий момент я лидер направления Self-Service BI в крупном FMCG. Очень хочется начать делиться с вами своими знаниями и наработками, поэтому в рамках первой небольшой статьи решил рассказать вам максимально просто о том, а что же такое Self-Service BI. Поэтому давайте познакомимся с основными подходами к построению Business Intelligence и поймем, почему важен процесс Self-Service.

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

А есть ли альтернатива нейронным сетям в создании систем ИИ? Краткое описание одной из них представлено здесь.

Бизнес в современных условиях развивается стремительно. На динамику продаж, доходов, расходов оказывает влияние множество различных факторов, как внутренних (инвестиции, стимулирование отдельных каналов продаж, исследование рынка и т.п.), так и внешних – различные непредвиденные обстоятельства, вроде, пандемий, стихийных бедствий, исторические событий. 

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

С 2015 по 2021 годы я работала в дирекции по продажам конвергентных продуктов Билайн аналитиком, можно сказать, «на все руки» – аналитиком продаж, продуктовым, финансовым. В мою зону ответственности входили операционная и ежемесячная отчетность, расчет планов продаж на квартал, бюджетирование расходов на продажи, расчеты кейсов по инициативам – для всего этого требовалось моделирование основных KPI развития бизнеса. 

Меня зовут Нина Фещенко, с 2022 года в департаменте аналитики розничного бизнеса (B2C) я в большей степени занимаюсь работой с данными и BI-аналитикой, но без моделирования тоже не обходится. В этом посте я опишу свой опыт построения модели прогнозирования продаж конвергентных продуктов (2019-2021), а также прогнозирования оттока мобильных абонентов в 2022 году. Расскажу, как работала модель в относительно стабильный период до 2020-го года, и какие корректировки пришлось внести впоследствии. 

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

Хабр, привет! 

Меня зовут Полина Окунева, я работаю ведущим аналитиком в компании GlowByte в команде Advanced Analytics, а также автор курса по A/B тестам. Сегодня в статье я предлагаю интересующимся небольшой гайд по A/B-тестам.

Когда я начала погружаться в тему A/B-тестирования пару лет назад, меня кидало из стороны в сторону: то перечитывала фундаментальные учебники по статистике, то переключалась на статьи о конкретных методиках. Но во всем этом многообразии материалов для меня на тот момент был огромный недостаток — я не могла собрать все в кучу и разобраться, а как же проводить-то этот A/B-тест? Я знала, что есть разные виды тестов, множественное тестирование и поправки, полезный и популярный Bootstrap… Но как все это соединить было не очевидно. Хотелось понять, какие этапы есть у A/B-тестирования и когда на что обращать внимание. Хотя бы какие термины гуглить и когда.

Сегодня я представляю вашему вниманию пазл, который сложился в моей голове по итогу плотной работы в этой теме. Я не претендую на истину в последней инстанции — шаги могут и должны(!) быть адаптированы конкретно под вашу задачу. Но если вы только начинаете входить в сферу A/B-тестирования, надеюсь, статья будет очень полезна. Я не буду подробно останавливаться на каждом понятии. Моя цель — обозначить технические этапы и показать новичкам модельную картину A/B-тестирования.

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

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

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

Задача: Необходимо очистить данные о продажах компании за последние несколько лет с помощью библиотеки Pandas.

Хабр, привет! Я Денис Теплов, Директор по продукту в Лиге Ставок.

В нашей компании продуктовая структура представляет из себя 9 продуктовых end-to-end команд общей численностью ~130 человек, работающих над развитием одного продукта. Каждая из команд укомплектована всеми необходимыми компетенциями. Все живут в одном релизном процессе, делают задачи из одного бэклога (и проекта в Jira), и следят за одними метриками в Amplitude.

В условиях такого тесного взаимодействия естественным образом возникает вопрос: А как оценивать их эффективность?

Об этом мы и поговорим.