Личный кейс из телекома: как мы сопоставляли биллинг, 1С, адреса, услуги и партнерскую платформу, чтобы найти, где нарушается синхронизация
Когда говорят про DWH, чаще всего обсуждают управленческую отчетность, BI-дашборды, витрины данных и красивые графики для руководителей.
DWH — единая база, в которой собраны и хранятся все значимые данные компании, аккумулированные из разных источников.
Небольшой мысленный эксперимент на стыке машинного обучения и продуктового менеджмента. О том, почему одна и та же задача «определить, что нужно клиенту» может выглядеть по-разному со стороны product'а и data scientist'а. Разбор на примере корпоративного ДМС, где у одного контракта сразу три стейкхолдера с разными работами.
Все вокруг ноют, что работы нет и что на каждую вакансию космический спрос, а джуны готовы работать за еду. В этой статье поделюсь фактурой — как я нанимал продуктового аналитика в известную международную компанию и какая у меня получилась статистика по кандидатам.
Если посмотреть открытые данные в HH, то можно ужаснуться — на IT вакансии может быть по 1000+ заявок от кандидатов. Чтобы не умереть, разбирая тысячи резюме, по рекомендации HR я добавил в начале достаточно простой опросник — сам заполнял похожий при трудоустройстве. Результат? Всего 85 откликов за всё время публикации вакансии!
Если вы продакт, вы точно хотя бы раз писали релиз-ноты и ловили себя на мысли: а их вообще кто-то читает? В большинстве случаев — нет. Release notes остаются формальностью между сборкой билда и публикацией в сторе.
Но если посмотреть на рынок, можно выделить три совершенно разных подхода к ведению Release Notes. Кто-то пишет для галочки, кто-то — для отчета, а кто-то превращает список багов в шоу. Разберем каждый из них.
Самый распространенный и безопасный путь. Команда не тратит время на копирайтинг. Текст вроде “Исправили баги, улучшили производительность”кочует из версии в версию в сторе.
AB-тест почти всегда живет в плотном контуре принятия решений. Руководителю нужно понимать, не проседают ли ключевые показатели. Команде важно вовремя остановить вариант, который ухудшает метрику, и так же вовремя зафиксировать улучшение, если оно убедительное. Поэтому интерес к проверкам по ходу эксперимента естественен: данные копятся, отчеты обновляются, вопросы возникают каждый день.
Каждый раз, когда в продуктовых чатах заходит речь о проверке гипотез, кто-нибудь обязательно кидает ссылку на калькулятор статзначимости. Мол, «наливаем трафик, ждем p-value < 0.05 и радуемся».
В идеальном мире это работает. В реальности же АБ-тест может стоить компании несколько недель простоя разработки и миллионов недополученной прибыли. Иногда играть в «честный сплит» просто невыгодно.
Длительность. Если вы не Amazon, вам может понадобиться месяц, чтобы добрать выборку. За это время рынок может измениться.
Технический долг.Читать полностью »
В прошлой статье мы разбирали ситуацию, когда есть одна метрика во времени и понятная дата изменения. На практике чаще бывает иначе: изменение затронуло не всех.
Типовые примеры:
релиз раскатан на часть гео,
изменение включено только для определенного сегмента пользователей,
затронуты только отдельные кластеры, каналы, витрины,
контрольной группы в виде AB теста нет, но есть группы, которые не трогали.
У нас есть дата изменения 
. Например, поменяли алгоритм, цены, онбординг, выдачу, лимиты, антифрод, форму оплаты. Есть метрика Читать полностью »
В продуктовой аналитике легко дойти до состояния, когда экспериментов много, а уверенности в решениях мало.
Типовые симптомы:
тест идет «пока не станет понятно»;
MDE забывают зафиксировать (или берут «как обычно»);
p-value проверяют каждый день и закрывают эксперимент на первом же p < 0.05;
ARPU и другие денежные метрики шумят так, что любой вывод спорный;
после релиза эффект не подтверждается, в следствие чего доверие к экспериментам падает.
