Сегодня мы рассмотрим достаточное простое решение, как ограничить доступ к любому вашему дашборду на Суперсете, зная лишь емейл или логин пользователя, без использования стандартных не самых удобных прав пользователя «зашитых» в Superset.
Зачем нужен фреймворк метрик? Общий ответ – для структуризации и порядка в головах бизнеса. В своей работе в разных командах я не раз сталкивалась с желанием стейкхолдеров отслеживать все метрики сразу, хаотично, без четкого понимания, зачем это нужно. А также с последующими попытками расписать и перечислить показатели, которые им кажутся важными, и побежать к аналитикам со срочными запросом всё посчитать и добавить на дашборд. В результате часто получалась монструозная картинка, не позволяющая определиться с фокусами и, как следствие, не удовлетворяющая самих стейкхолдеров.
Ну, а если говорить более профессиональным языком, то система метрик может быть вам нужна в следующих случаях...
Сотни человек из России вложили в эту «надежнейшую американскую инвесткомпанию» суммарно более $30'000'000 – возможно, среди них есть и ваши знакомые. Но со стороны ICN Holding выглядит скорее как пародия на «Волк с Уолл-стрит» от Реутов-ТВ. В этой статье я провожу детективно-финансовое расследование с целью понять – скам это или нет?
Вы знакомы с тем ощущением, когда в чате диалог постепенно превращается в перепалку, аргументы уступают место сарказму, логика — голословным утверждениям, а попытка понять — желанию победить? Мне тоже это знакомо.
Вместо того чтобы просто уйти в игнор или ввязываться в словесную дуэль, я попробовал другой путь. Я взял проверенные временем идеи (Аристотеля, Канта и Хабермаса) и превратил их в промпт «детектор качества диалога».
Получившийся промпт я протестировал с помощью нейросетей — и стал получать объективную обратную связь о том, где заканчивается разумный обмен и начинается флуд.
Если вы тоже устали от бесконечных дискуссий, в которых ничего не решается, — возможно, пришло время не просто спорить, а научиться видеть, когда диалог стоит продолжать, а когда — завершить с достоинством.
Покажу, как философия и нейронки могут помочь разобраться в этом — без лишнего морализаторства, но с ясностью и подробностью.
Это третья статья из цикла «Проектирование GraphQL API».
В предыдущих статьях мы рассмотрели основы GraphQL и принципы проектирования схемы. Теперь перейдем к архитектуре — фундаменту, определяющему, как GraphQL API будет работать в реальных условиях.
Хочу поделиться одной идеей, которая позволяет по-новому взглянуть на проводки бухгалтерского учета. Это может понадобиться тем, кто считает стандартные бухгалтерские отчеты недостаточно наглядными.
Если разложить отслеживание в Яндекс Метрике по уровням сложности, получится три ступени:
Level 1. Цели с параметрами — фиксируем не только факт, но и контекст события.
Level 2. Офлайн-конверсии — подтягиваем в Метрику сделки из CRM и колл-центра.
Level 3. Measurement Protocol и виртуальные визиты — включаем «режим разработчика» и шлём в систему любые события напрямую.
В этой статье рассматриваю только первый уровень статья для новичков, которым уже мало обычных целей и авто-целей, но еще нет желания и потребностей погружаться в глубину.
В отличие от классического подхода, где BI-система жестко фиксирует связи, мы реализовали модель, которая сама определяет, какие таблицы и связи нужны под конкретный дэшлет, и формирует оптимальный запрос «на лету». Это наша новая Адаптивная модель данных Luxms BI.
Я, Николай Павлов, инженер по обработке данных, и в статье мы разберём, как на практике построить такую модель на примере небольшого проекта: поднимем ClickHouse в Docker, создадим схему «снежинка» с тестовыми данными, соберём адаптивную модель и построим дэшборд с экономическими метриками интернет-магазина.
В этой статье расскажем про новую адаптивную модель данных в Luxms BI. Мы реализовали подход, при котором модель сама понимает, какие таблицы и связи нужны под конкретный дэшборд, и строит оптимальный SQL-запрос. Это делает аналитику быстрее, а работу с данными — действительно self-service.
Расскажем как это работает, чем отличается от старого подхода и какие преимущества дает аналитикам и бизнесу.
Самые интересные новости финансов и технологий в России и мире за неделю: миллиардный инвестфонд от 23-летнего AI-щегла, DeepSeek не осилили обучение своей модели на китайских чипах, Маск опять поссорился с Сэмом Альтманом и Apple, Цукерберг учил своих чатботов правильно флиртовать с несовершеннолетними, а еще эфир пробил $4400.
В этой статье я покажу, как провожу UX-аудит: от первого контакта с клиентом до выдачи финальных рекомендаций. Поделюсь своим процессом, инструментами, примерами документов и рефлексией о том, что на самом деле важно в UX-работе.
Как это обычно происходит? Покажу на примере последнего запроса. Пишет мне потенциальный клиент в Телеграм:
— Добрый день, Егор! Подскажите, пожалуйста, ориентировочную стоимость проектирования и аудита интерфейса. Уже есть готовый проект, думаем о редизайне.
На этом этапе моя цель — понять суть задачи и смогу ли я помочь. Дело в том, что разные люди по-разному представляют себе, что такое проектирование и аудит и в результате разговора может выясниться, что они имели в виду что-то, чем я не занимаюсь.
Объясняю в переписке, что всё очень индивидуально и предлагаю время созвона. Моя задача — организовать часовой разговор, во время которого я познакомлюсь с человеком и проектом, а также успею провести экспресс-аудит. Это бесплатно и всегда интересно.
Алгоритмическая торговля на Московской бирже с помощью терминала QUIK остаётся популярным способом автоматизировать стратегии. В этой статье мы напишем грид-бота, который выставляет ордера сеткой вокруг текущей цены и зарабатывает на колебаниях.
Практическое руководство по работе со сложными клиентами — с примерами из нефтегаза, госсектора, бизнеса и стартапов.
Эта статья — концентрированный опыт нашей команды аналитиков из компании Rubius, накопленный за годы работы в заказной разработке. Здесь нет теории из учебников — только проверенные на практике методы общения с «Генералами», «Истериками», «Цезарями» и другими сложными типами заказчиков.
Всем привет! Меня зовут Дима Лунин, я автор курса по экспериментам в Академии Аналитиков Авито. В текущей статье я хочу "обкатать" материал, который мы рассказываем на курсе экспериментов, а также поделиться экспертизой по АБ-тестированию с ребятами, которые только начинают свой путь в аналитике, но уже имеют базовые знания в статистике и в проверке стат. гипотез.
Сегодня данные превратились в один из главных активов бизнеса. От того, как компания их использует, зависит и качество принимаемых решений, и эффективность процессов, и шансы обойти конкурентов.
Эпоха, когда бизнесу достаточно было просто владеть данными, осталась в прошлом. Теперь их нужно интерпретировать, делать легкодоступными, встраивать системы, поддерживающие принятие решений. При этом объемы данных растут, их форматы множатся, а сценарии использования — усложняются.
Чтобы справиться с этим, компании переходят на более гибкие подходы к управлению данными. В этой статье разберем четыре наиболее популярные архитектуры: Data Warehouse, Data Lake, Data Lakehouse и Data Mesh. Обсудим, чем они отличаются и какую выбрать под конкретные задачи.
История ИТ представляет собой череду волн автоматизации, каждая из которых радикально меняла требования рынка и подходы к разработке. Эти волны не просто внедряли новые технологии, они трансформировали бизнес-модели, создавали новые профессии и переопределяли ценность специалистов. Предлагаю ретроспективно взглянуть на сферу ИТ и пофантазировать, что нас ждёт.
Продолжаем изучение по работе с требованиями по Карлу Вигерсу. В этой статье законспектированы разработка (выявление, анализ, документирование, утверждение) и управление требования.
ClickHouse не тормозит, но теряет данные. Набор простых действий с объяснениями, позволяющий избежать потери данных.
При проектировании модели автоматизации бизнес‑процессов проектируются модели самих процессов: вначале концептуальные, затем детализированные, в виде взаимодействий пользователя (или внешней ИТ системы) с проектируемой ИТ системой. Проектируются модели, взаимосвязывающие разные процессы: связывающие по данным — модели логической структуры данных, связывающие по пользовательским интерфейсам — модели переходов между интерфейсами.
Но кроме интерфейсов и данных, нужно взаимосвязать (сделать композицию = обратно от декомпозиции) и сами процессы, так как возникают задачи/проблемы, решение которых этого требуют. Стейкхолдеры не всегда вспоминают задачи/проблемы и можно помочь им, задавая нужные вопросы.
В статье разбирается методика формирования вопросов для обнаружения задач или проблем, возникающих тогда, когда одновременно протекают множество процессов с множеством используемых в процессах ресурсов.
Иногда JSON выглядит рабочим, но под капотом он полон сюрпризов: лишние уровни вложенности, запутанные поля и непонятные даты. Разбираем пример и доводим структуру до ума.