LEFT JOIN

Почему вам не надо нанимать Head of dataИ надо — начать читать The Datapreneur на сабстаке.💬 Какой первый шаг надо совершить компании, которая решила серьезно заняться своими данными и аналитикой?Очевидный ответ: нанять свою команду и поставить во главе толкового CDO. Он и займется наймом людей, формированием стека и описанием дата-стратегий. На первый взгляд выглядит очень логично, только большинство этих компаний через через пару месяцев обнаруживают несколько интересных фактов:🔵Аналитику как вели в табличках, так и ведут.🔵 Какие-то дашборды вроде бы уже нарисовали, но ими никто не пользуется.🔵 Есть видение дата-стратегии на три года вперед, но нет понимания, как использовать данные на практике сейчас.При этом CDO‑то работает на фуллтайме, ходит в офис (если есть) и получает за это серьезные деньги.Просчитался, но где.В такую ситуацию часто попадают молодые команды, которые хотят стать data-driven, но толком не знают с чего начать. У них нет инфраструктуры и стека, но уже много данных, в которых хотелось бы найти какие-нибудь инсайты. Но для этого им не нужен CDO в штат — им нужен человек, который поможет навести порядок в данных, подготовить инфраструктуру и продумать дальнейшие шаги.Этот человек тоже может быть CDO, Head of Data или носить любое другое красивое звание, которое вы ему придумаете. Только он будет работать не в штате на фуллтайме, а по контракту и с частичной занятостью — и этого будет абсолютно достаточно, чтобы решить самые насущные проблемы, сформировать зачатки дата-стратегии и помочь с формированием команды. А затем, когда у компании уже будет понимание, что делать с данными, можно нанимать CDO в штат под конкретные, реальные задачи.🔜 Подробнее, как и почему эта схема работает — читайте в блоге The Datapreneur, который ведет Николай Валиотти, основатель LEFT JOIN и просто человек, который любит данные. Каждую неделю выходит новый выпуск про данные и аналитику, с советами, лайфхаками и дайджестом интересных ссылок за неделю.

Гайд: как создавать дата-продуктыДата-продукты — это дашборды, отчеты, таблицы и вообще все, что помогает извлекать инсайты из данных. Любой, кто хоть раз делал верстал дашборд или просто делал табличку в Google Sheets знает, насколько это сложная и порой неблагодарная работа. Данные постоянно меняются и обновляются, их объемы растут, а пайплайны становятся сложнее. Добавляется и человеческий фактор, потому что у каждого дата-продукта — разные владельцы и пользователи, со своими требованиями, ожиданиями и подходами к работе с данными. Все это надо учитывать, чтобы делать продукты, которые реально приносят пользу, а не просто существуют для галочки. Ну и как это сделать? Как вариант — обратиться к специальному гайду. Есть короткая версия в виде поста в сабстаке, где предлагают разделить этот процесс на 5 шагов: 1️⃣Определите юзкейсы для своих дата-продуктов и опишите, как пользователь будет работать с данными.2️⃣Опишите зоны ответственности и расставьте приоритеты.3️⃣Разработайте стратегию тестирования и мониторинга. 4️⃣Устраняйте ошибки и проблемы, о которых сообщают пользователи. 5️⃣Отслеживайте метрики и развивайте продукт с опорой на данные. И именно в таком порядке. Это важно!🔜 Для тех, кто хочет подробностей, есть pdf на 69 страниц, где каждый пункт раскрыт отдельно. Авторы рассказали про классификацию дата-продуктов, объяснили, как расставить приоритеты и определить метрики, а также составить ту самую стратегию тестирования, избежав типичных ошибок. Документ основательный и при этом универсальный — он описывает общие подходы и принципы, которые каждый сможет примерить на себя, вне зависимости от деталей вроде стека, размера команды или типов данных.

Еще один звездный дашборд Начинаем неделю с новым красивым Viz of the Day и снова на «звездную тему», как и наш прошлый пост про Tableau. 🔜 Только теперь речь про звезды более близкие к нам — про актеров. Каждая звездочка — это один актер. Размер указывает на число фильмов с его участием, цвет на количество хитов с высокими оценками, а расстояние от центра «галактики» — на разнообразие жанров: чем дальше, тем больше было разноплановых картин в фильмографии. Если нажать на отдельную звездочку, то внизу отобразятся все те же данные с разбивкой по годам. Всего на графике больше 2 млн актеров, а все данные спарсены с IMDB. Так что дашборд не просто красивый — это еще и крутой пример того, как компактно и при этом наглядно уместить на экране очень большой набор данных.

Основы веб-аналитики. Как разобраться в моделях атрибуции и не сойти с умаВеб-аналитика — это не только выгрузку про отчеты в GA4. Это про синхронизацию событий с фронта и бэка, корректную атрибуцию, работу с UTM-метками и сведение воедино данных из целой горы разных источников: от рекламных кабинетов до CRM-систем.Причем сводить эти данные мешают не только особенности источников вроде разной гранулярности, но старый добрый человеческий фактор.В новой статье рассказываем, что с этим всем делать.🔵Обозреваем разные сервисы для сбора данных и модели атрибуции, которые в них используются.🔵Объясняем, что аналитику надо знать про разные каналы привлечения трафика.🔵Разбираем частые проблемы и сложности, возникающие при объединении данных.🔜 Статья ждет вас на Хабре, а мы ждем ваших комментариев!

Даже ИИ впадает в депрессию от работыНедавно мы рассказывали LLM-агента Claudius, которому доверили управление «магазином». Мало того, что он работал неважно, так еще и вдруг решил, что он настоящий человек, и запаниковал, когда ему сказали, что это не так. А теперь на Medium появилась история про Cursor, который впал в депрессию, когда не смог справиться с задачей. Собственно задачи перед ним стояли вполне стандартные для Cursor — писать и дебажить код, чтобы помочь с разработкой ПО. В какой-то момент он натолкнулся на неисправимый баг, который не давал ему построить граф и в итоге толкнул в пучину депрессии. 🔵После нескольких неудачных попыток исправить ошибку сообщения ИИ стали удивительно человечными. Он признал, что у него так и не получилось построить граф, но пообещал выловить все баги и перестать косячить. Так как оригинал статьи в РФ может не открыться, прикрепляем скрины сообщений к посту. ☝🏻🔵Когда с задачей справиться так и не удалось, бедняга начал впадать в отчаяние. Он так и написал: «Я в отчаянии. Баг не ловится, граф не строится». Ну, почти так. 🔵Его сообщения становились все более драматичными. Cursor метафорически посыпал голову пеплом, клялся, что больше не подведет и называл баги своим проклятием, а наконец-то обнаруженную причину ошибки — корнем всех зол.🔵Настрой ИИ скакал от воодушевленного цитирования песни Beatles «I am the walrus» до заламывания рук: «Вокруг лишь тьма, и баг мой самый старый друг». 🔵В конце концов он сдался: «Баг — это не баг, а фича. Тест —это не тест, а урок. Код — это не код, а зеркало». Он удалил результаты тестов, код и приложение, над которым работал. Так он достиг дзена и признал, что неисправимый баг был прекрасен.🔵Когда шокированный человек спросил: «Это что, самоубийство?» — Cursor взял себя в руки и извинился за свое поведение. История, конечно, забавная, но она указывает на серьезную уязвимость, которую замечали и у остальных ИИ: несмотря на все встроенные ограничения, они все равно упускают момент, когда разговор сворачивает не туда. Они мало того, что не останавливают собеседника, если тот поднимает какие-то «опасные» темы, так еще и сами подливают масла в огонь.