This is Data

Друзья, это финальный пост про пирамиду метрик. Я довольно много писал про метрики и разные фреймворки, и к пирамиде мы возвращались не раз. Но с последним слоем я немного подзатянул - исправляюсь 🙂 На последнем уровне - интерфейс продукта и маркетинг - находятся самые прикладные метрики. Те, с которыми команды работают каждый день и которые напрямую отражают поведение пользователей. Этот слой отвечает на базовые вопросы: - как пользователи приходят в продукт? - что они в нем делают? - доходят ли до целевого действия? Как и в предыдущих слоях, здесь есть своя логика группировки. Я выделяю четыре блока: 1. Маркетинг Это про вход в продукт: кого мы приводим и за какие деньги. 2. Интерфейс Это уже про UX и то, насколько продукт понятен. 3. Вовлеченность Здесь видно, «цепляет» продукт или нет. 4. Аудитория Это наша текущая и потенциальная база. Этот слой - точка, где формируется все поведение пользователя: как он зашел, что сделал, получил ли пользу. А дальше поднимается выше по пирамиде - в ценность, лояльность и деньги. На этом мы полностью разобрали пирамиду метрик - от бизнес-уровня до конкретных действий пользователя. Главное не фреймворк, а используете ли вы его на практике. Будь то пирамида, дерево метрик или что-то свое - важно, чтобы метрики были системой, а не набором цифр. #харды #метрики #разбор_метрик

Эффективные встречи один на один - существуют ли они? Я терпеть не могу встречи ради встреч. Обычно это просто сжигание времени. Но есть один формат, в который я по-настоящему верю 🙏 Встречи один на один - не просто регулярный разговор сотрудника с начальником, а один из главных инструментов управления. К сожалению, многие относятся к ним как к простой формальности и проводят их «для галочки». Для меня 1-1 - это способ синхронизироваться, вовремя заметить проблемы, поддержать и задать направление движения. Именно поэтому к таким встречам нужно готовиться. Не обязательно писать большой план, но важно хотя бы заранее понимать, что хочешь обсудить. Формат может быть таким: 1. Начинаем с короткого неформального разговора. 2. Даем слово сотруднику: какие есть вопросы, сложности, идеи, что беспокоит, где нужна помощь (и действительно стараемся помочь). 3. Переходим к своей части: рассказываем новости, делимся мыслями, советуем, если это уместно, обсуждаем планы и изменения. 4. Самый важный блок - фокус недели. Фиксируем 1-2 главных приоритета на ближайшие дни. На следующей встрече разбираем: что вышло, что нет и почему. ⚠️ Сами фокусы не должны браться из воздуха. Они должны рождаться из стратегии развития. Если у руководителя нет понимания, куда движется функция, то 1-1 быстро скатывается в обсуждение только текучки. А когда есть стратегия, такие встречи становятся способом регулярно переводить ее в конкретные шаги для команды. Кстати, я уже готовлю статью про свой опыт создания и внедрения стратегии аналитики в компании. ⚠️ Еще одна практика, которую считаю очень полезной - это фиксировать письменно темы встреч и договоренности в любом удобном инструменте. Всегда можно вернуться и вспомнить, что обсуждали. Потому что если договоренности не зафиксированы, то их не существует. Как часто проводить 1-1? Все зависит от вашей команды и контекста, но мне нравятся недельные каденции. Они позволяют не терять фокус и темп: за 5 рабочих дней обычно накапливается достаточно прогресса для обсуждения. Для зрелой команды хватит и двухнедельного интервала, но реже есть риск упустить проблемы. Такой подход делает встречи не формальностью, а рабочим инструментом. Помогает держать курс, поддерживать людей и не тонуть в текучке. А вы верите в эффективный 1-1? 👍 - да 🔥 - нет, сжигание времени #опыт

Как аналитику оптимизировать свои запросы? Ранее я рассказывал, почему оконные функции могут тормозить, и дал 4 совета по оптимизации. Но если ты действительно хочешь ускорить свои запросы, то начинать нужно с анализа плана выполнения. Знакомьтесь - EXPLAIN Команда простая и очевидная, но почему-то ею мало кто пользуется. Может, потому что хочется быстрее решить задачу, а не копаться в том, как база данных обрабатывает запросы. Но когда ты пишешь боевой запрос, от которого зависит работа важной системы, или когда на кластере жесткие лимиты по ресурсам - умение читать EXPLAIN твое все! Как SQL работает под капотом? Прежде чем говорить о плане, важно понимать этапы, которые проходит SQL-запрос внутри базы данных (на примере PostgreSQL): 1⃣ Parser - разбирает текст SQL, проверяет синтаксис и строит абстрактное синтаксическое дерево. 2⃣ Analyzer - проверяет существуют ли таблицы, колонки, функции, есть ли права доступа. Если ты опечатался в названии колонки, то ошибка упадет именно здесь. 3⃣ Rewriter - делает логическое преобразование запроса. 4⃣ Planner / Optimizer - самый важный этап для нас. Он перебирает возможные планы выполнения и выбирает тот, у которого наименьшая стоимость. 5⃣ Executor - выполняет план и возвращает результат. EXPLAIN показывает результат работы planner и это тот самый план, который база данных посчитает оптимальным на основе статистики. Как читать EXPLAIN? План выполнения - это дерево. Самый глубоко вложенный оператор выполняется первым. Всегда читай план снизу вверх - так ты увидишь реальную последовательность действий. Команда EXPLAIN показывает, как именно база данных собирается выполнять запрос: какие индексы использовать, как соединять таблицы, будет ли сортировка. А EXPLAIN ANALYZE еще и выполняет запрос, добавляя фактические цифры: сколько строк прошло через каждый шаг, сколько времени заняло, сколько памяти использовано. Основные операторы в плане: ◾ Seq Scan - последовательное чтение всей таблицы (для маленьких таблиц - это окей). ✔ Оптимизация: добавить индекс на поля, которые используются в WHERE, JOIN, ORDER BY. ◾ Index Scan - чтение по индексу. ✔ Оптимизация: следи, чтобы индекс реально использовался: без функций, кастов и с правильным порядком колонок. ◾ Sort - дорогая операция, особенно на больших объемах и без индексов. ✔ Оптимизация: если сортировка нужна, то убедись, что есть индекс на поля сортировки. Если не нужна - убери. ◾ Hash Join / Merge Join / Nested Loop - это способы соединить таблицы. Hash Join и Merge Join обычно быстрее на больших данных, Nested Loop - на маленьких. ✔ Оптимизация: главный прием - уменьшить данные до JOIN, а не после. ◾ Cost=1..123 - оценка оптимизатора, где первое число - стоимость получить первую строку, второе - все строки. Чем меньше - тем лучше. ✔ Оптимизация: это лишь оценка оптимизатора, ориентируйся на реальные метрики из EXPLAIN ANALYZE. Я не буду переписывать сюда всю документацию. Вот ссылки на официальные руководства, где все подробно расписано: - PostgreSQL - MySQL - SQL Server - Greenplum - ClickHouse Твое задание на сегодня Возьми любой запрос, который работал долго, и выполни перед ним EXPLAIN, найди самый дорогой узел по стоимости и попробуй его оптимизировать. Интересными кейсами делись в комментариях! #харды #sql

Как учатся модели машинного обучения? Ранее я написал небольшую статью про историю ML, а сегодня хочу развить тему дальше. Речь пойдет о моделях, которые учатся, минимизируя функцию потерь градиентными методами. У других алгоритмов (например, деревья) свои механизмы, но они тоже оптимизируют критерий качества. Есть и алгоритмы, которые вообще не проходят этап обучения - например, kNN просто хранит обучающие данные и делает предсказания на основе ближайших соседей. Когда модель обучается с «учителем», у нее есть простая джоба: на вход размеченные данные, на выход - предсказание. Но дальше возникает ключевой вопрос: как понять, насколько предсказание хорошее, и как сделать так, чтобы в следующий раз было лучше? Для этого нужна функция потерь (loss). Формально функция потерь сравнивает две вещи: ▪️ правильный ответ (y); ▪️ предсказание модели ŷ. И превращает разницу между ними в число ошибки. Именно это число становится целью обучения - модель старается его уменьшить. Как выглядит обучение по шагам? Обычно перед обучением проводят подготовку и делят данные на три части: ▪️тренировочная выборка - это те данные, на которых будет учиться модель; ▪️валидационная выборка - чтобы проверять, не начинает ли модель «зазубривать» тренировочные данные и как лучше настроить параметры; ▪️тестовая выборка - финальная честная проверка, когда обучение уже закончено. 1⃣ Модель делает предсказание Мы подаем признаки (X) в модель, она считает ответ и выдает свой прогноз. 2⃣ Считаем ошибку (loss) Теперь сравниваем получившееся предсказание модели с правильным ответом, то есть y и ŷ. Получаем ошибку модели и если модель сильно ошибается - loss будет большим. Если предсказывает хорошо, то маленьким. 3⃣ Считаем градиент Дальше нужно понять, как изменить параметры модели, чтобы ошибка уменьшилась. Для этого считается градиент функции потерь - он показывает направление, в котором нужно менять параметры. 4⃣ Обновляем параметры модели Сам градиент параметры не меняет. Его использует оптимизатор - специальный алгоритм обновления весов. Оптимизатор делает маленький шаг в сторону уменьшения ошибки. И после обновления параметров цикл начинается заново. В итоге получается такой алгоритм: Сделали предсказание > Посчитали ошибку > Вычислили градиент > Обновили параметры > Повторили тысячи раз. Какие бывают функции потерь? Их много, потому что разные задачи требуют разных способов измерять ошибку. Для интуитивного понимания достаточно двух примеров: ▪️MSE (mean squared error) - ошибка возводится в квадрат. Это значит, что большие ошибки «наказываются» особенно сильно, поэтому модель старается избегать крупных промахов. ▪️MAE (mean absolute error) - берется просто абсолютная разница. Такая функция потерь относится к ошибкам более спокойно и обычно лучше переносит редкие выбросы. Понимание этого цикла - одна из базовых идей ML. Многие современные модели, от простой линейной регрессии до нейросетей, в той или иной форме обучаются именно так. #харды #ml