万字长文!致敬Tableau LOD15大详细级别表达式——FineBI的复刻

文 | 商业智能BI相关文章 阅读次数:1,220 次浏览
2024-03-01 15:07:41

Tableau作为国外知名BI产品,其LOD表达式可让用户轻松计算不在可视化详细级别层面上的聚合,做到沉浸式分析,但是LOD又并非能轻易学会。为解决上手问题,官方博客提供了15个经典案例供用户学习,每一个都是经典的高级计算场景,实现能在一个视图中包含多个层次的跨层次分析,为业务分析师提供高级分析思路。

而FineBI作为目前国内帆软旗下领先的BI产品,以BI分析三大件:数据编辑、主题模型、DEF函数作为产品亮点,其中DEF函数(def、def-add、def-sub和earlier函数)则是其专门突破解决复杂计算场景的自研函数。

复杂计算场景,可视化关键,DEF函数

由于工作需要,老李我经常需要处理复杂计算场景,且近期公司有国产化需求,因此想借本篇文章,来直观测评两款BI产品在实现复杂计算场景的表现情况。

本文将详细展示如何分别使用Tableau及FineBI完成这15个案例,并从中对比、总结出各自的优劣势。

先给结论:

通过本次测评,我们发现针对这15个案例,相较于Tableau的LOD表达式,FineBI的DEF函数在85%情况下能完成相同效果,无需写sql完成,易用性属于中上水平。但FineBI在部分场景下的易用性还稍显不足,例如书写复杂及过滤优先级问题,不过据FineBI产品团队透露,这些问题将在下半年得到解决。

总的来说,通过此次测评可看出FineBI的复杂计算体系已初步构建完成,能满足大部分复杂计算场景,但在各类功能细节处还需不断优化迭代,二者具体优劣势总结可直接见文末测评总结。

场景01:客户订单频率

场景描述:

找出每个客户订购的订单数相对简单,但是如果我们想了解订购过一个订单、两个订单、三个订单(依次类推)的客户数目,该怎么办?要生成相应视图,我们必须按订购的订单数划分客户数。这是一个简单的问题,但是如果没有详细级别表达式,按照某一度量划分另一度量将非常困难。

想一想每个订单包含多个项目的超市销售数据库,各个客户的单独订单数指出了每个客户订购的订单数,只需采用简单的详细级别表达式,即可将订单数转变为按客户数划分的维度。

可视化关键:

不同购买频次的顾客数量

LOD范例:

每个顾客的购买次数:{ FIXED [Customer ID]:COUNTD([Order ID])}

复杂计算场景,可视化关键,DEF函数

FineBI复刻:

每个顾客的购买次数:DEF(COUNTD_AGG(${Order ID}),[${Customer Name}])

复杂计算场景,可视化关键,DEF函数

点评:

在此场景,二者无明显差异。

场景02:阵列分析

场景描述:

合作间越长的客户对销售额的贡献越大吗?下面的视图按照客户首次购买的年份将客户分组,以便对比各个阵列的年度销售贡献额。每个客户的最早订单日期将体现出首次购买日期。不过,由于视图中的数据未按客户显示,我们必须使用详细级别表达式来确定每个客户的最早订单日期。

可视化关键:

每年,各年新增顾客群的贡献度

LOD范例:

每个顾客的首次购买日期:{ FIXED [Customer ID]:MIN([Order Date])}

复杂计算场景,可视化关键,DEF函数

FineBI复刻:

每个顾客的首次购买日期:DEF(MIN_AGG(${Order Date}),${Customer ID})

点评:

在此场景,Tableau里的 FIXED 是不被过滤条件影响,但FineBI里的结果过滤器是明细过滤,所以当需要结果过滤的时候,应该把字段拖到细粒度里,然后用细粒度过滤就是结果过滤了,过滤优先级问题需要改善。

场景03:每日利润 KPI

场景描述:

我们确实可以查看利润随时间的变化趋势,但如果我们想按照每个工作日的总利润来衡量成功,该怎么办?

我们可能想要了解每个月或每年的盈利天数,尤其是在我们想了解季节影响时。下面的视图显示了在以交易级别记录基础数据的情况下,我们如何利用详细级别表达式轻松根据聚合数据创建分级(例如每日利润)。

可视化关键:

每月,三个盈利标签下的天数

LOD范例:

根据每天的利润总额,给每天标记一个利润标签。

每一天的盈利额:{FIXED [Order Date]:SUM([Profit])}

盈利标签:IF [每一天的盈利额] > 2000 THEN “高盈利” ELSEIF [每一天的盈利额] <= 0 THEN “亏损” ELSE “盈利” END

复杂计算场景,可视化关键,DEF函数

FineBI复刻:

每一天的盈利额:DEF(SUM_AGG(${Profit}),[${Order Date}])

盈利标签:IF(${每一天的盈利额}>2000,”高盈利”,IF(${每一天的盈利额}<0,”亏损”,”盈利”))

复杂计算场景,可视化关键,DEF函数

点评:

在此场景,二者无明显差异。

场景04:总额百分比

场景描述:

每个国家/地区的收入对全球销售额有何贡献?如果我们按照贡献百分比着色,即可看出美国对全球销售收入的贡献最大。但是,我们可能想重点关注欧盟等在绝对值上相对贡献较小的市场。如果不采用详细级别表达式,对某市场进行筛选会导致总额百分比的重新计算,从而显示每个国家/地区对其市场的贡献。利用简单的详细级别表达式,我们可对某市场进行筛选,同时仍可衡量全球贡献。

可视化关键:

每个区域的销售额,占总的额度占比

LOD范例:

总的销售额,不随筛选器变化

所有国家的销售额的总和:{ sum([sales]) }

复杂计算场景,可视化关键,DEF函数

FineBI复刻:

所有国家的销售额总和:DEF(SUM_AGG(${Sales}),[])

复杂计算场景,可视化关键,DEF函数

点评:

在此场景,FineBI同2场景(阵列分析)一样,还是过滤优先级问题,如果想要占比不受过滤器影响的话,只能放到这几个结果过滤的地方,但这样其实不方便查看用户操作。

场景05:新客户争取率

场景描述:

各个市场总客户争取率的每日趋势如何?了解这一数据趋势后,可帮助我们了解地区营销和销售组织在发展新业务方面的表现。线越陡,则争取率趋势越好。如果线逐渐变平,则必须采取一些措施来增加潜在客户流。

详细级别表达式可确保回头客不会误计入新客户,这是因为虽然数据按照市场和天数直观显示,但是必须在客户层面上进行评估。

可视化关键:

每个市场每天的新客户数量

LOD范例:

给每个客户一个标签,标记在当前日期下的状态

首次购买日期:{FIXED [Customer ID]:MIN([Order Date])}

根据购买日期是否等于首次购买日期判断新老客户:IF [Order Date] = [首次购买日期] THEN “新客户” ELSE “老客户” END

通过快速表计算,计算汇总累计客户数。

复杂计算场景,可视化关键,DEF函数

FineBI复刻:

IF(${Order Date}=${首次购买日期-1},”新客户”,”老客户”)

累计客户数,目前没有类似Tableau的表计算,通过函数实现累计求和:

DEF_ADD(${客户数},[],[${Order Date}<=EARLIER(${Order Date}),${Market}=EARLIER(${Market})])

复杂计算场景,可视化关键,DEF函数

点评:

在此场景,FineBI性能问题略显劣势,老李我在用户交流时曾给产品团队反馈过,预计年底会发布windows窗口函数,可以解决性能卡慢问题。

场景06:对比销售额分析

场景描述:

找出与平均值之间的差异相对简单,但是如果想找出与选定类别的差异,该怎么办?首先,必须隔离选定类别的销售额。然后,需要使用 EXCLUDE 表达式在所有其他类别中重复该值。之后,便可轻松了解每个类别的销售额与其他类别的差异。

可视化关键:

每个分类的销售减去选择的分类的销售额

LOD范例:

把选择的产品销售锁定为全局可用:{EXCLUDE [Category] : SUM([选定的category的销售额]) }

复杂计算场景,可视化关键,DEF函数

FineBI复刻:

引入额外背景条件:DEF_SUB(SUM_AGG(${选定category的销售额}),${Category})

复杂计算场景,可视化关键,DEF函数

点评:

在此场景,二者无明显差异。

场景07:各个销售代表的平均最大额交易数额

场景描述:

每个销售代表达成的最大交易额是多少?然后想一想,对于各个销售代表达成的最大额交易数额,按国家/地区计算的平均值是多少?

利用详细级别表达式,即使数据按照国家/地区级别直观显示,我们也可以向下查看销售代表详细级别。在下面的视图中,销售代表的平均最大额交易数额在颜色为蓝色的国家/地区较高,而在颜色为橙色的国家/地区较低。我们可以使用这些信息指导对从国家/地区到销售代表的深入分析。

可视化关键:

不同地区的“最大订单金额”的平均值

LOD范例:

计算各销售代表的最大订单金额:{INCLUDE [Sales Rep]:MAX([Sales])}

复杂计算场景,可视化关键,DEF函数

FineBI复刻:

每个销售代表的最大订单金额:DEF_ADD(MAX_AGG(${Sales}),${Sales Rep})

复杂计算场景,可视化关键,DEF函数

点评:

在此场景,二者无明显差异。

场景08:实际对比目标

场景描述:

在本可视化视图中,我们描述了每个州连锁咖啡厅的实际利润与目标利润之间的差异。在顶部视图中,我们可以清楚地看出哪些州超额完成目标,哪些州未完成目标。但是采用这种聚合方式,我们会漏掉重要的细微差别。某些州超出目标是因为在该州销售的每项产品都超出目标,另外一些州超出目标是因为单项产品超额完成其目标,足以弥补未完成目标的所有其他产品。我们可以使用详细级别表达式,确定某州内销售的产品中超出目标产品所占百分比。

可视化关键:

每个州,销售超过目标计划的商品占总数占比

LOD范例:

商品详细级别,销售超过目标的商品数量

每个产品的利润和目标利润差异:{INCLUDE [Product]:SUM([Difference Between Actual and Target Profit])}

该产品是否达到目标利润:IIF([每个产品的利润和目标利润差异]>0,1,0)

复杂计算场景,可视化关键,DEF函数

FineBI复刻:

每个产品的利润和目标利润差异:DEF_ADD(SUM_AGG(${Difference Between Actual and Target Profit}),${Product})

该产品是否达到目标利润:IF(${每个产品的利润和目标利润差异}>0,1,0)

复杂计算场景,可视化关键,DEF函数

点评:

在此场景,点击区域可以联动显示该区域哪些商品达到了目标利润,不过由于FineBI的参考线不如Tableau的灵活,所以这里修改了数据结构,做了一个类似子弹图的效果。

场景09:周期最后一天的价值

场景描述:

表示具体某天状态的数据(如库存数、员工实际人数或存货的日清算值)需要与可以聚合的指标(例如销售额或利润)区别对待。处理这些数据时,可能希望显示日历月最后一天的值。此外,我们可能希望从每月下钻到每周后,视图能够更新显示每周最后一天的值。

在下面的示例中,我们记录了每天多个时间点的库存数据。该视图对比了平均日清算值和周期最后一天的清算值。使用简单的详细级别表达式,我们可以向下查看每日级别,虽然数据直观显示的是较高级别。

可视化关键:

视图中日期维度(上面为月份)最后一天的闭市价格(close value)

LOD范例:

可视化日期详细级别中中,最后一天的闭市价格。

最后一天:{ INCLUDE:MAX([Date])}

最后一天的闭市价格:IF { INCLUDE:MAX([Date])}=[Date] THEN [Adj Close] ELSE 0 END

复杂计算场景,可视化关键,DEF函数

FineBI复刻:

最后一天:DEF(MAX_AGG(${Date}),[YEAR(${Date}),MONTH(${Date})])

缺点:DEF_ADD不能max日期也是我没想到的……

最后一天的闭市价格:IF(${Date}=${最后一天},${Adj Close},0)

复杂计算场景,可视化关键,DEF函数

点评:

在此场景,二者无明显差异。

场景10:各个阵列的回头客

场景描述:

争取新客户的成本可能非常高,因此我们希望能够确保现有客户会重复购买。在一个、两个、三个、N 个季度重复购买的客户数目是多少?从未重复购买的客户数目是多少?如果按季度阵列划分重复购买行为,会怎么样?我们可以使用 FIXED 表达式找到每个客户的第一次和第二次购买日期,并从中计算出重复购买的季度数。

可视化关键:

订单日期与顾客两次购买间隔,对应的顾客数量

LOD范例:

顾客两次购买的时间间隔。

首次购买日期:{FIXED [Customer ID]:MIN([Order Date])}

剔除首次购买日期:IIF([Order Date]> [首次购买日期],[Order Date],NULL)

第二次购买日期:{ FIXED [Customer ID]: MIN([剔除首次购买日期])}

计算两次消费日期间隔:DATEDIFF(‘quarter’,[首次购买日期],[第二次购买日期])

复杂计算场景,可视化关键,DEF函数

FineBI复刻:

DEF(MIN_AGG(${剔除首次购买日期}),${Customer ID})

计算两次消费日期间隔:

DATEDIF(${第一次购买日期},${第二次购买日期},”M”)

IF(${第二次购买日期}=NULL,NULL,DATEDIF(${第一次购买日期},${第二次购买日期},”M”))

复杂计算场景,可视化关键,DEF函数

复杂计算场景,可视化关键,DEF函数

点评:

在此场景,FineBI计算时间差没有季度参数,所以这里用月份差代替,以及DEF的结果转换为维度后,必须再次转回指标才可以进行修改,不太方便。

场景11:一系列平均值的百分比差异

场景描述:

示例 6 说明了如何对比单个选定项,但是如果您想对比一系列值,该怎么办?例如,在影响所关注行业的重大事件发生之前,您可能想对比存货的日清算值与平均日清算值。

可视化关键:

LOD范例:

额外引用的背景数据:指定ticker的选定日期区间内的平均闭市价格

新建两个参数:开始日期、结束日期

返回日期区间的闭市价格数值:IIF([Date]>= [开始日期] and [Date]<= [结束日期],[Adj Close],null)

计算选定日期区间内的平均值:{FIXED [Ticker]: AVG([选定日期区间内的闭市价格])}

百分比差异:([闭市价格]-[计算选定日期区间内的平均值])/[计算选定日期区间内的平均值]

复杂计算场景,可视化关键,DEF函数

FineBI复刻:

新建两个参数:开始日期、结束日期

返回日期区间的闭市价格数值:IF(AND(${Date}>=${开始日期},${Date}<=${结束日期}),${Adj Close},null)

返回日期区间的闭市价格的平均值:DEF(AVG_AGG(${返回日期区间的闭市价格数值}),${Ticker})

百分比差异:(${Adj Close}-${日期区间的闭市价格的平均值})/${日期区间的闭市价格的平均值}

复杂计算场景,可视化关键,DEF函数

点评:

在此场景,由于FineBI中折线图限制了维度+指标,而不能给维度加参考线,所以做不了Tableau里用参考区间表达日期区间的可视化效果明显

场景12:相对周期筛选

场景描述:

与前一年的年初至今和月初至今进行对比是分析业绩的常用指标。通过筛选相对于今天,我们能够轻松得出分析,但如果数据每周都刷新一次,这时该怎么办?假设您最近一次刷新是在 3 月 1 日,但当前日期是 3 月 7 日。月初至今对比会显示前一年 3 月 1 日到 3 月 7 日与今年的 3 月 1 日的对比。这会导致出现严重警报,但这种情况下不该出现警报!我们可以采用简单的详细级别表达式找出数据集中的最晚日期。

可视化关键:

今年同比去年的利润

LOD范例:

缺少去年YTD的截止日期,需要从今年的max日期中做比照。

最大的日期:{ max ([order date]) }

筛选

dayofyear = DATEPART(‘dayofyear’, {MAX([Order Date])} ) 258天

复杂计算场景,可视化关键,DEF函数筛选条件:[dayofyear] >= DATEPART(‘dayofyear’, [Order Date] )

计算2013年和2014年的累计汇总利润,以及2013年和2014年累计利润的差异,直接通过表计算可视化界面配置即可

FineBI复刻:

步骤:在自助数据集里获取年份、周数,然后按照年月、周数分组汇总,再按年累计汇总,最后行转列得到2014年和2013年的两列累计利润值,最后把累计值为空值的行过滤掉即可

复杂计算场景,可视化关键,DEF函数

组件里直接计算差异:${2014-按年累计汇总}-${2013-按年累计汇总}

复杂计算场景,可视化关键,DEF函数

点评:

不能像Tableau里用表计算直接算,略麻烦

场景13:用户登录频率

场景描述:

每月一次、每两月一次、每三月一次(依次类推)登录网站或应用程序的用户数目是多少?平均登录率是多少?这一平均值周围的分布偏斜如何?数据粒度为每个用户 ID 的登录日期。也就是说,用户登录的每一天都记录为一行。生成此视图需要按照登录率划分客户数,即我们必须按照某个度量划分另一个度量。我们在示例 1 中了解了如何使用详细级别表达式轻松进行此类分析。

可视化关键:

首次和二次登录的间隔,对应的用户数量

LOD范例:

首次和二次登录间隔,以及每个用户的登录次数。

首次登录日期+最近登录日期, fixed+min/max函数:{FIXED [User ID]:MIN([Log in Date])}、{FIXED [User ID]:MAX([Log in Date])}

计算上述两个日期的间隔,用datediff函数,同时参数定为month:DATEDIFF(‘month’,[首次登录日期],[最近登录日期])

计算每个用户的登录次数,fixed +countd:{FIXED[User ID]:COUNTD([Log in Date])}

计算每个用户的平均登录周期,间隔/次数:ROUND([间隔日期]/[每个客户的登录次数])

参考线,所有用户的平均登录周期:{EXCLUDE [平均登录周期]:AVG([平均登录周期])}

柱子的渐变颜色:AVG([平均登录周期])-AVG([所有用户的平均登录周期])

复杂计算场景,可视化关键,DEF函数

FineBI复刻:

首次登录日期+最近登录日期

计算两个日期的间隔月份:DATEDIF(${首次登录日期},${最近登录日期},”M”)

计算每个用户的登录次数:DEF(COUNTD_AGG(${Log in Date}),${User ID})

计算每个用户的平均登录周期

ROUND(${两个日期的间隔月份}/${每个用户的登录次数},0)

复制一个指标,其中一个转维度,用于图表,另一个保留参与后续计算

所有用户的平均登录周期:DEF_SUB(AVG_AGG(${每个用户的登录周期1}),${每个用户的登录周期1})

柱子的渐变颜色:AVG_AGG(${每个用户的登录周期1})-AVG_AGG(${所有用户的平均登录周期})

复杂计算场景,可视化关键,DEF函数

点评:

由于图表的限制,FineBI中柱形图图表只能是维度+指标,所以做不了竖着的参考线。同时指标转换成维度后,无法继续当做数值计算,所以需要复制一个值计算所有用户的平均登录周期。

场景14:成比例笔刷

场景描述:

任何分析中最基本的问题都是:“对比对象是什么?” 在筛选时,我们有时会需要对比所选内容和总量,而不是简单地向下筛选所选内容。这种技巧称为按比例笔刷。

可视化关键:

国家在每个分类的销售的占比

LOD范例:

全部的销售数量(聚合级别更高)

该子分类在所有国家的销售额:{Fixed [Sub-Category] : Sum([Sales]) }

占比:SUM([sales])/SUM([该子分类在所有国家的销售额])

复杂计算场景,可视化关键,DEF函数

FineBI复刻:

该子分类在所有国家的销售额:DEF(SUM_AGG(${Sales}),${Sub-Category})

占比:SUM_AGG(${Sales})/SUM_AGG(${该子分类在所有国家的销售额})

点评:

不能完全做到Tableau的效果,图表联动是明细过滤,所以不能像Tableau一样通过点击地图,动态显示每个国家的情况。同时,由于两个柱子不堆积重叠显示,另一个柱子单独显示也做不到,所以用了两个柱子并列+点图的组合图

场景15:各个客户阵列的年度购买频率

场景描述:

如果合作时间按争取到客户的年份度量,忠诚度按年度购买频率度量,那么合作时间越长的客户越忠诚吗?

从示例 1 中,我们可以精确了解购买过一次、两次(依次类推)的客户数目。然而,营销人员极少需要精确确定购买过五次产品的所有客户。相比之下,了解至少购买过五次产品的客户数目更有用。

另外,我们从示例 2 中了解到,2011 年争取到的客户最多,而 2014 年争取到的客户最少。查看客户的绝对数目只能再次了解同样的趋势。因此,我们应该将每个阵列的客户总额百分比作为度量忠诚度的标准,这样会更意义。

所以最初问题更具体的表达是,在每个阵列中在一年中购买过至少一次、两次、三次、N 次产品的客户所占的百分比是多少?

本示例结合了示例 1 中订单数详细级别表达式的变体、示例 2 中的阵列表达式和示例 4 中的总额百分比表达式的变体。

可视化关键:

筛选器:年度客户矩阵的累计合计的百分比,以购买频次为轴

LOD范例:

额外引用的背景数据:至少购买1次、2次、3次、n次的顾客数量、以及阵列(即顾客的获客年份)信息

每个客户最早的购买年份:{FIXED [Customer ID]: MIN(Year([Order Date]))}

每年每个客户的购买次数:{FIXED [Customer ID], [Order Date (Years)]: COUNTD([Order ID])}

至少购买1、2、n次的客户数:WINDOW_SUM( COUNTD([Customer ID]), 0, LAST())

每年的获客总人数:{ FIXED [每个客户最早的购买年份]:COUNTD([Customer ID])}

占比:[至少购买1、2、n次的客户数]/SUM([每年的获客总人数])

复杂计算场景,可视化关键,DEF函数

排除100%,因为当年购买的客户肯定至少购买过1次,这样可视化效果不受100%的干扰

FineBI复刻:

每个客户最早的购买年份:DEF( MIN_AGG(YEAR(${Order Date})),${Customer ID})

每年每个客户的购买次数:DEF(COUNTD_AGG(${Order ID}),[YEAR(${Order Date}),${Customer ID}])

至少购买1、2、n次的客户数:DEF_ADD(COUNTD_AGG(${Customer ID}),[],[${每年每个客户的购买次数1}>=EARLIER(${每年每个客户的购买次数1}),${每个客户最早的购买年份1}=EARLIER(${每个客户最早的购买年份1}),${Order Date (Years)}=EARLIER(${Order Date (Years)})])

每年的获客总人数:DEF(COUNTD_AGG(${Customer ID}),${每个客户最早的购买年份1})

占比:${组内累计}/${每年的获客总人数}

复杂计算场景,可视化关键,DEF函数

点评:

FineBI指标和维度的转换,指标计算完成后转换成维度,但是维度无法编辑,也不能参与计算,导致需要保留一个计算指标 + 一个指标转换后的维度,略显麻烦。

测评总结

作为BI产品资深用户,通过这次测评,老李我能明显发现,相较于目前国内其余BI产品,FineBI 6.0 的 DEF 函数在仪表板计算方面表现优秀,功能丰富且强大。

值得一提的是,FineBI内置了数据集功能,这不仅弥补了 DEF 函数在表处理方面的不足,还进一步增强了数据整理和准备能力。与之相对,Tableau 的 FIXED 函数虽然具有一定的计算能力,但缺少过滤能力,同时需要借助另一款名为 Tableau Prep 的工具来完成表处理操作,这带来了一定的阻碍。

不过正如开头所说,FineBI在各类功能细节处还需不断优化迭代,建议FineBI团队仍需踏实研究产品逻辑及用户习惯,期间还是有很多可改进及优化的地方,例如:

图表的灵活性:和Tableau对比,无法完成特殊的组合图和一些参考线的效果。

复杂函数书写:目前,在涉及组内排序、组内累计、跨行计算等场景下,函数的书写较为繁琐,需要将其封装成快速计算,以便业务人员更便捷使用。

DEF计算优先级问题:在仪表板中,DEF函数存在优先级问题。例如,在过滤组件和图表联动方面,明细过滤的机制使得部分结果过滤需在组件中配置。这会导致查看用户无法轻松地进行修改和调整。

指标计算转换为维度问题:在柱形图和折线图等情境中,指标计算完成后需要将其转换为维度。然而,维度却无法被编辑,因此再次转换回指标进行编辑。同时,维度也无法参与公式计算,这在某些情况下需要保留一个维度加一个指标的组合。

NULL处理问题:目前,在计算过程中,NULL值被视为当前日期,而非空值。这可能引发一些不准确的计算结果。

基础函数问题:部分基础函数存在缺陷,例如计算时间差缺乏季度参数,导致无法直接计算季度差,限制了一些时间相关计算的可能性。此外,在FineBI组件内部,周数的计算结果与某些函数所得到的周数结果不一致。DEF_ADD不支持MAX_AGG日期等。

最后,说一些心里话

由于前司工作原因,老李我很早就在使用FineBI了,因此与FineBI团队也有过数次用户研究及共创。因此,在文章发布前,我曾将文章草稿给到帆软FineBI产品团队共同研讨,他们表示:

“Tableau作为全球领先的BI软件,积累了丰富的经验和强大的功能集,深受众多企业的信赖和喜爱。而FineBI作为国产BI软件,与Tableau相比,我们FineBI团队清楚地认识到还存在一些技术和功能上的差距。但是,我们也并没有被差距所阻挡,我们反而将这些差距视为前进的动力,致力于持续地提升产品性能、用户体验和功能完整性。通过不断地听取用户的反馈意见,努力弥补产品中的不足之处,引入创新功能,优化性能,以便更好地满足用户的需求。”

而针对此次测评,我目前了解到的是FineBI团队已针对2、3、4问题完成设计优化,且其他问题产品也在持续关注中,听说在年末或明年年初能解决上述问题,这段期间不妨让我们共同静候国产BI的成长,给这个认真做产品的团队一些信心。

最后,如果你想体验FineBI的DEF函数功能,文末指路免费试用FineBI。

很显然在目前的信息时代,借助类似于FineBI的这些工具,可以让企业加速融入企业数据分析的趋势。备受市场认可的软件其实有很多,选择时必须要结合实际的情况。一般的情况下,都建议选择市面上较主流的产品,比较容易达到好的效果,目前企业数据分析BI软件市场占有率前列的,就是帆软BI软件——FineBI。

复杂计算场景,可视化关键,DEF函数

商业智能BI产品更多介绍: www.finebi.com

产品体验

相关内容

目录
立即体验 立即体验

商务咨询

在线咨询
专业顾问帮您解答问题

电话咨询

技术问题

投诉入口

微信咨询

返回顶部