Как создать аналитическое приложение
В качестве примеров аналитических приложений, расположенных на вершине "аналитической пирамиды" рассмотрим:
- системы, реализующие методологию сбалансированных систем показателей ( BSC -системы);
- системы корпоративного планирования и бюджетирования;
- системы формирования и анализа консолидированной финансовой отчетности;
- BI -приложения и другие аналитические приложения.
BSC -системы, системы корпоративного планирования и бюджетирования и системы консолидации финансовой отчетности представляют собой три основных типа аналитических приложений корпоративного уровня, входящие в состав комплексных систем управления эффективностью бизнеса ( Business Performance Management , BPM ). В то же время имеется довольно большое количество систем, которые по своей сути также являются аналитическими, хотя и применяются не столь масштабно - для решения отдельных, иногда специфических задач.
Системы управления эффективностью бизнеса (BPM-системы)
Сущность концепции BPM
90-е годы прошлого века ознаменовались интенсивным развитием аналитических систем, включая BI -системы и аналитические приложения. На определенном этапе была признана необходимость их интеграции - и методологической (функциональной), и технологической. Так появилось новое направление, получившее название Business Performance Management ( BPM ) , что на русский язык обычно переводится как "управление эффективностью бизнеса" (хотя такой перевод представляется не вполне корректным). В общих чертах, BPM - это целостный, процессно-ориентированный подход к принятию управленческих решений, направленный на улучшение способности компании оценивать свое состояние и управлять эффективностью своей деятельности на всех уровнях, путем объединения собственников, менеджеров, персонала и внешних контрагентов в рамках общей интегрированной среды управления [50].
Приведем определение, разработанное группой по стандартизации BPM .
Business Performance Management (BPM) - это методология, направленная на оптимизацию реализации стратегии и состоящая из набора интегрированных циклических аналитических процессов, которые поддерживаются соответствующими технологиями и имеют отношение как к финансовой, так и к операционной информации. BPM позволяет предприятию определять, измерять и управлять эффективностью своей деятельности, направленной на достижение стратегических целей. Ключевые финансовые и операционные процессы BPM включают планирование, консолидацию и отчетность, анализ ключевых показателей эффективности и их распространение в рамках организации [51].
Заметим, что, как и в случае с термином ERP , понятие " BPM -система" может употребляться в двух значениях: как концепция управления (определенный подход к принятию управленческих решений и их практической реализации) и как информационная система (комплекс программных и технических средств, поддерживающих идеологию BPM и обеспечивающих ее практическую реализацию).
К сожалению, сложилось так, что разные организации (включая аналитиков рынка и разработчиков программного обеспечения) стали использовать разные термины для обозначения одного и того же понятия. Сегодня в литературе можно встретить, как минимум, четыре различные аббревиатуры:
- управление эффективностью бизнеса (Business Performance Management , BPM );
- управление эффективностью деятельности предприятия (Enterprise Performance Management , EPM );
- управление эффективностью деятельности корпорации (Corporate Performance Management , CPM );
- стратегическое управление предприятием (Strategic Enterprise Management , SEM ).
Также нельзя не отметить досадное совпадение: аббревиатура BPM имеет и другую расшифровку - Business Process Management (управление бизнес-процессами). Этот термин используется, в частности, компанией IDS Scheer - одним из мировых лидеров в области управления бизнес-процессами и разработки соответствующего программного обеспечения.
Так или иначе, несмотря на некоторые терминологические проблемы, понятие BPM уже завоевало себе право на жизнь и признано как специалистами в области управления, так и ведущими компаниями - аналитиками рынка информационных технологий. По сути дела, концепция BPM превратилась в самостоятельное направление, имеющее не только определенную теоретическую идею, но и методики и технологии ее практической реализации.
Функциональность BPM-систем
В соответствии с документом, разработанным Группой по стандартизации BPM , в качестве основных процессов, охватываемых BPM -системами, можно выделить следующие [51].
- формализация стратегии ( strategize );
- планирование ( plan );
- мониторинг и анализ ( monitor and analyze );
- корректирующие воздействия ( take corrective actions ).
В части формализации стратегии BPM -системы позволяют менеджерам разрабатывать стратегии и доводить их до подразделений компании, выявлять возможности создания стоимости и формировать системы метрик, позволяющих оценивать эффективность бизнеса и ее динамику.
В части планирования BPM -системы позволяют менеджерам всех подразделений компании устанавливать свои локальные цели, разрабатывать и моделировать сценарии планирования, разрабатывать программы и бюджеты, поддерживающие бизнес-стратегию, а также формировать целевые значения определенных показателей для различных временных периодов.
В части мониторинга и анализа BPM -системы позволяют оценивать индивидуальную и групповую эффективность с применением соответствующих ключевых показателей на всех организационных уровнях, а также предоставляют пользователям дополнительную информацию, помогающую им предпринимать те или иные действия.
В части корректирующих воздействий BPM -системы помогают менеджерам своевременно реагировать на возникающие ситуации и отклонения.
Приведенная классификация построена в соответствии с циклом стратегического управления: первые две группы процессов связаны с формированием и реализацией стратегий (целеполагание и трансформация стратегий в планы), вторые две группы - с обеспечением обратной связи (контроль, корректировка целей и планов). В этом отношении классификация достаточно детально отражает структуру функциональных областей BPM . Однако, с другой стороны, она вряд ли подходит для классификации информационных систем, обеспечивающих перечисленные функции. Дело в том, что конкретные программные продукты, как правило, реализуют не одну, а сразу несколько ключевых функций, относящихся к разным функциональным областям и используемых на разных стадиях цикла стратегического управления.
Например, информационные системы, поддерживающие разработанную Р. Капланом и Д. Нортоном методологию Balanced Scorecard [52], часто называемые BSC -системами, позволяют структурировать стратегические цели организации, формировать системы ключевых показателей (как финансовых, так и нефинансовых), декомпозировать эти показатели вплоть до нижнего уровня управленческой пирамиды, а затем - осуществлять мониторинг достижения целей и строить на этой основе корпоративную систему мотивации, обеспечивающую координацию усилий отдельных подразделений и бизнес-единиц. Таким образом, BSC -системы включают в себя все компоненты раздела "формализация стратегии". В то же время совокупность индикаторов дает менеджерам возможность оценить, насколько успешно компания продвигается в заданном направлении и насколько его текущая деятельность соответствует утвержденной стратегии. Эти функции соответствуют разделу "мониторинг и анализ". Наконец, BSC -системы позволяют создавать уведомления и поддерживают процессы корректировки целей, что соответствует разделу "корректирующие воздействия".
Аналогичные рассуждения применимы и к системам корпоративного планирования и бюджетирования. Прежде всего, такие приложения содержат всю необходимую для планирования функциональность, включая ведение аналитических направлений и классификаторов , описание финансовой структуры и принципов взаимодействия, учет трендов , анализ отклонений и т.п. Такие системы учитывают потребности крупных организаций, позволяя составлять бюджеты для каждой бизнес-единицы и для каждого из структурных подразделений, при этом консолидация информации может осуществляться на любом из уровней организационной структуры [53]. Перечисленные функции представляют раздел "планирование". Кроме того, системы планирования и бюджетирования позволяют производить план-факт анализ на основе информации из транс-акционных систем (раздел "мониторинг и анализ"), а также осуществлять корректировку планов и бюджетов (раздел "корректирующие воздействия"). Наконец, современные системы этого класса обладают развитой функциональностью в области организации бюджетного процесса, что дает возможность координировать усилия специалистов разных подразделений, обеспечивая тем самым коллегиальность стратегического управления (функциональность раздела "формализация стратегии").
В то же время существуют приложения, возможности которых относятся всего лишь к одной из функциональных компонент, приведенных в классификации. Примером могут служить системы консолидации финансовой отчетности, функциональность которых относится к одной из компонент раздела "мониторинг и анализ". Такие системы позволяют организовать сбор финансовой отчетности всех организаций, входящих в состав группы, обеспечить процедуры консолидации в соответствии с национальными или международными стандартами и в результате сформировать полный комплект консолидированной финансовой отчетности.
Таким образом, концепция управления эффективностью бизнеса может применяться для предприятий и организаций самых разных отраслей, включая организации социальной сферы. Эта концепция имеет непосредственное отношение к стратегическому менеджменту, поскольку она предусматривает целый ряд важных управленческих функций, включая формализацию стратегии и определение ключевых показателей, планирование, мониторинг и анализ, а также обеспечение необходимой обратной связи и корректирующие воздействия. С другой стороны, концепция BPM тесно связана с задачами корпоративного управления, позволяя обеспечить информационную прозрачность организации для заинтересованных лиц, в частности, путем формирования и представления корпоративной отчетности.
Управление по ключевым показателям
Balanced Scorecard и другие методики управления по ключевым показателям
Развитие теории управления привело к появлению методологии сбалансированных систем показателей ( Balanced Scorecard, BSC ), которую ее создатели, Р. Каплан и Д. Нортон, определяют как инструмент, позволяющий трансформировать миссию и стратегию организации в исчерпывающий набор показателей эффективности, которые служат основой для системы стратегического управления и контроля [52]. Именно эта теория на сегодняшний день получила всеобщее признание и, несмотря на наличие целого ряда аналогичных методик, все чаще воспринимается как "стандарт де-факто".
Возникновение Balanced Scorecard относится к началу 90-х годов, когда был разработан новый подход к оценке результативности деятельности компании, позволяющий преодолеть ограниченность традиционных методов. Важным новшеством стало то, что набор измеряемых показателей, по которым оценивалось предприятие, был расширен, и в него, помимо привычных финансовых показателей, были включены нефинансовые параметры - сведения о клиентах, внутренних процессах, обучении и развитии. Кроме того, вместо ретроспективных показателей в процессе анализа стали учитываться и "опережающие индикаторы", позволяющие оценивать состояние компании с учетом перспектив в будущем.
Дальнейшее развитие методологии Balanced Scorecard характеризуется переходом от простой оценки показателей эффективности к управлению стратегическим развитием компании. Для этого Капланом и Нортоном была разработана карта стратегии ( strategy map ), которая дает визуализированное представление стратегии в виде стратегических целей, показателей и причинно-следственных связей.
В карте стратегии Каплана и Нортона выделяются четыре аспекта (перспективы):
- финансы (финансовое положение и финансовые результаты деятельности);
- клиенты (то, как предприятие выглядит с точки зрения своих клиентов);
- внутренние процессы (ключевые процессы, в значительной мере определяющие эффективность деятельности компании);
- обучение и рост (наиболее важные элементы культуры, технологии и навыков персонала предприятия).
Связующим звеном между четырьмя перечисленными перспективами служат причинно-следственные связи ( cause and effect linkages ). Известно, что любая организация представляет собой сложный организм, и изменение в какой-то одной области практически неизбежно влечет за собой изменения в нескольких других областях.
Перечисленные перспективы включают в себя цели ( objectives ), связанные между собой причинно-следственными связями. Цели - это ориентиры, характеризующие желаемое состояние организации в будущем. Можно сказать, что именно цели определяют то, как стратегия будет трансформирована на операционный уровень. При этом различные цели и группы целей закрепляются за конкретными уровнями менеджмента, определяющими их достижение. Отметим, что для целей организации, так же как и для перспектив, характерно наличие причинно-следственных связей: действия, направленные на достижение одной цели, способствуют (а иногда и препятствуют) достижению других целей.
Наконец, необходимым элементом Balanced Scorecard являются стратегические инициативы ( strategic initiatives ), представляющие собой конкретные действия и/или программы действий по реализации стратегии и достижению стратегических целей. По сути дела, стратегические инициативы - это перечень усилий, которые следует предпринять для достижения стратегического результата. Иначе говоря, стратегические инициативы представляют собой не что иное, как тактические мероприятия, позволяющие реализовать стратегию.
В результате детализации и описания зависимостей определяются целевые показатели, характеризующие успехи (или неудачи) в тех или иных стратегических областях. Как правило, количество таких параметров не должно превышать двух-трех десятков, что дает возможность контролировать их взаимосвязь. При этом часто приходится констатировать конфликт целевых показателей: например, задача снижения затрат вступает в противоречие с задачей поддержания необходимого квалификационного уровня сотрудников, поскольку программы повышения квалификации не бесплатны. В таких случаях от руководителей компании требуется найти некоторую "золотую середину", не противоречащую стратегическим целям компании. В результате такого анализа и формируется Balanced Scorecard - сбалансированная система показателей.
Таким образом, при помощи набора "стратегические перспективы - цели - измерители - целевые показатели - стратегические инициативы" система Balanced Scorecard позволяет выстроить сквозную связь между стратегией и тактикой организации, в результате чего задача трансформации стратегии в реальные действия оказывается решена. Кроме того, такая система позволяет не только формализовать стратегию, но и контролировать успешность ее реализации за счет измерителей и значений целевых показателей.
Balanced Scorecard по праву можно назвать наиболее популярной среди методик стратегического управления. Но это не означает отсутствия других методов и подходов, многие из которых также получили достаточно широкое распространение и признание. Примерами таких разработок могут служить методика управления стоимостью компании ( Value Based Management, VBM ), а также методика tableau de bord, разработанная и получившая распространение во Франции.
Фундаментом аналитики является сбор данных. Настройка аналитики мобильного приложения включает в себя интеграцию SDK системы аналитики в мобильное приложение, проектирование структуры ивентов и их расстановку внутри приложения. Неправильно настроенный сбор данных для аналитики оставит вас без приборов в работе с вашим продуктом, либо же обеспечит неверными данными, что, с моей точки зрения, еще хуже, чем отсутствие данных.
В этой статье я расскажу о том:
- Какие ошибки часто допускают при настройке аналитики мобильных приложений
- Как я обычно подхожу к процессу встраивания аналитики в мобильное приложение
- Также я поделюсь некоторыми хаками и секретами, которые позволят вам эффективнее использовать ваши данные
Внутренняя аналитика мобильных приложений или зачем нужны ивенты
Аналитика мобильных приложений обычно строится на ивентах. Вы шлете в систему аналитики ивенты (события), а система предоставляет интерфейс для работы с этими данными.
Ивент – любое действие, которое совершает пользователь (клик на кнопку, открытие определенного экрана, добавление комментария, трата или покупка внутренней валюты). Когда происходит это событие, то приложение отправляет ивент на сервера системы аналитики. Вместе с ивентами обычно передаются ряд обязательных параметров (индификатор пользователя, версия приложения, модель девайса, прочие служебные параметры), а также ряд дополнительных кастомных параметров, которые вы определяете сами (например, количество дней с момента начала использования приложения, кол-во запусков приложения и тд).
По сравнению с стандартными для веба системами аналитики (Яндекс Метрика или Google Analytics) описанный подход оказывается более затратным на этапе встраивания и настройки системы аналитики, но зато позволяет отвечать на существенно большее количество вопросов.
Ошибки при настройке аналитики в мобильном приложении
Обычно проектированию структуры ивентов и настройке аналитики уделяется мало времени и внимания при разработке мобильных приложений. Неправильно или некачественно настроенная аналитика сильно осложняет последующую работу с продуктом, а порой оставляет полет вашего продукта без каких-либо навигационных приборов.
Я заметил следующие распространенные ошибки при настройке аналитики:
1) Настройка аналитики откладывается до последнего момента. Но перед релизом и помимо аналитики (которая в этот момент не кажется особо важной частью) образуется большой стек всевозможных задач. В итоге времени на продумывание того, какие данные следует собирать и зачем, не остается.
2) Иногда ивентами завешивают каждый элемент и каждое действие в приложении, безотносительно полезности и применимости этой информации. Такой подход тоже опасен, так как появляется куча ненужных данных, а их структура далеко не всегда подходит для последующей работы с ними.
3) Случается и другая крайность. Ивенты вешают только на наиболее важные места в приложении (по мнению команды на момент релиза), а потом оказывается, что собираемые данные не позволяют получить ответы на ключевые вопросы.
Если более глобально, то все описанные ошибки произрастают из неправильного направления движения мысли при настройке аналитики. Аналитика призвана отвечать на вопросы, поэтому логично сначала сформулировать набор интересующих вопросов, а потом на их основе сформировать структуру ивентов, которые позволят на эти вопросы ответить, а не наоборот.
Настройка аналитики мобильного приложения. Алгоритм.
Шаг 1. Что хотим знать
Сначала необходимо определиться с тем, на какие вопросы вы хотите найти ответы с помощью собираемых данных, какие гипотезы вы хотите доказать или опровергнуть. Представьте, что приложение уже запущено, и пришло время провести анализ. Что вы захотите узнать, что проверить?
Чтобы не потерять важные вопросы, я рекомендую использовать следующий подход. Выпишите основные сценарии использования вашего приложения, а затем представляя, как пользователь проходит через них, задавайте интересующие вас вопросы.
Финальный список вопросов обычно состоит из стандартной части, которая подходит почти для любого приложения, а также из вопросов специфичных для данного конкретного приложения.
Стандартная часть обычно выглядит примерно так:
- Где люди отваливаются на туториале?
- Насколько туториал эффективен (какая часть пользователей обучились по его итогам, а не просто прокликали его)?
- Сколько людей продолжают использовать приложение спустя 1, 7 , 14 дней
- Какая доля новых пользователей заходят в магазин (или видят продающий экран)?
- Какова конверсия в покупку? в повторую покупку?
- Сколько стоит привлеченный пользователь?
- Сколько мы зарабатываем с пользователя на 1, 7, 14, 30 день?
- Как отличаются ответы на предыдущие вопросы в зависимости от платформы, страны, источника трафика, типа девайса?
После самостоятельного составления списка вопросов имеет смысл спросить других участников команды о том, что им интересно узнать про то, как пользователи взаимодействуют с продуктом. Если пропустить эту часть, то может получиться, например, что вы включили в список ключевые вопросы по геймдизайну, но вопросы про интерфейсные решения остались вне вашего внимания.
Итогом этого шага является список вопросов, который представляет собой структуру исследования приложения.
Шаг 2. Какие ивенты и с какими параметрами нужны, чтобы ответить на вопросы из шага 1
Теперь у вас есть понимание того, что конкретно вы хотите знать, поэтому можно переходить к проектированию структуры ивентов и их параметров. Подойдите к этому процессу итеративно. Быстро составьте первую версию списка ивентов и переходите к следующему пункту. К этому пункту вы еще вернетесь.
Шаг 3. Позволит ли используемая система аналитики ответить на вопросы из шага 1 со структурой ивентов из шага 2?
Дело в том, что разные системы аналитики обладают разным функционалом, разными возможностями и разными ограничениями, и все эти особенности надо учитывать еще на этапе встраивания аналитики в приложение. Особенности вашей системы аналитики вам, скорее всего, хорошо знакомы, но я все-таки приведу несколько примеров, чтобы было понятнее, о чем идет речь.
Во Flurry есть ограничение на количество параметров, которые можно передавать с ивентом (не более 10 параметров у конкретного ивента). Поэтому при создании структуры ивентов и параметров вам надо держать эту особенность в голове. В Kontagent параметров ивентов по сути нет (подробнее тут), поэтому всю содержательную информацию придется поместить в название ивента.
Во Flurry при составлении воронок нельзя указывать параметры ивентов. Поэтому если вы захотите построить воронку движения пользователя по уровням в вашей игре, то придется для каждого уровня заводить отдельный ивент. Несмотря на то, что удобным и логичными кажется заведение специального ивента, отправляемого при прохождении уровня с параметром level_number, в случае если вы хотите иметь воронку прохождения игры по уровням и при этом используете Flurry, это решение вам не подойдет.
Если вы используете Mixpanel и хотите интегрировать его с AppsFlyer (система для определения источников трафика), чтобы в Mixpanel знать, откуда пришел пользователь, то вам надо будет делать параметр источника трафика глобальным (то есть передавать его со всеми ивентами). В противном случае вы, например, не будете знать о том, пользователю из какого источника трафика принадлежит покупка, а значит не сможете посчитать LTV для разных каналов трафика.
Таких особенностей систем аналитики много, и думать о них следует на этапе настройки аналитики приложения. Если оказалось, что текущая структура ивентов и параметров не закрывает ваши вопросы с помощью используемой у вас системы аналитики, то вернитесь к шагу 2 и переделайте структуру ивентов.
Шаг 4. Еще раз пройдитесь по предыдущим пунктам
Спустя некоторое время имеет смысл еще раз пройтись по получившемуся списку вопросов и структуре ивентов, чтобы добавить туда то, что было упущено (а такое есть почти всегда), а также, чтобы оптимизировать структуру ивентов для упрощения последующей работы с данными.
Шаг 5. Встройте аналитику в приложение
На этом этапе максимально детально объясните разработчикам суть каждого ивента и параметра. Расскажите, когда и при каких условиях каждый конкретный ивент должен отправляться, для чего он нужен, и что с его помощью вы хотите понять/узнать/проверить.
Осмысленное встраивание аналитики окупается экономией времени на следующем шаге.
Шаг 6. Протестируйте статистику перед релизом
Но чтобы быть до конца уверенным в том, что все работает правильно, я рекомендую использовать следующий подход. Выгрузите собственную сессию использования приложения в виде последовательности ивентов во времени. Затем проверьте, что все ивенты приходят в нужный момент, и что все параметры изменяются в соответствии с заложенной вами логикой.
В системе аналитики Mixpanel это делать очень удобно благодаря инструменту Live view (инструмент позволяет видеть и фильтровать приходящие ивенты в режиме реального времени). Ты что-то делаешь в тестовой версии приложения и сразу же видишь ивенты, которые от тебя приходят в систему аналитики.
Я рекомендую очень внимательно проверять мобильную аналитику, как минимум по двум причинам:
Описанный выше алгоритм настройки аналитики мобильного приложения из шести шагов может показаться достаточно сложным, но в реальности все просто и понятно. Если все описанное выше поместить в одно предложение, то получится следующее: заранее подумайте о том, что вы хотите узнать из собираемых данных, и заранее убедитесь, что ваша система аналитики способна дать вам это знание при имеющейся структуре ивентов.
Полезные хаки при настройке аналитики в мобильном приложении
Глобальные параметры
Глобальные параметры обычно характеризуют пользователя, а не само действие, к которому прикреплен ивент. В список глобальных параметров я почти всегда вношу следующие параметры:
1) номер недели или дня, когда пользователь пришел в игру (для последующего выделения когорт)
2) источник трафика
3) уровень игрока
4) количество покупок
5) кол-во пройденных уровней в игре
Пишите статистику как минимум в две системы аналитики
Даже при внимательной проверке статистики на этапе тестирования, все равно случаются ошибки, поэтому лучше писать данные как минимум в две системы, чтобы иметь возможность проверять их достоверность. В качестве запасной системы аналитики удобно использовать Flurry.
Проверяйте покупки на сервере перед тем, как писать их в статистику
Если вы хотите использовать вашу систему аналитики для работы с финансовыми данными, то обязательно делайте серверную валидацию платежей перед тем, как писать ивенты покупки в статистику. В противном случае читеры испортят все ваши данные.
Как хранить структуру ивентов
Для хранения и ведения структуры ивентов хорошо подходит Excel файл. Заводите новую вкладку на каждую версию приложения и отмечайте цветом ивенты, которые добавились в соответствующей версии приложения. Так вы всегда будете знать, когда и какие изменения вносились в структуру ивентов.
Как называть ивенты
Чтобы не путаться в названиях ивентов, их удобно называть по принципу ЭКРАН_ЭЛЕМЕНТ_ДЕЙСТВИЕ. Например, старт уровня будет называться LEVSCR_LEVEL_STARTED, а покупка в магазине SHOP_ITEM_PURCHASED.
Для некоторых сущностей такая структура не подходит, тогда можно вводить сквозные ивенты, которые не привязаны ни к какому экрану, а отвечают, например, за трекинг внутренней экономики. Такие ивенты можно назвать ECONOMICS_CURRENCY_SPENT и ECONOMICS_CURRENCY_GAINED, а в качестве параметров передавать method (на что потратил) и value (сколько потратил).
В заключении
И еще раз суть статьи в одном предложении. Заранее подумайте о том, что вы хотите узнать из собираемых данных, и заранее убедитесь, что ваша система аналитики способна дать вам это знание при имеющейся структуре ивентов.
Если у вас есть свои хаки встраивания аналитики в приложения, то поделитесь ими в комментариях. Спасибо.
Эссе и образовательные симуляторы про продакт-менеджмент, продуктовую аналитику, маркетинг и рост
Недавно посмотрел курс IBM по визуализации данных с использованием Python. Интерес вызвал раздел “построение дэшбордов”. В разделе перечислены как уже знакомые библиотеки Bokeh, Dash, так и незнакомые Streamlit, Panel. Библиотека Dash предоставляет богатый функционал для построения интерактивных отчетов или веб-приложений. К сожалению, в community версии нет возможности использовать часть тем. Возможности развернуть свой отчет на серверах Dash также нет.
Изменение интереса к библиотекам во времени
Streamlit – библиотека с открытым исходным кодом для языка программирования Python. На странице библиотеки разработчики обещают простой API, полностью бесплатную функциональность, а также быстрое и бесплатное развертывание на серверах.
Библиотека предоставляет собой декларативный подход к написанию веб-приложений. Напомню, что программисты разделяют два основных подхода к разработке: императивный и декларативный. Первый подход как решить задачу и описывает шаги для достижения результата. Декларативный подход противоположен, в нем указывается что вы хотите.
Большое преимущество Streamlight, в том, что вам не нужно писать backend, подключать frontend или писать на HTML, CSS или JS для красивой верстки вашего проекта.
К примеру, чтобы сделать форму, в которой будет содержаться текст и график, вам понадобится всего 5 строчек кода:
И запуск веб-приложения в командной строке:
Приятные аспекты разработки с использованием данной библиотеки:
- Поддержка популярных библиотек, таких как Pandas, Matplotlib, Seaborn, Plotly, Bokeh, Altair, Folium;
- Поддержка языков разметки Markdown, Latex;
- Возможность добавлять интерактивные виджеты: слайдеры, выпадающие списки одной строкой;
- Галерея приложений, разработанных с использованием этой библиотеки, в различных областях;
- Быстрая поддержка;
- Быстрое и понятное развертывание на серверах разработчиков.
Что не понравилось:
- В документации содержалось мало примеров;
- Плохая адаптивная верстка у Plotly и Bokeh.
Примеры реализованных приложений
Для освоения библиотеки реализовано два простых веб-приложения. Первое реализует функции математической морфологии.
- Загрузка своего изображения;
- Операции эрозии, дилатации, вскрытия и закрытия;
- Показ изображения до и после обработки;
- Визуализация гистограмм изображений.
- Можно выбрать оси;
- Выбор функции агрегирования;
- Выбор метода интерполяции.
Развертывать приложения я решил на хостинге от streamlit. Для размещения приложения на серверах streamlit достаточно выполнить простые шаги, указанные в документации.
Вывод: библиотека Streamlit подходит для быстрой разработки и развертывания веб-приложений. На текущий момент библиотека имеет не более 10 интерактивных виджетов. Однако с их помощью можно создать действительно интересные программы. Подборку таких программ можно найти на официальном сайте библиотеки. Рекомендую ознакомится с библиотекой, она поможет в быстром создании веб-приложений.
Аналитические мини-приложения используют запросы Transact-SQL (T-SQL), выполняемые для мониторинга серверов и баз данных, и преобразуют их в содержательные визуализации.
Аналитические сведения представлены в виде настраиваемых диаграмм и графиков, добавляемых на панели мониторинга серверов и баз данных. Быстро просматривайте данные о серверах и базах данных, открывайте детализированные представления и выполняйте необходимые действия по управлению.
Создавайте потрясающие панели мониторинга для управления серверами и базами данных, аналогичные приведенным в следующем примере.
Чтобы приступить к созданию различных типов аналитических мини-приложений, ознакомьтесь со следующими руководствами:
Запросы SQL
Чтобы не добавлять дополнительные языки или сложные пользовательские интерфейсы в Azure Data Studio, здесь максимально активно используется T-SQL с минимальной конфигурацией JSON. При настройке аналитических мини-приложений с помощью T-SQL задействуется бесчисленное количество существующих источников полезных запросов T-SQL, которые можно преобразовать в информативные представления.
Аналитические мини-приложения состоят из одного или двух запросов T-SQL.
- Запрос аналитического мини-приложения является обязательным и возвращает данные, отображаемые в мини-приложении.
- Запрос подробных аналитических сведений является обязательным только при создании страницы подробных аналитических сведений.
Запрос аналитического мини-приложения определяет набор данных, позволяющий отображать количество, диаграмму или график. Запрос подробных аналитических сведений используется для вывода соответствующих подробных аналитических сведений в табличном формате на панели аналитических данных.
Azure Data Studio выполняет запросы аналитического мини-приложения и сопоставляет результирующий набор запроса с набором данных диаграммы, а затем показывает его. Когда пользователи открывают подробные аналитические сведения, выполняется соответствующий запрос с выводом результата в представлении сетки в диалоговом окне.
Основная идея заключается в написании запроса T-SQL так, чтобы его можно было использовать в качестве набора данных для мини-приложений "Счетчик", "Диаграмма" и "График".
Сводка
Поведение аналитического мини-приложения определяется запросом T-SQL и его результирующим набором. При создании эффективного аналитического мини-приложения ключевым фактором является написание запроса для типа диаграммы или сопоставление правильного типа диаграммы для существующего запроса.
Читайте также: