Proof of Concept: Как проверить, что внедрение ML стоит свеч

Классный пост о том как правильно "продавать" внутренние проекты по машинному обучению.

https://habr.com/ru/company/ods/blog/438212/

Сравнение даты и строки в Postgres

Первый «улов» с поля проверок заданий студентов на курсе по DE. Коллега-ревьюер заметил, что у студента в работе теряются часть записей, когда в SQL запросе идёт проверка даты и строки:
<..>
WHERE created < '2022-04-03'

Короткий поиск подкинул вопрос со StackOverflow. Оказывается, чтобы сравнить время со строкой, под капотом Постгрес приводит строку ко времени; тогда он наивно из ‘2022-04-03’ получается '2022-04-03 00:00:00’, то есть начало суток, а не конец, как ожидалось.

Посмотреть подкапотную логику можно, прогнав запрос через EXPLAIN, там будет такая строка:

Filter: (created < '2022-04-03 00:00:00'::timestamp without time zone)

Как решение предлагают в запросах явно приводить дату-время к дате перед сравнением со строкой
WHERE created::date < '2022-04-03'

тогда под капотом будет сравнение дат с ожидаемым результатом:

Filter: ((сreted)::date <= '2022-04-03'::date)

Доска для сбора требований к дашбордам

https://miro.com/app/board/uXjVOOmjOqY=/?moveToWidget=3458764518437556371&cot=14

Пара здравых мыслей о приоритезации задач аналитиков из серии статей "How to Prioritize Analytical Work".

Например, вот советы из первой части по распределению времени на 4 типа проектов:
🔹Стратегические — 50%
🔹Операционные / Ad Hoc — 20%
🔹Обслуживание — 20%
🔹Исследования и эксперименты — 10%

А во второй части статьи - подробно расписанный пример бизнес-требований к таким проектам.
Для его составления последовательно отвечаем на вопросы из групп:
🔸Что требуется?
🔸Какая у этого бизнес-ценность?
🔸Какие верхнеуровневые шаги нужно предпринять?

🔗Ссылка на часть 1
🔗Ссылка на часть 2

#компетенции

Николай спрашивает:

> Как развивать в себе умение генерировать какие-то гипотезы, когда смотришь на данные. Все очевидные, типа сколько заказов у нас из города N быстро заканчиваются, да и ценность их не всегда велика. Базовые все проработали, а что дальше? Особенно когда нет каких-то видимых проблем?

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

Ой я знаю! Никак!
С помощью данных гипотезы надо не генерить, а проверять.

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

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

Гораздо надежнее сначала думать о бизнесе и все гипотезы генерить на основе здравого смысла.

Специально в честь такого замечательного вопроса достал старую заметку из уже закрытого курса: https://smysl.io/blog/figure-out/

Выгрузила в ноушн мысли по составлению дерева метрик.

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

Но в целом, если вы только начали думать в сторону иерархии метрик в своём продукте, то вам тоже зайдёт.