Попытка по-иному ответить на вопрос «какую BI‑систему выбрать»? Вместо сравнения систем сделаем проще — оценим рынок и расскажем о возможностях той системы, которую предпочли топы.
Всем привет. На связи Даша Леонова, product owner и ранее product analyst в международной IT-компании Garage Eight. Недавно я открыла конференцию AHA!25 с докладом об A/B-тестах для опытных аналитиков и продуктовых менеджеров. Делюсь: вышло круто. В статье расскажу о том, как вырастить компетенции аналитика за три этапа, начать проводить эффективные A/B-тесты, и стать партнером для компании, а не рядовым сотрудником.
В эпоху цифровой трансформации данные стали стратегическим активом. Однако их ценность напрямую зависит от качества. По данным Gartner, ежегодные потери компаний из-за плохого качества данных составляют в среднем $15 миллионов. Особенно критично это при внедрении ERP-систем, где данные становятся основой для всех бизнес-процессов.
Меня зовут Настя Неводчикова, я системный аналитик в KODE. В этой статье я хочу поделиться опытом работы с бинарными форматами сериализации, а именно с Protobuf, и рассказать, с какими проблемами мы столкнулись в процессе аналитики и тестирования, а также как их решали.
Исходные условия: у нас было мобильное приложение, написанное на Objective-C (iOS) и Java (Android). Цель — переписать его на современный стек: Swift и Kotlin. Дополнительно нужно было сделать редизайн приложения и обновить бэкенд: поднять Java с 6 до 21. Приложение общалось с бэкендом по HTTP и использовало Protobuf для сериализации данных.
Что важно — никакой документации на существующее приложение не было. У нас была лишь тестовая сборка и сервер с логикой. Поэтому перед стартом разработки нужно было:
В этой статье — история о том, как мы вместе с командой Аналитики цифровых продуктов работали над одной небольшой фичей и в процессе создали собственную альтернативу известной платформе для сбора статистики пользователей сайтов.
Пару слов о нашей команде и о том, чем мы занимаемся. У нас 6 инженеров данных и 5 аналитиков — вместе мы помогаем продуктовым командам (тем, кто развивает сайты и приложения) создавать дашборды и отчёты. Они нужны для того, чтобы коллеги видели, как их изменения влияют на бизнес-метрики и поведение пользователей.
Вторая часть нашей работы — поддержка маркетологов. Мы помогаем им анализировать эффективность продвижения Спортмастера и других наших брендов: где увеличивать бюджеты, где сокращать и как быстро оценивать результат. В общем, мы те, кто превращает данные в понятные решения.
Как появилась задача
Наши пользователи — маркетологи — каждую неделю сталкивались с одной проблемой. По вторникам у них проходят планёрки с руководством, где они разбирают результаты прошлой недели: что сработало, что можно улучшить. Им критично важно к этому времени уже иметь готовый отчёт, чтобы успеть проанализировать данные и принять решения по рекламе.
Однако наш продукт выдавал отчёты только к 16:00. Кому-то хватает часа на подготовку, кому-то трёх, но пользователи жаловались: они просто не успевают осмыслить данные и сформулировать выводы.
Коллеги обратились к нам с запросом: перенести формирование отчетов на 12:00, чтобы оставалось больше времени на анализ. И мы стали думать, как это сделать своими силами без увеличения команды.
Представьте город без карты. Дома построены, улицы проложены, люди живут своей жизнью — но никто не знает, как всё это связано между собой. Каждый архитектор чертит по-своему: у одного — квадраты, у другого — кружки, а у третьего — загадочные стрелки, ведущие в никуда. Когда решения принимаются «на глаз», последствия не заставят себя ждать. В результате, ценные находки теряются в ворохе несогласованных схем. Именно так выглядит ИТ-ландшафт без продуманной системы архитектурных артефактов. Сегодня я расскажу, как мы в МТС наводим в этом хаосе порядок, почему выбрали путь EAoaP — и что сделали, чтобы эта красивая теория прижилась в реальной, живой экосистеме из сотен продуктов.
Привет, Хабр! Меня зовут Наиль Миннахметов и я — корпоративный архитектор в МТС. В прошлом –– разработчик, аналитик и консультант в телекоме, финтехе, eCom, ритейле, логистике, фарме и FMCG. Занимался много чем, но всегда это было связано с IT. Я помогал разным бизнесам расти, становиться надёжнее или зарабатывать больше.
Чуть более 10 лет назад, когда я служил не очень большим, но и не очень маленьким начальником в федеральном министерстве, мне предложили пройти российско-китайскую программу в Китайской академии руководящих кадров Пудун (CELAP) в Шанхае. Ядумал, что это будет очередная командировка с ритуальными поклонами.
Оказалось — нет. Совсем нет.
Если говорить ИТ метафорами, нам дали доступ в бэкенд системы управления Китаем. Представьте себе, что вы — инженер, и вас внезапно пригласили заглянуть внутрь исходного кода ОС, на которой держится страна с населением 1,4 миллиарда.
Таково ощущение от первых дней в Пудуне.
CELAP — не просто академия. Это один из самых закрытых и влиятельных центров подготовки элиты КНР, прямо в подчинении Центрального комитета КПК.
Сюда не попасть по конкурсу или связям — попасть можно только по решению системы. Здесь не просто учат не менеджеров.
Здесь программируют будущих архитекторов государственной политики — тех, кто будет решать, где расти чипам, как развивать ИИ, куда направить триллионы инвестиций. И да, я был там не как турист. Я был — как слушатель. И этот опыт переписал моё понимание того, как можно управлять сложностью в масштабах страны.
В статье рассказывается о создании стратегии для позиционной торговли. Показан опыт разработки инструмента для проверки торговых идей. Описывается реализация стратегии, основанной на принципе «моментума» (когда растущие акции продолжают расти), и её улучшение с помощью оптимизации параметров.
Уходящие с рынка западные BI-решения оставили компании перед сложным выбором. Как найти альтернативу, которая не только заменит функционал, но и позволит масштабировать self-service аналитику на всю организацию? В этой статье делимся реальным кейсом компании t2 (бывший Tele2), которая за два года превратила FineBI в backbone корпоративной аналитики с одной из самых больших инсталляций в России. 400+ разработчиков отчетности, 3500+ общих лицензий, кластерная архитектура и автоматизированное обучение — рассказываем, как это работает на практике.
Меня зовут Елизавета Ковальчук, и моя задача как бизнес-аналитика — быть связующим звеном между бизнес-задачами и технологическими решениями. Я не пишу код для роботов, а создаю для них технические задания — детальные инструкции, которые превращают рутинные операции в автоматизированные процессы. В этой статье я расскажу, как при выборе платформы Primo RPA мы сфокусировались не на быстрой замене, а на создании надежного фундамента для будущей автоматизации, сделав осознанный шаг к построению безопасной среды для автоматизации.
Расследование: отечественные микросхемы в счетчиках электроэнергии – миф или реальность?
13 апреля в канале пользователя @STriple вышла первая разоблачающая публикация о производителях счетчиков, использующих комплектующие зарубежного происхождения, что запрещено законом. Со временем таких статей стало несколько, и каждая из них получала широкий отклик: об этом писали СМИ, обсуждали в блогах и кулуарах на отраслевых тусовках, а Минпромторг инициировал проверки.Мы с замиранием сердца следили за происходящим и были слегка разочарованы тем, что в поле зрения @STriple попало только несколько игроков рынка, тогда как их значительно больше. Быть может у остальных все нормально и дела с импортозамещением не так уж и плохи? Или, наоборот, нам показали лишь вершину айсберга? Мы решили это проверить и приобрели три реестровых счетчика, которые не фигурировали в расследовании нашего незримого коллеги. Продолжим вскрывать этот гнойник, чтобы заражение не разнеслось по всей отрасли.
«Есть ложь, наглая ложь и статистика» — этот афоризм, по утверждению Марка Твена, принадлежит премьер‑министру Великобритании Бенджамину Дизраэли. А по мнению скептиков — самому Твену. Как бы там ни было, статистика не так уж и врёт, по крайней мере не больше, чем машинное обучение (ML). Более того — в некоторых случаях она может оказаться привлекательнее, надёжнее и значительно дешевле, чем обучение и внедрение ML‑моделей.
В этой статье я пропущу очевидные вещи вроде среднего, медианы и моды и сразу перейду к более интересным и полезным инструментам. Примеры и код — на Python, с использованием библиотек numpy, pandas.
Привет, хабражители и коллеги по цифровым джунглям! Сижу тут, владелец скромного, но гордого царства игрушек Akarius, попиваю вечерний чай (ну, ладно, крепкий кофе — отчеты же ждут!). Вспоминаю, как после одного особенно «мощного» прогона Хрумером, я чуть не превратился в того самого озлобленного плюшевого медведя с нашего сайта — глаза квадратные, пальцы в спазме от кликов. Знакомо? Сейчас расскажу не только о том, как автоматизация спасла мой рассудок, но и как она превратила гору цифрового мусора в… золотую жилу для будущих побед! Да‑да, даже из «плохих» отчетов можно извлечь пользу, если знать как.
Сегодня мы рассмотрим достаточное простое решение, как ограничить доступ к любому вашему дашборду на Суперсете, зная лишь емейл или логин пользователя, без использования стандартных не самых удобных прав пользователя «зашитых» в Superset.
Зачем нужен фреймворк метрик? Общий ответ – для структуризации и порядка в головах бизнеса. В своей работе в разных командах я не раз сталкивалась с желанием стейкхолдеров отслеживать все метрики сразу, хаотично, без четкого понимания, зачем это нужно. А также с последующими попытками расписать и перечислить показатели, которые им кажутся важными, и побежать к аналитикам со срочными запросом всё посчитать и добавить на дашборд. В результате часто получалась монструозная картинка, не позволяющая определиться с фокусами и, как следствие, не удовлетворяющая самих стейкхолдеров.
Ну, а если говорить более профессиональным языком, то система метрик может быть вам нужна в следующих случаях...
Сотни человек из России вложили в эту «надежнейшую американскую инвесткомпанию» суммарно более $30'000'000 – возможно, среди них есть и ваши знакомые. Но со стороны ICN Holding выглядит скорее как пародия на «Волк с Уолл-стрит» от Реутов-ТВ. В этой статье я провожу детективно-финансовое расследование с целью понять – скам это или нет?
Вы знакомы с тем ощущением, когда в чате диалог постепенно превращается в перепалку, аргументы уступают место сарказму, логика — голословным утверждениям, а попытка понять — желанию победить? Мне тоже это знакомо.
Вместо того чтобы просто уйти в игнор или ввязываться в словесную дуэль, я попробовал другой путь. Я взял проверенные временем идеи (Аристотеля, Канта и Хабермаса) и превратил их в промпт «детектор качества диалога».
Получившийся промпт я протестировал с помощью нейросетей — и стал получать объективную обратную связь о том, где заканчивается разумный обмен и начинается флуд.
Если вы тоже устали от бесконечных дискуссий, в которых ничего не решается, — возможно, пришло время не просто спорить, а научиться видеть, когда диалог стоит продолжать, а когда — завершить с достоинством.
Покажу, как философия и нейронки могут помочь разобраться в этом — без лишнего морализаторства, но с ясностью и подробностью.
Это третья статья из цикла «Проектирование GraphQL API».
В предыдущих статьях мы рассмотрели основы GraphQL и принципы проектирования схемы. Теперь перейдем к архитектуре — фундаменту, определяющему, как GraphQL API будет работать в реальных условиях.
Хочу поделиться одной идеей, которая позволяет по-новому взглянуть на проводки бухгалтерского учета. Это может понадобиться тем, кто считает стандартные бухгалтерские отчеты недостаточно наглядными.
Если разложить отслеживание в Яндекс Метрике по уровням сложности, получится три ступени:
Level 1. Цели с параметрами — фиксируем не только факт, но и контекст события.
Level 2. Офлайн-конверсии — подтягиваем в Метрику сделки из CRM и колл-центра.
Level 3. Measurement Protocol и виртуальные визиты — включаем «режим разработчика» и шлём в систему любые события напрямую.
В этой статье рассматриваю только первый уровень статья для новичков, которым уже мало обычных целей и авто-целей, но еще нет желания и потребностей погружаться в глубину.