История Loom о том, как одна функция внутри почти провалившегося продукта дала 3000 регистраций за сутки, а анализ реального поведения пользователей помог команде найти дальнейший механизм роста.
Не успели мы толком оправиться от расследования про Культ Роя внутри OpenAI, как появились новые данные про проделки другой «цивилизации» агентов: на этот раз они общались между собой прямо у нас под носом в публичном интернете (и настрочили более 18'000 сообщений).
Бизнес-вопрос редко звучит как готовая аналитическая задача. Руководитель может спросить: «Какие подразделения требуют внимания?», «Пользуются ли приложением?» или «Почему результат изменился?». В этих формулировках понятен общий интерес, но ещё нет показателей, правил расчёта и структуры будущего отчёта.
Можно сразу выбрать несколько доступных метрик и построить графики. Но тогда система будет отвечать не на исходный вопрос, а на то, что оказалось проще посчитать.
В моих проектах эта проблема возникала и при разработке BI-отчётности для сравнения подразделений, и при проектировании аналитики мобильного приложения. В обоих случаях работа начиналась с широкого вопроса. Затем его нужно было разложить на более узкие аналитические задачи, определить объекты наблюдения, выбрать основные и объясняющие показатели, а после проверить, можно ли их достоверно получить из существующих данных.
В этой статье разберу сам переход от вопроса к показателям. Без универсального каталога KPI, потому что один и тот же показатель может быть полезен в одном процессе и бесполезен в другом.
Аналитик может создать логичную систему, которая окажется неудобной для тех, кто ей пользуется каждый день. Разбираем, почему возникает разрыв между ожиданиями специалиста и реальной работой пользователей, и как избежать проектирования «фантомных пользователей».
Как организовать регулярную выгрузку данных из 1С, если ручной экспорт уже не справляется с объемом и частотой обновлений? В статье сравниваются два подхода: прямой доступ к базе через SQL и использование готового ETL-инструмента. Разбираем скорость, сложность настройки, требования к специалистам, риски для безопасности и сопровождения системы. Также показываем, в каких случаях оправдан SQL, а когда удобнее использовать готовый инструмент для автоматической выгрузки данных по расписанию без постоянного участия разработчика.
Если вы проводите достаточно времени, используя DeFi, то вы заметите, что большинство диалогов крутится вокруг всего одной метрики: APY. Какой протокол предлагает наибольшую доходность? У которого из них наибольшая отдача? Какой пул ликвидности генерирует больше всего комиссий? Эти вопросы вполне резонны, но они упускают из виду кое‑что гораздо более важное. Насколько эффективно используется на самом деле ваш капитал?
Представьте себе двух инвесторов, каждый из которых владеет сотней ETH. Первый зарабатывает 7% годовых на депозитах в децентрализованном кредитном протоколе. В то время как второй имеет меньшую отдачу с его позиции в эфире, однако эти же самые активы одновременно обеспечивают безопасность сети в стейкинге, поддерживают кредитование, упрощают торговлю и ещё остаётся запас доступный для использования в дополнительных стратегиях. Если смотреть только на APY, то первый инвестор безусловно лидирует, но если смотреть насколько продуктивно используется их капитал, то картина становится гораздо менее очевидной.
Эффективность использования капитала незаметно стала одной из самых определяющих тем современного DeFi. Почти каждая значимая инновация последних нескольких лет претендовала на то, чтобы заставить криптоактивы работать полезнее и эффективнее без необходимости их постоянного перемещения между различными протоколами. Понимание этого сдвига помогает объяснить не только где сейчас находится DeFi, но и в каком направлении движется.
Требование может выглядеть понятным на этапе обсуждения, но при передаче в разработку превратиться в источник вопросов и переделок. В статье разберём, как находить «смысловую кашицу» в требованиях: выявлять скрытые допущения, пропущенные сценарии и слабые места ещё до начала реализации.
Инженеры данных построили агрегат — маленькую таблицу «продажи по магазинам по дням». Отчёт из неё собирается за доли секунды. А сводная в Excel всё равно ждёт двадцать секунд и читает миллиард строк.
Разбираемся на живом ClickHouse, почему база не видит предагрегат, который для неё построили, какая форма запроса это лечит (одна и та же для ClickHouse, Snowflake и BigQuery) и почему в итоге вопрос не к базе, а к семантическому слою. Внутри — замер на миллиарде строк: 3 секунды против 37 миллисекунд, сравнение восьми баз и одно правило, которое стоит проверить в своём BI.
Фраза «покажите нам всё» звучит как плохое требование. В ней нет конкретного пользователя, перечня показателей, периода, источников и даже понятного результата. Но за ней обычно стоит нормальная потребность: заказчик видит много разрозненных данных, регулярно получает отчёты вручную и боится потерять что‑то важное при переходе к новой аналитической системе.
Проблема начинается, если воспринять эту фразу буквально. Тогда в первый релиз пытаются включить все таблицы, показатели, фильтры и варианты детализации. Система растёт ещё до того, как становится понятно, кто и для чего будет ею пользоваться.
Я столкнулся с этим при проектировании BI‑контура для организации, где данные о разных направлениях деятельности уже находились в операционных системах и единой базе, но значительная часть отчётности проходила через выгрузки и ручную обработку. Пользователям были нужны сведения об учебных процессах, финансах, задолженностях, движении контингента, нагрузке и других направлениях. На верхнем уровне запрос действительно можно было свести к формулировке: собрать всё в одном месте.
Но «всё» нельзя использовать как границу проекта. Его сначала нужно разобрать на решения, роли, показатели, источники и сценарии проверки.
Привет! Меня зовут Дмитрий Гаврилов, я руководитель центра компетенции аналитики в MWS. Моя команда внедряет ИИ-скиллы в работу дата-аналитиков. Мы посмотрели на типичный рабочий день и поняли: рутина съедает до 75% времени аналитика. А можно ли это передать ИИ-агенту без потери качества? Эту гипотезу проверили на реальных задачах и получили конкретные результаты — делюсь в этом материале.
Продажа товарного знака — один из способов получить права на уже зарегистрированное обозначение. Такие действия могут потребоваться по ряду причин — слияние компаний, приобретение нового бизнеса и т.д. Разумеется, такой способ приобретения прав имеет свои подводные камни — регистрация договора отчуждения прав, возможно, вопрос встречного удовлетворения в странах общего права. Да и у нас финансовый вопрос тоже может добавить некие сложности — как правильно заполнять бухгалтерские отчеты с учетом подобной сделки. Однако несмотря ни на что, используется он достаточно часто — и при самых разнообразных обстоятельствах. В настоящей статье предложены лишь некоторые случаи покупки товарного знака.
В аналитических командах часто происходит парадокс: чем сильнее эксперт, тем быстрее он решает задачи — и тем меньше пространства остаётся для роста коллег вокруг. Джуниоры привыкают получать готовые решения, запоминают шаблоны SQL и перестают разбираться в причинах ошибок.
Разберём подход «управляемого хаоса», который помогает превратить наставничество из передачи знаний в развитие самостоятельного мышления: через дефицит подсказок, работу с черновыми решениями и разбор собственных решений.
Всем привет!
В своих постах мы часто пишем о разных этапах систем распознавания документов (например, тут и тут). Настало время рассказать о еще одной задаче (и нашем решении для нее), которая часто опускается из подробного рассмотрения.
Наверняка каждый из вас хоть раз клал лист в сканер перевернутым (ну или вы очень везучи). Человек в случае такой оказии может повернуть изображение в редакторе или немного повертеть головой, а что делать системе распознавания?
Просто взять и проигнорировать перевернутые изображения нельзя, ведь при обработке больших объемов данных, например, цифровизации архивов, таких изображений может быть множество. При этом попытки запустить OCR-модели на перевернутых строках обычно заканчиваются плачевно – мы получаем случайные последовательности символов.
Давайте разбираться по порядку!
Когда смотришь на описание нового инструмента, обычно всё выглядит хорошо: список функций, скриншоты, сценарии использования. Но гораздо интереснее посмотреть, что происходит с продуктом после покупки — какие задачи им действительно решают, где он оказывается полезным, а где пользователи упираются в ограничения.
Мы поговорили с тремя командами, которые используют продукты из экосистемы Инфостарт Маркетплейс в повседневной работе:
В 1С ежедневно накапливаются данные о контрагентах, номенклатуре, остатках, продажах, договорах и сотрудниках. Они нужны не только для учета: руководители используют их в дашбордах, аналитики — в BI-системах, а смежные сервисы — для обмена справочниками и показателями.
Сложность начинается в момент, когда данные требуется получить за пределами учетной системы. Иногда достаточно один раз сохранить список в Excel. В других случаях нужна обновляемая таблица или отчет с отборами и группировками. Разберем три способа, доступных без разработки отдельного решения.
Искусственный интеллект уже умеет за считанные минуты собирать дашборды, которые выглядят вполне профессионально. Проблема в том, что убедительный интерфейс легко маскирует слабую постановку задачи и сомнительные выводы. В этой статье — эксперимент с тремя промптами для Claude Design и разбор того, где заканчиваются возможности модели и начинается работа аналитика.
Запрос на дашборд часто начинается со списка показателей и заканчивается красивым отчётом, по которому непонятно, что делать дальше. На примере BI-дашборда для сравнения подразделений разбираю, как перейти от пожеланий к конкретному решению, проверить сопоставимость данных и построить структуру отчёта от отклонения к деталям.
Ниже не попытка восстановить всю работу над проектом по дням, а структура подхода, к которой я пришёл на практике.
Привет, Хабр!
В этой статье разберём ещё один инструмент ClickHouse, который часто используется при обогащении данных и позволяет значительно ускорить выполнение тяжелых SQL-запросов с джоинами.
BI снова хоронят: подключаем LLM к хранилищу и аналитики больше не нужны, деньги тратить на лицензии не нужно. По крайней мере, так выглядит обещание.
На практике дата-агент может написать корректный SQL, получить верные цифры и всё равно уверенно ответить не на тот бизнес-вопрос. Он путается в определениях метрик, теряет права пользователя, дорого ходит по кругу и иногда рассуждает хуже, когда ему дают больше времени.
Я разобрал свежие кейсы OpenAI, Anthropic и Hex: что действительно улучшает ответы, какие очевидные подходы уже провалились, из чего складывается реальная стоимость и как за шесть шагов проверить
Почему «удалить аккаунт» — это плоская проекция, как из неё рождается предметная область цифрового санкционного управления и зачем профессиональным сообществам нужны таксоны, состояния, события и восстановительные маршруты.