Привет! На связи команда Business Intelligence GlowByte. Хотим поделиться статьей китайского автора и бизнес-аналитика, активного пользователя FineBI. Он рассмотрел решение 15 типичных кейсов в Tableau и FineBI, провел сравнение инструментов, а также сделал вывод относительно их преимуществ и недостатков. Для интересующихся темой этот материал – находка. Если вы ищете больше информации и ответов на вопросы, смело приходите к нам в самое крупное комьюнити FineBI в России, созданное Business Intelligence GlowByte.



Tableau – BI-инструмент, который посредством LOD-выражений позволяет выполнять сложные запросы/анализ, включающий множество измерений на уровне источника данных, без необходимости переноса их на визуализацию.

FineBI – это BI-инструмент, разработанный китайской компанией FanRuan. Функция DEF является отличительной чертой этого продукта. DEF (def, def-add, def-sub и функция earlier) – это собственная разработка компании, способная решать сложные сценарии вычислений.

Данная статья будет полезна тем, кто, как и автор, часто имеет дело со сложными сценариями вычислений, а также компаниям, которые заинтересованы в ближайшем будущем перейти на FineBI.


Погружение в вопрос

В ходе написания статьи мы обнаружили, что при решении кейсов LOD-выражения Tableau и функция DEF FineBI в 85% случаев работают одинаково хорошо: пользователю не нужно выполнять расчеты в SQL и общий принцип работы двух инструментов довольно понятен. Однако в некоторых случаях FineBI использовать было сложнее: к примеру, было сложно писать формулы и выставлять приоритеты на фильтрах, но, как утверждает команда разработчиков FineBI, эти проблемы будут решены в ближайшее время.

Благодаря этому сравнению можно увидеть, что комплексная вычислительная система FineBI уже имеет некую структуру, и ее можно использовать в большинстве сложных сценариев вычислений. Однако она все еще нуждается в оптимизации некоторых функций. С кратким описанием конкретных преимуществ и недостатков обоих инструментов можно ознакомиться в заключении к настоящей статье.

Пример №1: частота оформления заказов клиентами

Описание:

Мы можем с легкостью найти в системе историю заказов каждого клиента, но что, если нам нужно узнать, какое число клиентов оформило один, два, три, n заказов? Для этого мы должны сгруппировать клиентов по количеству заказов. Это несложно, хотя группировать один набор данных на основе другого очень трудно без LOD-выражений.

Рассмотрим базу данных продаж супермаркета, в которой на один заказ приходится несколько товаров. Посредством данных о заказах клиентов мы можем узнать, какое количество заказов сделал каждый из них. Для этого с помощью LOD-выражения мы преобразуем количество заказов в некое измерение, на основе которого будем группировать клиентов.

Ключевой момент в визуализации:

Количество клиентов с разной частотой покупок

Пример LOD:
Количество покупок одного клиента: { FIXED [Customer ID]:COUNTD([Order ID])}

Пример FineBI:

Количество покупок одного клиента: DEF(COUNTD_AGG(${Order ID}),[${Customer Name}])

Вывод:

В этом примере у двух инструментов отличий нет.

Пример №2: анализ массива
Описание:

Можно ли утверждать, что, чем чаще клиент пользуется услугами компании, тем больше его вклад в продажи? На следующей визуализации, чтобы сравнить годовой объем продаж в каждом массиве данных, мы сгруппировали данные о клиентах в соответствии с годом, в котором клиент впервые совершил покупку. Эти данные мы и принимаем за min значение даты. Однако, поскольку на визуализации данные отображаются не по клиентам, мы используем LOD-выражение, чтобы определить первую дату заказа.

Ключевой момент в визуализации:

Ежегодный рост доходов за счет новой клиентской базы.

Пример LOD:
Дата первой покупки клиента: { FIXED [Customer ID]:MIN([Order Date])}

Пример FineBI:

Дата первой покупки клиента: DEF(MIN_AGG(${Order Date}),${Customer ID})

Вывод:

В этом примере фильтр не влияет на значение FIXED в Tableau, но в FineBI фильтрация результата происходит иначе, поэтому при фильтрации результата нам необходимо перетащить компонент на поле детализации, а затем применить фильтр. Таким образом, проблема приоритета фильтра все еще актуальна.

Пример №3: KPI ежедневной прибыли
Описание:

С одной стороны, мы можем отслеживать динамику прибыли, но что, если мы будем оценивать наши успехи на основе показателей прибыли за каждый рабочий день?

В таком случае, вероятно, нам нужно будет узнать число прибыльных дней в каждом месяце или в год, особенно если нам нужно понимать, как прибыль изменяется в зависимости от сезона. На следующей визуализации показано, как можно использовать LOD-выражения для создания уровней в агрегированных данных (например, прибыль за день), при этом основные данные записываются на уровне транзакций.

Ключевой момент в визуализации:

Ежемесячное количество сверхприбыльных, прибыльных и убыточных дней.

Пример LOD:

На основе данных о ежедневной прибыли мы присваиваем одно из трех значений прибыли каждому дню месяца.

Общий доход за день: {FIXED [Order Date]:SUM([Profit])}

Значение прибыли: IF [ежедневный объем прибыли] > 2000 THEN "высокая прибыль" ELSEIF [ежедневный объем прибыли] <= 0 THEN "убыток" ELSE "прибыль" END

Пример FineBI:

Общий доход за день: DEF(SUM_AGG(${Profit}),[${Order Date}])

Значение прибыли: IF(${ежедневный объем прибыли}>2000,"высокая прибыль",IF(${ежедневный объем прибыли}<0,"убыток","прибыль"))

Вывод:

В этом примере разница между двумя инструментами отсутствует.
Пример №4: процент от общего числа

Описание:

Какой вклад в глобальные продажи вносит каждая страна или регион? Если мы посмотрим на процентное соотношение прибыли, то увидим, что наибольший вклад в мировой доход от продаж вносят США. Однако, вероятно, нам будет интереснее рассмотреть рынки, чья доля невелика, например, Европейский Союз. Без LOD-выражения фильтрация по рынку приведет к пересчету процента от общего, и мы сможем увидеть лишь вклад каждой страны или региона в свой рынок. Однако с помощью LOD-выражения мы можем фильтровать рынки и при этом измерять глобальный вклад.

Ключевой момент в визуализации:

Объем продаж в каждом регионе, процент от общего.

Пример LOD:

Общий объем продаж не меняется при использовании фильтра.

Общий объем продаж каждого государства: { sum([sales]) }

Пример FineBI:

Общий объем продаж каждого государства: DEF(SUM_AGG(${Sales}),[])

Вывод:

В этом примере FineBI работает, как и в примере №2, есть проблема приоритета фильтра. Если вы не хотите, чтобы фильтр влиял на пропорцию, то можете поместить его только в те места, где фильтруются результаты, но это создаст определенные неудобства при просмотре действий пользователя.

Пример №5: показатель привлечения новых клиентов
Описание:

Как ежедневно изменяется показатель привлечения клиентов по рынку? При анализе этой динамики мы можем выяснить, какую роль играют региональные маркетинговые и торговые организации в развитии новых отраслей бизнеса. На визуализации можно увидеть, что чем круче график уходит вверх, тем выше показатель привлечения новых клиентов. Линия, которая постепенно выравнивается, означает, что необходимо предпринять определенные меры для увеличения количества потенциальных клиентов.

С помощью LOD-выражения система не будет ошибочно учитывать постоянных клиентов как новых, поскольку данные будут обрабатываться на уровне клиентов, даже если на визуализации они отображаются в соответствии с рынком и днем.

Ключевой момент в визуализации:

Ежедневное количество новых клиентов на каждом рынке.

Пример LOD:

Каждому клиенту был присвоен свой тэг, чтобы отмечать статус под текущей датой.

Дата первой покупки: {FIXED [Customer ID]:MIN([Order Date])}

Подсчет старых и новых клиентов в соответствии с тем, совпадает ли дата покупки с первой датой покупки: IF [Order Date] = [дата первой покупки] THEN "новый клиент" ELSE "старый клиент" END

С помощью быстрого табличного расчета мы вычисляем и суммируем общее количество клиентов.

Пример FineBI:

- IF(${Order Date}=${дата первой покупки-1},"новый клиент","старый клиент")

Для общего количества клиентов в настоящее время не существует табличного расчета, аналогичного Tableau, и общую сумму можно вычислить следующим образом:

- DEF_ADD(${новый клиент},[],[${Order Date}<=EARLIER(${Order Date}),${Market}=EARLIER(${Market})])

Вывод:
В этом примере производительность FineBI довольно низкая. Во время встречи пользователей с разработчиками автор внес соответствующее предложение команде FineBI. Ожидается, что в 2024 году пользователям станет доступна оконная функция, которая сможет решить эту проблему.

Пример №6: сравнительный анализ продаж

Описание:

Найти отличие от среднего – довольно простая задача, но что, если необходимо найти отличие от выбранной категории? Сначала необходимо отделить продажи выбранной категории от остальных, затем с помощью выражения EXCLUDE повторить данное значение в других категориях. После этого можно будет легко понять разницу между продажами выбранной категории товаров по сравнению с остальными.

Ключевой момент визуализации:

Продажи каждой категории без учета продаж выбранной категории.

Пример LOD:

Отделите продажи выбранной категории товара: {EXCLUDE [Category] : SUM([ объем продаж выбранной категории]) }

Пример FineBI:

Введите дополнительное условие: DEF_SUB(SUM_AGG(${объем продаж выбранной категории}),${Category})

Вывод:

В этом примере отличия между двумя инструментами отсутствуют.

Пример №7: среднее значение максимальной суммы сделок по
контрагентам

Описание:

Каково значение максимальной суммы сделок каждого контрагента? Если группировать эти сделки по контрагентам, то какое будет среднее значение по стране или региону?

Благодаря LOD-выражениям, даже если на визуализации данные отображаются на уровне страны или региона, мы можем увидеть данные контрагентов на уровне детализации. На следующей визуализации высокое значение средней суммы обозначено синим цветом, а низкое – оранжевым. Мы можем использовать эту информацию при переходе к детальному анализу продаж от стран или регионов к непосредственно контрагентам.

Ключевой момент визуализации:

Среднее значение самых крупных объемов сделок в разных регионах.

Пример LOD:

Максимальный объем продаж каждого контрагента: {INCLUDE [Sales Rep]:MAX([Sales])}

Пример FineBI:

Максимальный объем продаж каждого контрагента: DEF_ADD(MAX_AGG(${Sales}),${Sales Rep})

Вывод:


В этом примере отличия между двумя инструментами отсутствуют.

Пример №8: сравнение целевых и фактических показателей

Описание:

На данной визуализации мы попытались продемонстрировать различия между целевым и фактическим значением прибыли сети кофеен в каждом штате. В верхней части визуализации можно увидеть, в каких штатах удалось достичь целевых показателей, а в каких нет. Однако, используя лишь агрегирующие функции, мы можем упустить важные нюансы. Так, некоторым штатам удается достичь целевых показателей, поскольку в них продажи всех категорий товаров всегда превосходят целевые показатели. В других же штатах продажи одной категории товаров настолько велики, что способны компенсировать низкие продажи иных товаров. Таким образом, мы можем использовать LOD-выражения, чтобы определить, какой процент товаров, проданных в том или ином штате, действительно превышает целевой показатель.


Ключевой момент визуализации:

Доля проданных товаров в каждом штате, которые в общей сложности превышают план.

Пример LOD:

Детализация категорий товаров и число товаров, продажи которых достигли целевого показателя.
Разница между реальным и плановым показателем прибыли для каждого товара: {INCLUDE [Product]:SUM([Difference Between Actual and Target Profit])}
Достигли ли продажи данного товара планового показателя: IIF([разница между целевым и реальным показателем прибыли]>0,1,0)

Пример FineBI:

Разница между реальным и плановым показателем прибыли для каждого товара: DEF_ADD(SUM_AGG(${Difference Between Actual and Target Profit}),${Product})

Достигли ли продажи данного товара планового показателя: IF(${разница между целевым и реальным показателем прибыли }>0,1,0)

Вывод:

В этом примере, если нажать на любой компонент, можно перейти в детализацию, где будет показано, какие товары достигли целевого показателя. Однако, поскольку возможности визуализации в FineBI ограничены и мы не можем отобразить линию плана, как в Tableau, пришлось изменить структуру, чтобы создать эффект, напоминающий маркированную диаграмму.

Пример №9: значение последнего дня периода

Описание:

Данные, отражающие ситуацию в конкретный день (например, наличие товаров на складе, ежедневное количество работников и пр.), необходимо обрабатывать иначе, чем данные, которые можно агрегировать (например, объем продаж или значение прибыли). Во время обработки этих данных, вероятно, имеет смысл отображать значения последнего дня календарного месяца. Кроме того, нам, возможно, захочется, чтобы ежемесячные данные детализировались до еженедельных, показатели обновлялись и на экран выводилось значение последнего дня недели.

В приведенном ниже примере мы использовали ежедневные данные инвентаризации. На данной визуализации представлено сравнение среднего значения инвентаризации на конец дня и значения на последний день периода. С помощью LOD-выражения мы можем увидеть ежедневный показатель, даже если данные отражены на более высоком уровне.

Ключевой момент визуализации:

Значение в последний день (close value).

Пример LOD:

Детализация дня, значение в последний день.

Последний день: { INCLUDE:MAX([Date])}

Значение в последний день: IF { INCLUDE:MAX([Date])}=[Date] THEN [Adj Close] ELSE 0 END

Пример FineBI:

Последний день: DEF(MAX_AGG(${Date}),[YEAR(${Date}),MONTH(${Date})])

Недостаток: я не ожидал, что DEF_ADD с max не применим к дате…

Значение в последний день: IF(${Date}=${последний день},${Adj Close},0)

Вывод:

В этом примере отличия между двумя инструментами отсутствуют.

Пример №10: данные о постоянных клиентах в массивах

Описание:
Поскольку на привлечение новых клиентов приходится тратить много ресурсов, мы заинтересованы в том, чтобы клиенты возвращались и совершали покупки снова и снова. Но какое количество клиентов вновь совершило покупки за один, два, три и n кварталов? И какое количество клиентов больше никогда не возвращалось? Что мы узнаем, если сгруппируем данные о повторных покупках по кварталам? С помощью выражения FIXED мы можем найти дату первой и второй покупки каждого клиента и вычислить количество повторных покупок за квартал.

Ключевой момент визуализации:

Дата первой покупки и период, в течение которого клиент совершил повторную покупку; соответствующее количество покупателей.

Пример LOD:

Промежуток, в течение которого клиент совершил повторную покупку.

Дата первой покупки: {FIXED [Customer ID]:MIN([Order Date])}

Исключение даты первой покупки: IIF([Order Date]> [дата первой покупки],[Order Date],NULL)

Дата второй покупки: { FIXED [Customer ID]: MIN([исключить дату первой покупки])}

Вычисление промежутка между первой и второй датой: DATEDIFF('quarter',[дата первой покупки],[дата второй покупки])

Пример FineBI:

- DEF(MIN_AGG(${исключение даты первой покупки}),${Customer ID})

Вычисление промежутка между первой и второй датой:

DATEDIF(${дата первой покупки},${дата второй покупки},"M")

IF(${дата второй покупки}=NULL,NULL,DATEDIF(${дата первой покупки},${дата второй покупки},"M"))

Вывод:

В этом примере можно увидеть, что у FineBI нет ежеквартального параметра для расчета разницы во времени, поэтому вместо него используется разница за месяц, и после преобразования результата DEF в измерение необходимо снова перенести его в после индикаторов, что не совсем удобно.

Пример №11: процентная разница в ряду средних значений

Описание:

В примере №6 мы объясняли, как сравнивать выбранные значения, но что, если мы хотим сравнить ряд значений? Например, до появления неких событий, влияющих на отрасль, возможно, мы захотим сравнить ежедневный объем продукции на складе с его средним значением за сутки.

Ключевые моменты визуализации:

Нет.

Пример LOD:

Дополнительные данные: укажите среднее значение закрытия в пределах выбранного диапазона дат.

1. Два новых параметра: дата начала, дата конца.
2. Возвращение значения закрытия в пределах интервала: IIF([Date]>= [дата начала] and [Date]<= [дата конца],[Adj Close],null)
3. Вычисление среднего значения в пределах интервала: {FIXED [Ticker]: AVG([значение закрытия в течение выбранного периода])}
4. Процентная разница: ([значение закрытия]-[среднее значение в течение выбранного периода])/[среднее значение в течение выбранного периода]

Вывод:

В этом примере, поскольку в FineBI линейную диаграмму можно построить только с помощью измерения и индикатора, мы не можем добавить значение процентного сравнения на визуализацию и, как следствие, отобразить сравнение в интервале дат, как в Tableau.

Пример №12: фильтрация по относительному периоду

Описание:
При анализе часто используется сравнение показателей year-to-date и month-to-date с аналогичными показателями за прошлый год. После фильтрации мы легко можем провести анализ, но что, если данные обновляются каждую неделю? Допустим, предыдущее обновление было 1 марта, а сегодня уже 7 марта. Сравнение month-to-date показало бы сравнение между периодом с 1 по 7 марта предыдущего года и 1 марта текущего года, что может вызвать дискомфорт у пользователей. Однако благодаря LOD- выражениям мы можем найти max значение даты в наборе данных.

Ключевой момент визуализации:

Сравнение прибыли за текущий и предыдущий год.

Пример LOD:

Нет данных по последней дате за предыдущий год, необходимо провести сравнение с самой поздней датой за этот год.

Max дата: { max ([order date]) }

Фильтр:

dayofyear = DATEPART(‘dayofyear’, {MAX([Order Date])} ) 258 дней

Условие фильтра: [dayofyear] >= DATEPART(‘dayofyear’, [Order Date] )

Рассчитаем общую прибыль за 2013 и 2014 г., а также разницу между ними. Выведем результаты расчетов.

Пример FineBI:

Ход вычисления: возьмем из базы данных даты (детализация до недель), затем сгруппируем и суммируем данные в соответствии с годом, месяцем и неделей, далее суммируем данные за год. После этого соберем визуализацию – получилось два столбца со значениями прибыли за 2013 и 2014 год. Наконец, отфильтруем строки с нулевыми значениями.

Вычислим разницу непосредственно в компоненте: ${2014-объем за год}-${2013-объем за год}

Вывод:

Нельзя напрямую вычислять значения в таблицах, как в Tableau, что довольно неудобно.

Пример №13: частота входа пользователей

Описание:

Какое количество пользователей осуществляет вход на веб-сайты или в приложения раз в один, два или три месяца? Чему равно среднее значение? Насколько значения отличаются от среднего? Гранулярность данных определяется датой входа в систему клиентом под своим ID, другими словами, каждый вход пользователя система фиксирует в виде строки данных. Чтобы собрать визуализацию, необходимо разделить количество клиентов в соответствии с частотой входа, то есть сгруппировать одни данные на основе других данных. В примере №1 мы уже увидели, как можно использовать LOD-выражение при подобном анализе данных.

Ключевой момент визуализации:

Временной промежуток между первым и вторым входом, соответствующее количество пользователей.

Пример LOD:

Здесь нам понадобятся данные о периоде между первым и вторым входом, а также данные о количестве входов каждого пользователя.

1. Дата первого входа + дата последнего входа, функция fixed+min/max：{FIXED [User ID]:MIN([Log in Date])}、{FIXED [User ID]:MAX([Log in Date])}
2. Вычисляем интервал между двумя датами, для этого используем функцию datediff, задаем параметр значения month: DATEDIFF('month',[дата первого входа],[последняя дата входа])
3. Вычисляем количество выполненных входов каждым пользователем, fixed +countd：{FIXED[User ID]:COUNTD([Log in Date])}
4. Вычисляем среднее значение выполненных каждым пользователем входов за неделю, промежуток времени/ количество входов: ROUND([временной промежуток]/[количество входов каждым пользователем])
5. Строим контрольную линию (линию плана), указывающую на среднее значение выполненных всеми пользователями входов за неделю: {EXCLUDE [среднее количество входов за неделю]:AVG([среднее количество входов за неделю])}
6. Меняем цвет колонок: AVG([среднее количество входов за неделю])-AVG([среднее количество входов за неделю всех пользователей])

Вывод:

Ввиду ограниченных возможностей FineBI мы можем создавать визуализации только используя индикатор и измерение, поэтому дополнительно построить линию плана нельзя. Кроме того, после преобразования индикатора в измерение его невозможно использовать как численную величину, поэтому нам приходится дублировать индикатор для вычисления среднего значения выполненных всеми клиентами входов за неделю.

Пример №14: обработка пропорции

Описание:

При анализе данных прежде всего мы должны ответить на следующий вопрос: с чем мы сравниваем?. При применении фильтра иногда требуется сравнить выбранное значение с суммой, а не просто отфильтровать его. Этот метод называется обработкой пропорции (proportional brushing).

Ключевой момент визуализации:

Доля страны в продажах разных категорий товара.

Пример LOD:

Общий объем продаж (более высокий уровень агрегации).

Продажи данной подкатегории товара во всех странах: {Fixed [Sub-Category] : Sum([Sales]) }

Доля: SUM([sales])/SUM([продажи данной подкатегории товара во всех странах])

Пример FineBI:

Продажи данной подкатегории товара во всех странах: DEF(SUM_AGG(${Sales}),${Sub-Category})

Доля: SUM_AGG(${Sales})/SUM_AGG(${продажи данной подкатегории товара во всех странах})

Вывод:

В этом примере FineBI не может полностью воспроизвести функции Tableau. Соединение визуализаций – это элемент детальной фильтрации, поэтому у нас не получится динамически отобразить ситуацию в каждой стране, щелкая по карте, как в Tableau. Кроме того, мы не можем совместить две колонки в одну, поэтому приходится использовать комбинированный вариант визуализации – две колонки, стоящие рядом, и карту.

Пример №15: ежегодная частота покупок в массиве данных клиентов

Описание:

Можно ли утверждать, что чем чаще клиент возвращается за покупками, тем он лояльнее? В таком случае период сотрудничества компании и клиента мы будем отсчитывать с даты первого обращения, а измерять лояльность – ежегодной частотой покупок.

Из примера №1 мы поняли, как можно определить количество клиентов, совершивших покупку один или два раза. Однако маркетологам очень редко приходится вычислять количество клиентов, совершивших покупку, например, ровно пять раз. Гораздо полезнее знать количество клиентов, которые приобрели продукт не менее пяти раз.

Кроме того, из примера №2 мы можем узнать, что в 2011 году компания привлекла больше всего новых клиентов, а в 2014 году – меньше всего. Проанализировав абсолютное число клиентов, можно также проследить указанную тенденцию. Вероятно, именно поэтому было бы любопытно попытаться использовать процент от общего числа в каждом массиве данных клиентов в качестве показателя лояльности.

Таким образом, первоначальный вопрос можно перефразировать следующим образом: какова доля покупателей в каждом массиве, которые приобретали товары по крайней мере один, два, три или n раз в год?

Ключевой момент визуализации:

Фильтр: процент от совокупной суммы годового массива данных клиентов, основанный на частоте покупок.

Пример LOD:

Дополнительные данные: количество клиентов, которые совершили покупку минимум один, два, три и n раз; данные массива (за год).

1. Год, когда каждый клиент впервые совершил покупку: {FIXED [Customer ID]: MIN(Year([Order Date]))}
2. Число покупок, которые каждый клиент совершил за год: {FIXED [Customer ID], [Order Date (Years)]: COUNTD([Order ID])}
3. Число клиентов, которые совершили покупку минимум один, два, n раз: WINDOW_SUM( COUNTD([Customer ID]), 0, LAST())
4. Количество клиентов за год: { FIXED [год, когда клиент впервые совершил покупку]:COUNTD([Customer ID])}
5. Доля: [количество покупателей, которые совершили покупку минимум 1, 2, n раз]/SUM([ежегодное количество новых клиентов])

Мы исключили значение 100%, поскольку клиент, который совершил покупку в этом году, должен совершить покупку хотя бы еще один раз, чтобы визуализация не была сбита.

Пример FineBI:

1. Год, когда каждый клиент впервые совершил покупку: DEF( MIN_AGG(YEAR(${Order Date})),${Customer ID})
2. Число покупок, которые каждый клиент совершил за год: DEF(COUNTD_AGG(${Order ID}),[YEAR(${Order Date}),${Customer ID}])
3. Число клиентов, которые совершили покупку минимум один, два, n раз: DEF_ADD(COUNTD_AGG(${Customer ID}),[],[${ежегодное количество покупок каждого клиента 1}>=EARLIER(${ежегодное количество покупок каждого клиента 1}),${год, когда клиент совершил первую покупку 1}=EARLIER(${год, когда клиент совершил первую покупку 1}),${Order Date (Years)}=EARLIER(${Order Date (Years)})])
4. Количество клиентов за год: DEF(COUNTD_AGG(${Customer ID}),${год, когда клиент совершил первую покупку 1})
5. Доля: ${Вычисление внутри компонента}/${ежегодное количество новых клиентов}

Вывод:

После вычисления значения индикатора в FineBI мы преобразуем его в измерение, но измерение нельзя редактировать и вычислять. Как итог, нам нужно дублировать индикаторы, что довольно неудобно.

Заключение

Будучи активным пользователем FineBI и проведя подобный анализ, автору удалось отчетливо увидеть, что функция DEF в FineBI 6.0. отлично выполняет расчеты на дашбордах и довольно удобная в использовании.

Отдельно стоит отметить, что в FineBI есть self-service-датасет, который компенсирует недостатки и расширяет возможности функции DEF при обработке и подготовке табличных данных. В то же время, хотя функция FIXED Tableau обладает определенным вычислительным функционалом, ей все же не хватает возможностей фильтрации. Так, чтобы обработать таблицу, необходимо использовать другую функцию – Tableau Prep, что довольно неудобно.

Однако, как говорилось в начале, FineBI по-прежнему нуждается в оптимизации и улучшении различных функций. Мы рекомендуем команде FineBI продолжить детальное изучение и проработку логики продукта, учитывая привычки пользователей. По нашему мнению, существует еще множество областей для улучшения и оптимизации работы, к примеру:

1. Сложность в написании формул: на данный момент при сортировке и счете внутри группы, межстрочном расчете и пр. пользователям приходится писать довольно громоздкие формулы, а затем помещать их в быстрые вычисления, чтобы сотрудникам было удобнее пользоваться ими.
2. Преимущества и недостатки функции DEF: например, для обеспечения совместной работы компонентов фильтра и визуализации функция детальной фильтрации требует отдельной настройки фильтра результата в компоненте. Это приводит к тому, что другие пользователи не могут легко изменять и корректировать настройки.
3. Необходимость преобразовывать индикаторы в измерения: при использовании столбчатых и линейных диаграмм индикаторы (после проведения расчетов) приходится преобразовывать в измерения. Однако, поскольку измерение нельзя редактировать, их вновь приходится преобразовывать в индикаторы. Кроме того, измерения нельзя вычислять в формулах, что в некоторых случаях приводит к дублированию компонентов.
4. Обработка NULL: на данный момент при проведении расчетов за значение NULL принимается текущая дата, а не пустое значение, что может вносить неточности в итоговые расчеты.
5. Проблемы с базовыми формулами: в некоторых базовых формулах все еще есть определенные недоработки. Например, отсутствует функция вычисления данных за квартал, из-за чего нельзя напрямую вычислить разницу между кварталами, что ограничивает возможность расчета определенных данных, связанных со временем. Кроме того, в компонентах FineBI результат вычисления количества недель нельзя совместить с данными о количестве недель, полученными при использовании некоторых функций: так, DEF_ADD не поддерживает даты MAX_AGG и т. д.

Размышления автора

Как было сказано в самом начале, автор уже давно использует FineBI, а также неоднократно участвовал во встречах команды FineBI с пользователями и совместном усовершенствовании программы. Поэтому перед публикацией настоящей статьи автор отправил свои наработки команде FineBI, чтобы обсудить некоторые детали. Мы получили следующий ответ:

«Tableau является передовым и популярным во всем мире BI-инструментом с богатой историей и мощным набором функций, благодаря чему многие компании доверяют ему и активно используют. Поскольку FineBI – сугубо китайский BI-продукт, наша команда отчетливо осознает, что в сравнении с Tableau у нашего ПО все еще есть определенные недостатки. Однако это нас не останавливает, напротив, решая эти проблемы, мы имеем возможность дальше совершенствовать наш продукт, улучшать его производительность и добавлять новые функции. Мы прислушиваемся к нашим пользователям и пытаемся восполнить недостатки, внедрить инновационные решения и оптимизировать производительность, чтобы максимально удовлетворить потребности пользователей».

Если вы хотите попробовать данный продукт и сделать свой сравнительный анализ, оставляйте заявку и вступайте в самое крупное комьюнити FineBI в России.

Теги: finebitableauglowbyteвизуализация данныхдашбордыbusiness intelligencelodвычисленияданные в компанииbig data tools

Хабы: Блог компании GlowByteBig DataВизуализация данныхУправление продуктом