Нассим Талеб назвал книгу Бенуа Мандельброта The (Mis)Behavior of Markets "самой глубокой и реалистичной книгой по финансам, когда-либо опубликованной".
А своего "Черного лебедя" Талеб посвятил "Бенуа Мандельброту, греку среди римлян", что отражает уважение к его роли в развитии идей о сложных системах и неопределённости.
Книга Мандельброта: «(Не)послушные рынки. Фрактальная революция в финансах» (часть 3).
Количество и мощность DDoS-атак ежегодно растут, ставя под угрозу доступность публичных и корпоративных сервисов. Для бизнеса это оборачивается не только прямыми финансовыми потерями, но и серьезным репутационным ущербом.
Инфраструктура Selectel объединяет более 31 000 клиентов, которые генерируют легитимный сетевой трафик объемом свыше 500 Гбит/с. Анализ атак на проекты такого масштаба дает уникальные данные для оценки ландшафта угроз в облачных средах.
Мы в Selectel подготовили аналитический отчет о DDoS-атаках за 2025 год и отдельно рассмотрели показатели за второе полугодие. Эти данные помогают компаниям оценить динамику угроз для облачной инфраструктуры и вовремя скорректировать настройки IT-систем и средств защиты. Какие выводы можно сделать, читайте под катом!
Всем привет! Меня зовут Никита Жарков, я продуктовый аналитик с большим опытом работы в Edtech и банковской сфере. В этой статье я расскажу, как мы построили систему прогнозирования прямо внутри ClickHouse, и покажу, как вы можете сделать подобное у себя. Здесь будет не только история как мы сделали, но и понятный путь, который можно повторить шаг за шагом: от подготовки данных до проверки качества.
Обычно прогнозы строят через внешний стек - выгрузка, Python, отдельные пайплайны. Это нормально, но не всегда удобно, особенно если прогнозы нужны ежедневно и команда хочет держать всё в одном месте. Мы решили использовать встроенные ML‑функции ClickHouse и получить рабочий прогноз без внешней инфраструктуры. В статье разберём, почему это работает, какие признаки нужны, как устроено обучение и как правильно оценить качество результата.
В идеальном мире продуктовый аналитик запускает тест и через три дня получает статзначимый результат. В реальности мы часто видим прогноз: «Для достижения мощности 80% вам нужно крутить этот тест 45 дней». Но математику можно «обмануть» (точнее — оптимизировать), не теряя в качестве выводов.
Каждый продуктовый аналитик или менеджер рано или поздно сталкивается с A/B-тестированием. На первый взгляд всё кажется простым: разделили трафик, показали разные кнопки, сравнили цифры. Но на практике 80% успеха теста закладывается ещё до его старта — на этапе дизайна.
В этой статье мы разберем, что такое «карточка теста», почему это не про картинки и какие 8 пунктов спасут ваш эксперимент от провала.
Нассим Талеб о Бенуа Мандельброте: «Мандельброт занимается серыми лебедями, я занимаюсь чёрным лебедем. Мандельброт одомашнил многих моих чёрных лебедей, но не всех и не полностью. Его методы дают нам проблеск надежды и помогают задуматься о проблемах неопределённости. Если хочешь понять неопределённость — начни с Мандельброта.»
Книга Мандельброта: «(Не)послушные рынки. Фрактальная революция в финансах» (часть 2).
Тема ИИ — это какая-то золотая лихорадка 21 века. Каждый стремится не упустить волну хайпа. ИИ пытаются внедрить везде, где только можно и нельзя.
Одно из популярнейших направлений — разработка. Заменить дорогостоящих разработчиков. Разве может быть что-то более привлекательным?
Да, на первый взгляд, ИИ очень неплохо справляется с этой задачей. Достаточно сформулировать, что тебе нужно, и через несколько секунд портянка кода готова.
Даже появился отдельный термин — вайб-кодинг. Но опасность кроется не в самом ИИ, а в способе его применения из-за непонимания природы.
Для запуска А/В теста необходимым минимумом является фиксация ошибок первого и второго рода, расчет MDE (минимальный наблюдаемый эффект). Однако при расчете результатов теста далеко не всегда получается достичь MDE заданного размера, в таком случае статистическая значимость результатов не будет достигнута. Помимо этого даже при статистически значимом результате существует вероятность ошибки, при которой наши результаты являются выбросом или просто случайностью. Как быть в таком случае?
Есть много статей про успешные трансформации. Но следует отметить, что часто это компании с одним основным бизнесом. У них есть один глобальный продукт и всё строится вокруг него. Это логично, когда ядро, движимое одной целью, развивается и обрастает периферией, особенно если это ядро сформировалось относительно недавно, лет 5-10 назад. Либо еще вариант, когда пишут про успешную трансформацию в одной команде.
Но что происходит у гигантов или в госсекторе? Они развивались по старым правилам, а потом стали расширяться, путём поглощений, создания новых, несвязанных направлений. Когда банк, например, становится не только банком.
Именно у таких компаний часто разворачивается «театр продуктового подхода». Он не улучшает ситуацию, а даже ухудшает. Вместо создания ценности команды учатся играть в метрики и отбывать стендапы.
Осторожно, статья-детектор.
Для меня до сих пор загадка, почему в вакансиях так часто не указывают верхний порог заработной платы, хотя это решило бы сразу целый ворох проблем.
Соискатели не отправляли бы отклики работодателям, которые заведомо не попадают в их зарплатные ожидания. В свою очередь, работодатели не получали бы огромное количество нерелевантных откликов, которые они всё равно не читают, а просто массово фильтруют и отклоняют.
При этом сам процесс найма стал бы чуть более прозрачным. Сейчас кандидат, как правило, не понимает причину отказа, а при наличии вилки по зарплате одной возможной причиной стало бы меньше — при условии, что он откликается на вакансию, подходящую по ЗП.
Я искренне не понимаю, почему в найме считается нормой тратить время соискателя.
Сначала — 30-минутное собеседование с HR. Потом, дай бог через неделю, техническое интервью на 1,5–2 часа. Ещё через неделю — знакомство с командой на час. В сумме выходит около четырёх часов чистого времени, и это не считая ожиданий между этапами.
И даже после последнего раунда ты легко можешь остаться без оффера. Хотя всё шло «как по маслу», просто в какой-то момент нашли кандидата чуть лучше — или такого же, но подешевле.
При этом HR на первом этапе с серьёзным лицом спрашивают: «А нет ли у вас уже оффера на руках?» И в такие моменты хочется ответить честно, но резко: даже если бы оффер и был, вряд ли нормальный работодатель стал бы ждать месяц, пока я пройду все ваши круги ада — если вообще их пройду.
Самое забавное, что такое количество этапов никак не улучшает качество подбора. Более того, на входе легко отсекаются сильные кандидаты — особенно те, кто недавно вышел на рынок и ещё не выучил, что сейчас принято правильно отвечать на собеседованиях.
Дополнительно ситуацию усугубляют длинные паузы между этапами. Кандидат теряет контекст, забывает детали предыдущих разговоров, и если в начале он был мотивирован и заряжен, то спустя пару недель ему становится попросту всё равно — возьмут его или нет.
В этой статье я разберу, почему многоэтапный найм не работает, какие проблемы он создаёт на практике, и в конце предложу альтернативу — как эффективно нанимать разработчиков всего за один этап, без потери качества и здравого смысла.
Всем привет! Меня зовут Ульяна Айкович, я исследователь. И мы продолжаем цикл статей в блоге от продуктовой команды «БКС Мир инвестиций». Сегодня я расскажу, как мы можем глубже анализировать время выполнения заданий, а также, как измерить группы респондентов в немодерируемых UX-тестах. В данной статье я разберу не только медиану и процентили для оценки времени, но и критерий Манна–Уитни — простой способ статистически сравнить две группы респондентов.
Статья будет полезна вам, если вы хотите принимать более обоснованные решения в дизайне и интерфейсе цифрового продукта.
За последние 5 лет в аналитике я прошел путь от «напишу любой джоин на салфетке» до Senior Product Analyst. А еще я менторю ребят и веду телеграм канал.
В этой статье не будет универсальной таблетки (её нет, я на обучении трачу недели, чтобы поставить людям голову на место), но я поделюсь своей системой, как не превратить решение кейса в гадание на кофейной гуще.
На ранних этапах разработки аналитика часто оказывается в тени функциональных требований: фича работает — значит, задача выполнена. Корректность событий, логика их отправки и влияние на будущие отчеты нередко проверяют только после релиза — если вообще доходят до этой проверки. Но аналитика — это полноценный продуктовый инструмент. Именно на результатах аналитики строят гипотезы, запускают A/B-эксперименты и принимают бизнес-решения.
В этой статье Андрей Смирнов, инженер по тестированию Циан, раскроет, почему аналитика — это не «дополнение», а часть фичи, какую роль в ней играет тестировщик, а также как ревью аналитики повлияло на процессы и качество решений в нашей команде. Статья отражает опыт взаимодействия QA и аналитика внутри нашей продуктовой команды.
Проводить нагрузочное тестирование PostgreSQL — полдела. Главная сложность начинается, когда нужно проанализировать сотни результатов и понять, где реальная просадка производительности, а где статистический шум. Младшие специалисты Postgres Professional Евгений Бузюркин, Дарья Барсукова и Рустам Хамидуллин разработали инструмент, который автоматически определяет тип распределения данных, детектирует мультимодальность и подбирает оптимальные параметры для каждого набора результатов бенчмарков.
Современное машиностроительное производство требует высокой точности планирования технологических процессов и оценки трудоёмкости операций. Эти оценки напрямую влияют на формирование себестоимости, планирование загрузки оборудования и назначение цен на продукцию и услуги.
В последние годы руководители IT-подразделений всё чаще рассматривают методы анализа данных и машинного обучения как универсальный инструмент, способный «автоматически» решить задачу расчёта норм времени. Иногда — с избыточным оптимизмом. Часто при этом забывается простая, но важная мысль: если существующий процесс расчёта неточен и данные в нём некачественные, то автоматизация такого процесса лишь ускоряет распространение ошибок. Особенно если применять вероятностные модели к накопленным за годы «грязным» данным.
Именно с такой реальностью нам (мне и коллегам) и пришлось столкнуться.
Всем привет! На связи Ульяна Айкович и Даниил Гурин — исследователи «БКС Мир инвестиций». Сегодня мы хотим поделиться результатами нашего небольшого, но довольно смелого эксперимента — попытки предсказать конверсию в прохождение опросов.
Каждый исследователь знает, как трудно удержать внимание респондентов. Особенно в опросах. Один лишний вопрос, одна лишняя картинка в анкете или лишняя минута времени для заполнения опроса — и человек закрывает вкладку. А ведь каждый ответ на вес золота. Поэтому мы решили разобраться: что именно определяет, дойдет ли человек до конца опроса или бросит его на полпути? Можем ли мы заранее это предсказать?
В статье более подробно рассказали о первой итерации нашего эксперимента!
Как не потеряться в сотнях графиков и найти реальные рычаги влияния на бизнес? В статье представлен подробный разбор Дерева метрик на примере FoodTech-сервиса (доставки еды). Мы уходим от простого мониторинга цифр к системной декомпозиции North Star Metric.
Современный мир переживает бум развития технологий искусственного интеллекта, помимо чат-ботов, сервисов генерации изображений и т.п. Искусственный интеллект (ИИ) применяется в беспилотных автомобилях, которые уже сейчас ездят по дорогам общего пользования. Это пример того, как ИИ управляет техническим средством, а именно, считывает данные с лидаров и видеокамер и т.п., анализирует их и формирует команды для задания направления и скорости движения автомобиля. На первый взгляд, это мало чем принципиально отличается от управления технологическим оборудованием на промышленных предприятиях. Почему же в современных АСУ ТП не применяют ИИ для формирования управляющих воздействий на исполнительные механизмы?
Как часто бизнес задает вопрос о результатах A/B-теста уже на второй день после запуска? В классической статистике основной ответ: необходимо ждать набора фиксированной выборки, иначе риск ложноположительного результата становится неконтролируемым. Однако современные подходы позволяют не только проводить мониторинг данных без риска математической ошибки, но и останавливать эксперименты значительно раньше срока. В основе такой гибкости лежит методология mSPRT, которая превращает эксперимент из закрытого процесса в прозрачный поток данных.
Вместо пассивного ожидания можно использовать концепцию доверительных последовательностей и всегда валидных p-значений. Эти инструменты сохраняют свою математическую силу независимо от того, как часто проверяются промежуточные итоги. Ключевую роль в настройке системы играет параметр смешивания тау, который помогает найти тонкий баланс между чувствительностью к минимальным изменениям и скоростью получения итогового результата.
Работа с реальным трафиком требует адаптации теории к специфике бизнеса. В статье разбирается, как метод линеаризации помогает применять последовательный анализ к сложным показателям вроде конверсии или среднего дохода на пользователя. Также рассматриваются ситуации, когда стандартная математика может давать сбои из-за экстремальных выбросов с тяжелыми хвостами распределения или изменения характеристик трафика во времени. Чтобы исключить ложные срабатывания, вводится система защитных механизмов, которая делает выводы устойчивыми к случайному шуму.
Такой метод позволяет сократить время проведения тестов на 30-50%, не жертвуя при этом достоверностью. Это способ сделать процесс проверки гипотез более гибким и быстрым, сохраняя безупречную математическую строгость в каждой точке принятия решения.
