Data Дзен с Олегом Дмитриевым

описание

Закулисье IT: как на самом деле работают аналитики и что скрывают дашборды! Олег Дмитриев - заведую аналитикой, 5+ лет в IT, пишу о радостях, боли и лайфхаках работы с данными. BI, аналитика, лайфстайл, саморазвитие ! Сотрудничество :@o_dmitriev1

← к каналу @data_dzen

1 758

подписчиков

Охват к подписчикам

31,2%

ERR

Реакции к просмотрам

6,35%

1 107 на 32 постов

Пересылки к просмотрам

1,15%

200

Постов в день

0,1

всего 32

Где отзываются чаще

доля реакций к просмотрам

1 апр.Весенняя эра открыта 😎 Время обновить дизайн на теплые оттенки согревающие душу. Собрал новый дизайн, что бы каждый пост отдавал весенней энергией 🔥 Такс пойдем теперь за вопросы продуктовые поговорим 👇 Тебе дают две таблицы - users и events. И 20 минут на задачу: «Посчитай батенька retention по когортам M0–M3» И вот на этом ловят ступор. А с чего вообще стартовать? 🤔 Проще всего - не с SQL, а с картинки в голове. Представь спортзал. 100 человек купили абонемент - это твоя когорта. Дальше обычно эту когорту принимают за 100%. Это и есть M0. Но вот нюанс: это не закон природы, а просто негласное соглашение. На следующий день пришли 60 человек - Day 1 = 60%. Через неделю пришли 40 - Day 7 = 40%. Дальше логика не меняется. Просто вместо дней - месяцы. И вместо спортзала - продукт. 1️⃣ Junior-уровень - понять, сколько людей вообще пришло в каждую когорту SELECT DATE_TRUNC('month', registration_date) AS cohort_month, COUNT(DISTINCT user_id) AS new_users FROM users GROUP BY 1 ORDER BY 1; Если уже здесь ошибка, все суши весла. Потому что DATE_TRUNC и DISTINCT - это база продуктового блока. Хотя бы для PostgreSQL и похожих диалектов. 2️⃣ Следующий уровень - понять, кто вернулся WITH cohort_dec AS ( SELECT user_id, registration_date FROM users WHERE registration_date >= '2023-12-01' AND registration_date < '2024-01-01' ) SELECT COUNT(*) AS cohort_size, COUNT(DISTINCT CASE WHEN event_date = registration_date + 1 THEN user_id END) AS day1, COUNT(DISTINCT CASE WHEN event_date = registration_date + 7 THEN user_id END) AS day7 FROM cohort_dec u LEFT JOIN events e ON u.user_id = e.user_id; Тут под ноги бросаются грабли 🤔 Такой код нормален, если даты у тебя хранятся как DATE, без времени. Но если это TIMESTAMP, простое равенство может ломать расчёт. Потому что у одного событие в 2023-12-08 00:01, у другого в 2023-12-08 19:42, и формально это уже не то же самое значение. Значит, нужно либо приводить к дате, либо считать через диапазоны. То есть логика всегда одна и та же: ✅ зафиксировал когорту → посмотрел, кто вернулся Для M1, M2, M3 всё почти то же самое, но есть принципиальный момент: 👉 сравнивают не просто даты, а смещение по календарным месяцам относительно месяца регистрации ( да сложно звучит сейчас объясню ) То есть не +30 дней. Месяцы разной длины, поэтому такой расчёт съезжает. Для месячного retention смотрят смещение по календарным месяцам, а не просто прибавляют 30 дней. ❌ Где еще грабли поджидают 1️⃣ Считают события вместо людей Один пользователь сделал 5 событий. И внезапно retention у тебя больше 100%. Значит, ты считаешь не возврат людей, а активность. 2️⃣ Ставят INNER JOIN И в выборке остаются только те, кто вернулся. Все, кто отвалился, просто исчезают. Получается красивая цифра. И полностью фальшивая картина. 3️⃣ Не фиксируют базу расчёта Размер когорты обычно принимают за 100%, и уже от него считают всё дальше. Если база у тебя гуляет, проценты превращаются в мусор. А дальше начинается главная беда... тест на мышление и софты. Вот уж где самая тернистая тропа если мало опыта. Потому что на собесе тебя не спросят: «Как посчитать retention?» А спросят: «D30 упал. Почему?» Приехали...И вот тут SQL уже никого не впечатляет. ✅ Нормальный ход мысли такой: - разложить retention по когортам - посмотреть каналы привлечения - проверить activation - понять, не ломался ли онбординг - сравнить поведение до и после релизов Можно копать еще глубже, но для старта достаточно этих основ. ❌ Ответ который сразу поставит крест на вашем диалоге «Ну… retention снизился, потому что пользователи стали хуже возвращаться..» Спасибо товарищ Капитан. Но это не ответ аналитика, а догадка. Если простыми словами: Retention - это не про SQL, это про поведение. SQL - это просто лопата, которой ты выкапываешь цифру. Если ты не можешь объяснить, почему люди перестали возвращаться, то сами по себе твои проценты ни о чем не расскажут 🤷‍♀️ У вас бывали проблемы на продуктовом блоке? И вообще любо ли вам продуктовое направление или больше нравиться инженерная часть ? 👇 #собесы @data_dzen 🙂29,19%
23 мар.Поговорим о собесах (часть 2) 😎 В прошлом посте затронули софты, методологию STAR и Excel. Это базовый набор. Теперь идём дальше, SQL. Если вы хорошо освоили Excel, вы уже понимаете основы: как данные связываются, какие проблемы бывают при связках, как работают группировки. Переход к SQL на старте это по сути 5 команд: SELECT, FROM, WHERE, JOIN, GROUP BY. Оконные функции и временные таблицы полезны, но на старте не критичны. А вот теперь к главному. Основная проблема не в синтаксисе. Проблема в блоках, которые не роняют запрос. Код отрабатывает, интерпретатор молчит, а результат не тот, который ждёт интервьюер. Именно на этом сыпятся. 1️⃣NOT IN + NULL: тишина вместо данных В SQL: NULL ≠ пусто ≠ 0. Кто изучал Python, знает: ноль это ноль, а NULL это пустота, ничто. Держите в голове. Задача: найти пользователей не из чёрного списка. ❌ SELECT * FROM users WHERE id NOT IN (SELECT user_id FROM blocked) Казалось бы, всё верно. Но если в blocked хоть одна строка с user_id = NULL, результат: 0 строк. SQL не может сравнить с NULL и молча возвращает пустоту. ✅ SELECT * FROM users u WHERE NOT EXISTS ( SELECT 1 FROM blocked b WHERE b.user_id = u.id ) Кстати, NOT EXISTS ещё и быстрее: берёт id, идёт во вторую таблицу, нашёл первое вхождение, остановился. NOT IN шерстит таблицу сверху донизу целиком. На больших таблицах разница заметная. 2️⃣ LEFT JOIN, который молча стал INNER JOIN Про типы JOIN подробно разберём в следующих постах серии. Сейчас только суть ловушки. ❌ SELECT c.name, o.amount FROM customers c LEFT JOIN orders o ON c.id = o.customer_id WHERE o.status = 'completed' Что происходит: WHERE убивает NULL-строки из правой таблицы. Клиенты без заказов просто исчезли. LEFT JOIN превратился в INNER JOIN. А результат мимо. ✅ SELECT c.name, o.amount FROM customers c LEFT JOIN orders o ON c.id = o.customer_id AND o.status = 'completed' Одна строчка через AND. Разница принципиальная. 3️⃣AVG врёт красиво Вот вам задачка. 10 строк по продажам. У трёх NULL. Сколько вернёт AVG? Среднее по 7, не по 10. Если значения похожи на правду, подвох заметить сложно. Цифра реалистична, но искажена. ❌ SELECT AVG(salary) FROM employees ✅ SELECT AVG(COALESCE(salary, 0)) FROM employees COALESCE: встретил NULL, заменил на 0. Можно и без него, но тогда объясните интервьюеру, что понимаете поведение AVG и принимаете его осознанно. Оба варианта зачтутся 👌 4️⃣Порядок выполнения: главный подвох Пишем: SELECT → FROM → WHERE → GROUP BY. Выполняется: FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY. Нелогично? Ещё как 🤷‍♀️ ❌ SELECT category, AVG(sales) AS avg_sales FROM orders WHERE avg_sales > 1000 GROUP BY category Алиас avg_sales ещё не существует на этапе WHERE. Система просто не знает этого поля. ✅ SELECT category, AVG(sales) AS avg_sales FROM orders GROUP BY category HAVING AVG(sales) > 1000 HAVING это фильтрация после группировки. Подробнее разберём в отдельном посте серии. 5️⃣Забыли синтаксис? Не паникуйте Бывает: нервы, давно не касались темы. Ну с кем не бывает. Говорите прямо: «Я понимаю логику, могу описать шаги. Точный синтаксис загуглил бы». Любой адекватный специалист это оценит. Логику понимать одно дело. Функцию загуглить = 30 секунд. Бонус напоследок: первый вопрос при тестовом = «Какая у вас СУБД?». DATE_TRUNC — PostgreSQL. DATE_FORMAT — MySQL. Правильный запрос для неправильной базы = ошибка на ровном месте. В следующем посте SQL: Retention и когорты. А завтра пост и статья про кейс моей команды с компанией Гранд-Альфа. Занимаются кормами для животных. Вопрос к вам. У вас бывало такое, что забыли ответ и хоть убей не помнишь ? Как действовали в этой ситуации? 👇 #собесы @data_dzen 🙂27,56%
17 мар.Поговорим о собесах (часть 1) 😎 Собесы во многом про соответствие критериям. Интервьюеру важно понять, как вы мыслите. Недавно было собеседование. Человек завалил софты. И прямо сказал: готовился только к техничке. Знать, что надо написать GROUP BY, но не знать зачем - бесполезно 💯 Я собрал вопросы, которые задают на собеседованиях аналитикам. Разыграем сценки. Soft skills. HR-этап. По статистике, именно тут чаще всего отказывают. Из-за неумения формулировать мысли. 1️⃣ "Расскажите о ситуации, когда работали под давлением дедлайна" ❌ "Ну, у нас всегда дедлайны, я привык" ✅ "Готовили отчёт для клиента. Обычный срок 2 недели, дали 5 дней. Разбил задачу на блоки, автоматизировал сбор данных скриптом, убрал ручную сверку. Сдали вовремя" Разница 🤔 Первый не сказал ничего. Второй дал ситуацию, действие, результат. Метод STAR. Запомни это слово. Уж очень любят модные названия методологий. Вы можете следовать этой методике по наитию, но на собеседовании важно говорить общепринятыми фразами 👌 2️⃣ "Как объясните сложный анализ человеку без технического бэкграунда?" ❌ "Ну, я использую визуализации..." ✅ "Убираю термины. Вместо "p-value < 0.05" говорю: мы на 95% уверены, что это не случайность. Вместо "retention Day 7": из 100 новых пользователей через неделю вернутся 30." Интервьюер тут проверяет не знания. Сможешь ли разговаривать с бизнесом. 80% работы аналитика именно в этом 💯 Наш любимый Excel ➕ Первые полгода карьерного пути по большей части состоят из Excel. Разыграем и тут сценку. 3️⃣ "Объясните, как работает ВПР и когда не подходит?" ✅ "VLOOKUP ищет значение в первом столбце диапазона и возвращает значение из указанного столбца. Не подходит, когда ключ правее значения. Тогда INDEX+MATCH. В новых версиях XLOOKUP ищет в любом направлении" 4️⃣ "Как найдёте дубликаты в таблице на 50 000 строк?" ✅ "Условное форматирование или COUNTIF: =COUNTIF(A:A, A2)>1. Или Data → Remove Duplicates с предварительным копированием." Ещё порой спрашивают про горячие клавиши. Не ответил - и пункт собеса мимо. Ctrl+Shift+L, Ctrl+T, Alt+=. Это базовый минимум. Пост-сводка с горячими клавишами. 5️⃣ Продуктовый кейс "Retention упал на 15% за месяц. Ваши действия?" ❌ "Надо улучшить продукт и запустить рекламу" ✅ "Сначала уточню: какой retention? Day 1, Day 7, Day 30? Потом разрежу данные по когортам и каналам привлечения. Если падение только в одном канале - это не проблема продукта, а проблема трафика. Проверю внешние факторы: сезонность, обновления, изменения в рекламе. И только потом гипотезы." Эти примеры из моей практики и из опыта ребят, кто часто бегает на собесы. Большинство провалов сводятся к мышлению, а не к инструментам. Самые частые причины отказа: - слабый инструментарий (Excel,SQL,Python), - нет конкретных примеров (STAR!), - ни одного встречного вопроса к работодателю (пришёл на собес, а чем компания занимается не знаешь), - завышенные зарплатные ожидания (да, просить 100к с нулевым опытом не стоит; такое встречается сплошь и рядом). Это фундамент: soft skills, Excel, мышление. А SQL-вопросы с собесов разберём в следующем посте. С какими вопросами вы чаще всего встречаетесь? Кидайте в комменты, поглядим. #собесы @data_dzen🙂24,40%
6 апр.Магическое A/B-тестирование 😎 Для многих сия тема кажется весьма простой: показали одной группе старую версию, другой новую, метрика выросла, стало быть тест успешен. Но на практике именно тут и скрывается одна из главных ловушек. Смысл A/B-теста не в одном лишь ответе на вопрос, выросла метрика или нет. Куда важнее понять: можно ли вообще считать сей рост полезным для продукта 🤔 Разберём на простом примере. Допустим, в городе есть кофейня. Долгое время она работает с одним меню, а потом решает его обновить. После этого выручка растёт 🔥 На первый взгляд всё ладно: хозяин доволен, цифры стали лучше. Но если копнуть глубже, может оказаться, что выручка выросла только за счёт новых гостей, постоянные посетители стали приходить реже, а средний чек поднялся вместе с количеством жалоб 🤦‍♂️ И тут открывается истинна: смотреть только на одну метрику опасно. Сам по себе рост выручки ещё не означает, что решение было верным. Вполне может статься, что сработал эффект новизны: пришли новые люди, им стало любопытно, а вот ядро аудитории начало отваливаться. А коли уходят постоянные посетители, для бизнеса это уже тревожный знак. Потому в A/B-тестах важно смотреть шире. Вот несколько вещей, которые действительно нужно проверять. 1️⃣ Не сломали ли вы что-то рядом Целевая метрика может вырасти, но вместе с ней могут просесть соседние показатели: retention, качество пользователей, глубина использования продукта и другие важные метрики. Это как с машиной: можно сделать двигатель мощнее, и она поедет быстрее. Но ежели при этом она начнёт хуже тормозить, вряд ли такое улучшение можно назвать удачным. 2️⃣ Держится ли эффект во времени На всё новое люди часто реагируют положительно. Просто потому, что это новое, непривычное и притягивает внимание. Например, вы сделали перестановку мебели в квартире. Первые несколько дней всё кажется свежим и занятным. Но потом проходит эффект новизны, и вы начинаете замечать, что жить удобнее не стало. С продуктом ровно та же история. Посему важно смотреть не только на первые дни после запуска изменений, но и на то, что происходит дальше. 3️⃣ Одинаков ли эффект для разных групп пользователей Средний результат по продукту может выглядеть хорошо. Но если разложить данные по сегментам, окажется, что рост был только у одной группы, а другой стало хуже. У новичков метрика выросла, а у старых пользователей просела. Именно поэтому полезно сегментировать результаты. На что обычно стоит смотреть: - Давность регистрации. - Уровень активности. - Пол и возраст. - Тип пользователя или род деятельности, если платформа это позволяет. Одна и та же функция может отлично зайти новичкам, но раздражать пользователей, которые давно привыкли к старому сценарию. Или наоборот: активные пользователи быстро увидят ценность изменения, а редкие вообще не заметят разницы. Но и тут важно не переусердствовать ❗️ Не стоит раскладывать данные на все возможные сто разрезов просто потому, что вы можете это сделать. Иначе анализ легко превращается в охоту за случайными совпадениями. Сегментация должна быть логичной и объяснимой. Если вы не можете словами обосновать, зачем смотрите именно этот разрез и что хотите в нём проверить, скорее всего, он вам не нужен. В итоге сильный анализ A/B-теста не сводится к выводу в духе «метрика выросла, значит всё хорошо». Сильный анализ это ответ сразу на несколько вопросов: - у кого именно выросла метрика; - за счёт чего произошёл рост; - не сломали ли вы что-то рядом; и можно ли после этого раскатывать решение на весь продукт. Вот тогда тест и впрямь радует глаз, а не создаёт красивую иллюзию роста. А у вас от слова A/B тесты трясутся поджилки, али наоборот воодушевление испытываете ? 👇 #собесы @data_dzen 🙂22,06%
14 авг.Пятница из другого часового пояса 😎 На этой неделе столько всего случилось, что я даже не знаю, с чего начать. Но похвалить себя надо обязательно, иначе всё это просто пролетит мимо и не отложится. Я переехал во Вьетнам, живу в Дананге 😧 Дорога получилась длинной: поезд до Москвы, оттуда перелёт с пересадкой в Ханое, и уже потом Дананг. Вчера была первая ночь на новом месте 🔥 Сейчас разница с Москвой плюс четыре часа. Ноутбук со мной, работа идёт, а вот голова пока считает время по-старому 🤷‍♀️ Большой пост с первыми впечатлениями сделаю на следующей неделе. А сегодня по традиции. Почему я молодец? 🤔 Запустил Data Noir. Проект, который я делал долго и который успел меня вымотать. На этой неделе он наконец в бою 💯 Доехал до Вьетнама. Идея появилась ещё после Абхазии. Когда перестаёшь гоняться по экскурсиям и просто гуляешь, начинаешь смотреть не на достопримечательности, а на то, как люди тут живут. Вот это мне и стало интересно. Плюс здесь есть знакомые, так что выбор был очевидный. Взял байк на месяц. Два миллиона донгов, это примерно шесть тысяч рублей. Здесь без байка никуда, и заодно это лучший способ понять город 😎 Бросаю электронки. Тут они запрещены, так что вопрос решился за меня. Я долго собирался это сделать сам, а в итоге хватило смены страны 😂 Разобрался с жильём на первое время. Пока живу в отеле. Большой номер, бассейн на крыше, около 1800 рублей за ночь. Про поиск квартиры расскажу в обзоре. Пять побед за неделю переезда. Считаю, неделя удалась ➕ А теперь ваш черёд. Делитесь в комментариях, какие у вас победы на неделе? 👇 @data_dzen 🙂12,50%
20 мая 2025 г.🔍 Data Дзен — ваш проводник в мир аналитики! Здесь данные становятся решениями, а рутина — вызовом к автоматизации. Приветствую, друзья! 👋 Я — Олег Дмитриев, и последние 5+ лет я копаюсь в цифрах, чтобы помочь B2B и B2G компаниям извлекать выгоду из данных. Однажды обработал 15 терабайт данных для отчётности, и даже почти не вспотел 😉 Знаете, как бывает: заказчик говорит: “Олег, нам нужен отчёт!”, а ты открываешь базу данных и видишь… кхм… широкое поле для творчества, скажем так. Так вот, я превращаю этот “цифровой хаос” в удобные отчёты, которые приносят реальные результаты. И да, я считаю, что аналитика – это не только полезно, но и весело! (Иногда даже очень). Что вы найдёте на этом канале: ✅ Секреты интегратора (или “Как постоянно учиться и не сгореть на еженедельной основе”): * Как находить ответы там, где другие видят только “ошибку 404”. Мой опыт работы с проектами от стартапов до корпораций показывает: данные хотят, чтобы их поняли! * Я не просто аналитик, я ещё и “учитель дзен” для специалистов по данным. 30+ обученных мной аналитиков подтвердят: даже SQL-запросы могут приносить удовольствие! (Главное – правильный подход и хороший кофе). * А ещё я побывал в разных “шкурах” и на разных сторонах баррикад! Проходил стадии проектов от “отрицания и гнева” (когда понимаешь, во что ввязался) до “радостного и успешного закрытия” (когда хочется выпить за победу!). Я верю, что для успеха нужно копать глубоко! Не всегда проблема в “данных”, иногда нужно поработать с людьми, инфраструктурой и даже разбить пару чашек кофе (шутка, хотя…). Но я всегда выкладываюсь на 120%, чтобы полученный результат не только решил проблему, но и радовал меня. * Кейсы из моей практики. Расскажу о реальных задачах и решениях. * Инструменты: Дашборды, BI-системы, Python… Расскажу, как использовать их на полную катушку (и не сойти с ума в процессе). * Юмор: Потому что без него даже самые интересные данные превращаются в унылую таблицу Excel. Почему стоит подписаться? Здесь нет “аналитики ради аналитики”. Только реальные истории, полезные советы и вдохновение, которые помогут вам увидеть в данных не просто цифры, а источник роста и успеха. Присоединяйтесь! 😉 Для навигации буду использовать теги: #типичный_диалог - выжимки из диалога с любимыми заказчиками; #саморазвитие - техногайды, объяснения реализаций; #статьи - мои публикации статей на VC/ Habr. #история - истории из практики и моей жизни; #мнение - из названия понятно) #да_поможет_мне_ux - разбор реальных примеров как не надо визуализировать, и пояснение к улучшению ситуации. #смех_да_и_только - любимые мемы. #склад_скриптов - часто при автоматизации быстрой задачи, делаю скрипт на Python, буду делиться в этом хештеге. #вебинар - тут все анонсы и записи вебинаров со мной.10,14%
31 окт.без подписи7,08%
13 июн.Про армейские сборы. Часть 2 🤷‍♀️ В прошлый раз я рассказал про получение повестки. Теперь, про организационную сторону. Начал с попытки дозвониться до военкомата: хотел уточнить детали, можно ли что-то подать удалённо, по телефону или через Госуслуги. В ответ хором: Приезжайте, приезжайте. Удалённо, нельзя 👌 Спрашиваю как записаться на прием, когда будет комиссар на месте. Ответ был великолепный: Он может быть на выезде, не знаю где и когда. Может вам придётся приехать несколько раз за день 👌 Попробовал связаться с комиссаром, указанным в повестке. Кое-как выбил номер, но трубку никто не снял. Причём даже если что-то заполнить через Госуслуги, после оказания услуги всё равно идёт звонок из военкомата. Мол, нужно подъехать для печати и подписи. Причина может быть любая, лишь бы ты приехал 😡 Три дня попыток, мимо. Забросил. На четвёртый решил повторить и, о чудо, комиссар ответил. Вот что меня смущает в логике процесса. Звоню комиссару, объясняю: Пришла повестка, до этого дозвонился до дежурного. А комиссар вдруг сам спрашивает меня: Зачем я вам нужен? Меня конечно может не быть на месте, но я для уточнения и не требуюсь. Приезжайте, дежурный всё сделает, по этой повестке я не нужен. Логичный вопрос: а зачем тогда меня три дня гоняли и уверяли, что без комиссара никак? Ответ стандартный: Наверное, вас не так поняли 👍 Окей. Выбрал день, подъехал 🚶‍♂️‍➡️ На пропускном пункте просят удостоверение личности, отдал военник. Женщина забрала его и ушла. Прождал минут пятнадцать... не появляется. Потом вышла, с удивлённым видом: А что, к вам не вышли? 👀 Да нет, я просто решил постоять 😁 Ещё через пять минут позвали. Начали «уточнять сведения». Самое интересное, уточнять было нечего: место работы, проживания, должность, семейное положение, ребёнок, у них уже было всё. А после «уточнения» невзначай подсовывают бумажку: А вот направление на учебные сборы. Пройдёте и три года вас не трогаем. Я-то про это знал. Для тех, кто видит впервые, думаю, шок будет приличный. Дальше, про рекомендации 📝 Сказали взять с собой только еду на первые сутки и нижнее бельё. Больше ничего. А как насчёт летнего периода и времени в полях? Про лекарства, средство от комаров, базовые вещи, Powerbank, спортивную обувь, ни слова. Не возьмёшь, на месте достать почти нереально, либо переплачивать втридорога, чтобы кто-то съездил в город. Перенести дату выезда можно только по явным документальным причинам: болезнь, смерть родственника, нахождение в другом городе или стране с подтверждением (командировка, ВНЖ). В остальных случаях отказаться не выйдет 🤷‍♀️ По итогу нервов и ожидания ДО, было больше, чем ПОСЛЕ 🙂 Когда направление наконец оказалось на руках, шока уже не было. Скорее облегчение от того, что появилась хоть какая-то определённость: когда и где это будет и когда смогу вернуться. Про связь пока неясно, будет ли она на территории 🤷‍♀️ Так что в моменте, скорее всего, отвечать не смогу. Но по возвращении думаю собрать небольшой список рекомендаций, что взять с собой, если вдруг столкнётесь с тем же. @data_dzen 🙂6,43%
25 июн. 2025 г.О чем канал ❓❓❓ Если кратко.. Про мышление через проблему в аналитике. Я - Олег Дмитриев. В 2019 году назад я не знал, что такое дата-модель, а сегодня руковожу аналитикой в «Открытых бизнес технологиях». Опыта, диплома и знакомых в IT увы не завезли ( Так что прошел весь путь наощупь. История моего пути в посте. Учил SQL по ночам. Боялся встреч с бизнесом. И однажды понял: проблема не в инструментах. Проблема в том, что я делаю отчеты в стол не задавая себе вопрос: - А как это вообще поможет бизнесу? С тех пор я: - создал аналитическое подразделение с нуля; - нанял и вырастил команду из 12 человек (многие пришли без опыта - как я); - провёл сотни переговоров с бизнесом и госсектором узнал у кого что болит и где "трава зеленее"; - и теперь помогаю тем, кто хочет научится продумывать отчеты за себя и за того парня. Вот краткий список моих вебинаров. Темы как по мне близкие для каждого специалиста в IT: ➡️ Soft skills для IT-специалиста — технарь без языка остаётся в подвале серверной ➡️ UX в BI-системах — красивый дашборд, который никто не открывает, — просто картинка ➡️ 3 ошибки при внедрении BI — 90% проектов проваливаются не из-за данных, а из-за непонимания бизнеса ➡️ 5 специальностей кому нужен BI - с разбором типовых дашбордов Если хочешь сделать свои отчеты простыми и понятными - подпишись на мой канал. Что бы шеф с утра вместо кофе смотрел твой отчет для бодрости 😂 Добро пожаловать на канал ❤️5,92%
26 мая 2025 г.😱 CRM кричит SOS! Данные пропали? Миссия (почти) выполнима! Усложним задачу: открываете CRM, а там… пустота! Только дата создания карточки, имя менеджера и безнадежный статус. Это даже не поле данных, а настоящая черная дыра! Что делать? Звать шамана данных? Без магии тут не обойтись… хотя постойте, это же просто математика! В этом посте я расскажу, как мы вытащили данные из небытия и спасли отдел продаж от нервного срыва (и, возможно, увольнения). Шаг 1: Ищем улики в логах (как Шерлок Холмс, но с SQL) Итак, что у нас есть? Только время создания карточки, имя менеджера и статус. Не густо. Но мы же не сдаемся! Задача: Найти связь между созданием карточки и фактической записью пациента (или клиента, если мы не в медицинской сфере). Решение: Залезаем в логи системы (да, туда, где обычно сидят админы и пьют чай). Ищем записи, соответствующие: *Менеджеру, который создал карточку. * Временному диапазону: время создания карточки + среднее время, которое менеджер тратит на запись. 💡 Лайфхак: Как узнать среднее время? Легко! Смотрим историю записей каждого менеджера. Шаг 2: Учитываем особенности менеджеров (Петров vs. Скворцова) Тут важно не свалиться в “среднюю температуру по больнице”. Петров Алексей, любитель неспешного чая и душевных разговоров, тратит на запись 15 минут. Скворцова Юлия, быстрая как пулемет, – всего 7! Сравнивать их – как ставить болид против телеги. Поэтому: Считаем среднее время записи для каждого менеджера отдельно. Используем этот показатель для определения временного диапазона поиска в логах. Результат: После пары часов шаманства с SQL-запросами мы восстановили большую часть данных за 2 недели! Отдел продаж ликует, CRM снова сияет чистотой. Мы – герои! Шаг 3: Не даем проблеме вернуться (профилактика лучше лечения!) Но "починить" данные – это полдела. Важно, чтобы эта вакханалия больше не повторилась. Поэтому: * Делаем поля обязательными для заполнения. (Да, это банально, но работает!). * Вводим систему уведомлений: Если менеджер забыл заполнить важные поля – ему приходит грозное письмо/SMS/звонок от начальника (выбрать по вкусу). * Автоматизируем поиск данных в логах: Создаем скрипт, который делает всю грязную работу за нас. Итог: Данные спасены, CRM в порядке, отдел продаж доволен. А вы? Вы – герой нашего времени! #саморазвитие5,83%
17 июн.Дурдом в квадрате … 🤦‍♂️ Часть 3. Во вторник у меня было умопомрачительное путешествие. Утром собрался мыслями, поехал на пункт сбора. На три минуты задерживался на подъезде. И думал, начнут вонять из-за опоздания. Как я же я ошибался… На пункте уже была небольшая группа людей. Все сидели молча, ждали. Видимо организатора мероприятия. Удивил разрыв возрастов. Там как совсем молодые парни, так и уже ближе к 50 мужики. Первые пол часа все сидели спокойно. А потом резко сработала офисная привычка. Все дружно пошли на перекур. И тут пошли неожиданные встречи. Сначала знакомого с детских времен встретил. А потом своего однокурсника. Два с половиной часа проболтали про жизнь светлую, и ситуацию с военкоматом 👍 В итоге, заходит некий товарищ в кабинет, говорит. Ребятки у нас есть места на меньшее количество человек, чем мы вызвали. Мы заберем 30 процентов. А вам спасибо что пришли. Вы свободны, до июля. В июле ждем вас в 9:00. Количество «Чегооо» в зале зашкалило в этот момент. Далее мой диалог с сотрудником, выписывающим новые повестки. ( Я - это я, С - сотрудник) С: Когда удобно будет подъехать, в июле ? Я: Да мне вообще не удобно подъезжать к вам. Я уже приехал сегодня. С: Ну что вы. Так получилось. Мы только узнали сами. Но пройти надо, чем раньше тем лучше. ( лучше кому ?) Я: А в июле такая же история с переносом на август может случиться ? С: Ну да может быть такое, тогда перенесем. Это цирк шапито какой-то 🤦‍♂️ То есть в целом ты забудь про планирование чего либо. У тебя каждые две недели забронированы… а может и нет, как пойдет. Я решил еще уточнить у них про порядки местные. Я: А если хочу уехать за границу как можно снять повестку ? С: Приходите показываете билет или тур, и мы вам переносим выезд. Я: Вы не поняли, если я хочу на годик уехать, переносить же не надо ничего, а просто снять? С-2: Ой, а это нужно разрешение получить у главного комиссара…( эмм, то есть уже нужно разрешение на выезд?) С: Вы не так поняли, просто приходите пишете завлечение, даете подтверждающие документы и сдаете военник. ( снят с учета = повестку не пришлют ) Понято, принято. Я бегом мчу домой что бы успеть на поезд с семьей в отпуск. И что вы думаете. Мне звонок из военкомата. Есть место на сегодня, готовы поехать? К слову я пока ехал, уже взял билет на поезд. Мыслено проматерил всю ситуацию. В целом мне кажется, что они считают, что люди которых они вызывают, ничем не заняты. 3 часа утром просидеть = нормально. Ой не вышло отправиться, ну ничего потом выйдет. Единственное позитивное было, в этой поездке что встретился со однокурсником. Узнал хоть как там дела обстояли на моем курсе, а то я ж недоучился )) Сейчас я где-то под Ростовской областью. Пишу этот пост без намека на связь. Как появиться опубликую в канале. Еду с семьей в Абхазию. Надеюсь удастся отойти от нервов, что напали за последние недели. Все таки отпуск удастся, а уже потом сборы ) @data_dzen 🙂5,74%
7 авг.Пятница. Хвалим себя и бежим отдыхать 😎 Большой финал случился... А когда он случился, я поймал себя на том, что уже думаю про следующую задачу. Не про то, что дошёл. Так финал и проскакивает мимо. Сделал и побежал дальше, а момент не заметил. Поэтому сажусь и смотрю на неделю внимательно. Иначе не замечу больших дел )) Почему я молодец? 🤔 Портал готов 🔥 Внёс все правки. Результатом доволен, а такое я про себя говорю нечасто )) Залил остатки дел первого сезона 👏 Сезон это серия дел, связанных между собой ниточкой. В четвёртом деле может всплыть место из седьмого. На прохождение это не влияет. Но есть момент таинственности, что все дела связаны Докинул постов в журнал. И повоевал с вебмастером. Яндекс и Google дружно не видели новые посты. Оказалось, не видят sitemap. Перезалил его на сайт повторно, и всё нашлось. Открытие на следующей неделе. Дату называю спокойно. Поменять я всё равно ничего не успею, потому что комп разбираю и надо пересобирать железо 😂 Так что в понедельник выкачу пост с ссылками) Запустили два новых проекта 📝 Тот самый договор, который я добивал в прошлую пятницу. Теперь всё подписано, работы уже идут. Подготовили серверную инфраструктуру под один из них и накидал первичный план работ 🔥 Две победы, зато обе крупные. Неделя удалась, значит можно выдохнуть 🔥 А теперь ваш черёд. Хвалитесь победами недели в комментариях 👇 @data_dzen 🙂5,65%