在分析工具选择上，企业具备以下特点可优先选UBA：
1.尚未建立独立的分析师团队，无专业的数据工程师。
2.希望加强业务人员的数据能力，提高数据效率。即让业务人员快速进行自主分析，加快业务决策，而不是所有需求都提给专门的BI团队。
3.希望以快速、低门槛的方式进行精准的时序性统计分析、探索性分析、动态分析、关联分析等。比如花几十秒就可以搭建分析模型并灵活下钻，进而判断一个客户是否为忠实客户。
4.注重用户的精细化运营，分析的核心诉求是改进用户体验、实现业务增长。
UBA（用户行为分析工具）出现之前，企业在进行数据分析时通常会用BI（商业智能）工具辅助业务决策。UBA的出现改变了数据分析的方式，其低代码的产品设计极大降低了分析门槛并提高了分析效率，成为数据分析领域的宠儿。
随着全行业数字化转型步入深水区，越来越多数字化能力薄弱的企业入局，他们在采购数据分析工具时因为不清楚个中差异，经常面临“UBA or BI”的选择困难。
UBA和BI都能全面覆盖数据分析过程中的各个环节，包括数据集成、清洗、整合、存储、计算、建模、分析表达、展现、协作等，让用户可以在一个统一的平台上完成全流程数据分析任务。
在进行业务指标监控即“KPI监控”时，二者在结果输出上给企业决策者呈现的效果基本一致。
不同的是背后的分析方法。
UBA有内置的数据模型，天然更擅长动态和关联分析，对分析能力薄弱的业务人员比较友好，同时还具备数据采集能力。BI的各个流程都需要数据开发工程师或高阶分析师的介入，比较适合做静态指标的监测分析。
业务人员在用BI进行数据分析时需要先向BI团队提出分析需求，然后BI分析师和数开人员再按照“设想分析思路——进行相关的数据拆解——定位数据字段——进行中间表的创建——创建报表”的流程，产出可视化报告交付给业务人员，整个流程最短要一周完成。
而用UBA，业务人员通过规则配置搭建看板即可完成计算，整个过程只需30秒，即便是海量数据也能秒级出数，方便业务人员实时监测。
两种工具业务分析效率的差异源于设计理念的不同：
UBA 面向用户，BI 面向指标
BI起源于美国，是数据基础设施从数据库到数据仓库衍进的产物，其研发初衷是为满足企业财务人员的报表需求，让数据分析支持业务决策，因此在产品设计上主要围绕“指标监控”进行。BI的本质是报表平台，适合明确至某一时间点的静态统计和核心指标的日常监控、汇报。
要想使用BI进行业务指标监测，需要企业具备专业的分析师团队和数开团队。同时，BI的专业性和明确的需求导向，让它很难承载高业务量下的数据分析需求。
GrowingIO服务过的某初创互联网公司的BI总监曾分享过自己的心得：“在业务发生井喷的情况下，12个人，或者20个人，甚至50个人的数据团队，也是没办法应付公司所有的业务分析需求的，所以在不同的阶段，需要推动不同的分析方式。”
当企业的业务量级达到一定程度，业务人员的自助式分析更为必要。“整个BI团队12个人，需要去支撑整个公司上千人的团队已经很困难。我们只能把数据分析的职能下放，做到去中心化。”
*企业决策正面临从人类做决策到机器做决策的鸿沟，
从人力投入与使用场景来看，BI工具可能更适合进行一维、二维的简单分析。
比如在进行原始数据的收集和清洗时，这家互联网公司BI团队中的数据仓库部门发现：对初创型的公司来讲，这个工作花费的人力实在太大了。
结果是：经过评估，他们最终选择使用GrowingIO的UBA产品来获取实时全量的用户行为数据，然后再由商业分析部门进行分析。
在有BI团队的前提下，一家企业尚且需要UBA做辅助，对本不具备分析师团队的传统企业而言，通过搭建BI团队实现自助式分析的难度系数更高。
UBA的出现极大缓解了这种尴尬。它的设计指向为“对用户数据的分析”，因为用户是企业大数据最大也是最重要的来源，同时还是企业最终要服务的对象，因此UBA上业务指标的监控也是围绕用户进行，分析范围更垂直，使用门槛也更低。
在和BI重叠的“KPI监控”部分，UBA主要通过内置的分析模型实现。比如GrowingIO的增长分析（UBA）目前有20大分析模型，覆盖用户行为分析、用户分析、产品分析。相比BI在交互方式上对使用者专业性的高要求，使用UBA的企业无需搭建“分析师/数开”团队，业务人员通过简单勾选的方式即可快速构建分析模型。
同时，UBA内每个分析模型的设计均有独特且最匹配的分析场景，如事件分析的自由下钻探索、漏斗分析的不同时期对比、留存分析的黄金拐点、首购复购的时间间隔、LTV分析的营收平衡点等，分析快速且高效。
GrowingIO增长分析（UBA）的20大分析模型
能对分析进行实时优化和能快速进行探索性、动态、时序性的分析是UBA有别于BI工具的核心能力。
深层探究，是二者运用的底层技术能力的差异。
UEI模型 VS 维度建模
讨论UBA和BI的底座技术能力之前，我们需要先明确数据分析的底层技术是如何实现的：数据库中的各项数据以维度建模的方式加工处理成原子指标后，才能存储在数据仓库中，然后分析师和数开人员再通过写SQL的方式从中调取数据，形成用户表、事件表、实体表等各类表，进行分析处理。
所以维度建模是UBA和BI进行分析的重要手段和前提。不同的是，UBA内置的UEI模型（User、Event、Item）可以替代分析师和数开人员，从数仓诸多表中调取用户表、事件表、实体表三张表，并动态表达出一张宽视图，基于该视图上层可搭建各类分析模型，业务人员只需要根据需求选择不同的分析模型进行简单的规则配置即可搭建看板进行分析。
比如同样进行用户忠诚度分析，必不可少的是分析“复购率”。假设新用户中有10%发生了首购，首购用户中有25%发生了二购，但七购、八购的用户，可能有90%持续复购。找到这个稳定高位复购率的购买次数（也被称为“魔法数字”），就能找到品牌忠诚用户的最低阈值，从而对这部分用户进行精细化运营。
如果这个分析由BI来实现，需要业务人员先向BI团队提出“找到魔法数字”的需求，然后BI团队会通过数据准备——数据验证——BI设计及上线的过程实现。
数据准备阶段，数开人员要进行一系列维度建模构建各类表，不算原始数据准备的对接工作量，仍需进行CDM层（构建事实表和维度表）、ADS层（根据维度预聚合）的开发，同时这个场景还要连续计算n购的人中有多少发生了n+1购买，所以维度聚合的开发工作量会大大增加，预计会有3—5天的开发周期，待开发完成后，还需要进行指标的准确性验证，最终由分析师进行看板PRD（产品需求文档）的设计，及实际的搭建工作，才能给到业务人员进行分析。
UBA和BI的底层技术差异
这种刀耕火种的原始工作不但繁重而且效率低，准确性也不可控，大量交叉查询还容易导致系统出现性能问题。
相较之下，UEI模型则促进了分析工作的工业化大生产，数开人员不用再将精力花费在业务数据源的哪个表、哪个字段抓取后进入到哪个对应的表里。
业务人员通过规则配置搭建看板即可看到“魔法数字”，整个过程不到一分钟就能完成，不但大大降低了数开人员的工作难度，提升了工作效率，还能适应高业务量。
当然，UEI并不是万能的，它只从数仓中调取了用户表、事件表、实体表三个表的数据，而BI是直接从数仓中根据需求取数，所以可调取的数据指标更多元，除了UEI模型涵盖的三张表，还可以调取ERP、人力资源、财务等其他数据，实现多主体分析，扩展性更强。
和BI不断降低使用门槛的智能化迭代趋势类似，UBA也正在向多主体分析方向上迭代，从UBA衍进为XBA，相应的，底层的UEI模型也正在向XEI模型迭代，尝试囊括更多BI的多主体分析能力。
未来，不管是UBA、BI，还是其他分析工具，降低分析门槛、提升分析效率都是产品迭代的大趋势，GrowingIO的增长分析平台（UBA）也将在扩展性上做出更多努力，帮助更多数字化能力薄弱的企业具备数据驱动增长的能力。
