产品

BI 产品开发过程中遇到的那些坑

Untitled Image

成功的经验不可复制,但失败的经验可以避免

BI 产品因为环节比较多,所以在开发过程中会有很多坑,这里总结一下踩过的坑。

Untitled Image

BI 系统环节虽然环节较多,但是总体可以划分为三部分:数据源、ETL 过程、产品设计。

1、数据源

  • 历史数据:历史数据的处理,向来是数据产品不可避免的一个问题,数据源系统重构,数据库结构字段发生了变化,都需要对历史数据进行整理;此外,也会遇到很多数据字段缺失的问题,比如某些数据未做记录,比如订单数据、商品数据等。这就需要,企业最开始时就要尽可能的考虑未来数据平台的设计,尽可能的记录所有数据。
  • 业务规范:业务不规范会导致数据源质量问题,例如部分业务未完全线上数据化,例如:唯品会平台的平台模式,退款退货时间较长,营收的计算准确性的问题。

2、ETL 过程

  • 数据抽取时间:ETL 一般的都会在凌晨执行任务,然后生成报表,手机端因为更加灵活,随时随地都可以看数据,当时我们设计了「昨日」这个日期选项,所以在 ETL 前后,对用户的迷惑比较大。
  • 源数据修改:如果第二天业务人员对源数据系统中的前一天或者某个时间点的数据进行了修改, ETL 需要及时更新数据仓库的数据。一般是业务人员通知技术,人工调整。

3、产品设计

  • 缓存机制 :为了减轻服务端的压力,在 APP 和服务端中间加了一层数据缓存,用户打开 APP 去读取缓存的数据,缓存会在每天的固定时间失效,会遇到的一个问题就是,如果数据仓库的数据在缓存建立之后发生了变化,缓存数据会不准确,缓存更新就需要一个触发机制,可以是定时,或者是在缓存和服务端建立一个触发更新缓存的机制。

Untitled Image

  • 多端产品设计:web 和 APP 独立开发的情况下,当某一个指标的计算公式或者是某个指标对应的字段发生变化时,就需要 web和 app 的产品经理及时通知,进行统一,如果是同一个产品经理、统一报表,或者 APP 是 web 进行自适应嵌套的,就不会出现这个问题。

  • 数据准确性校验:所有的程序运行过程中基本都会出现问题, ETL 抽取数据过程中,故障的发生率是最高的,这就需要在数据报表更新后,查看数据的准确性,如果出现异常需要提前告知用户,一般的通过人工校验,当然效率是比较低的,最理想的是对核心指标进行设置阈值监控,通知到产品运营对于异常数据进行排查。此外,对于单个卡片有异常的情况,数值不准确的这种,需要配置可隐藏显示的管理选项。

愿:天下无坑

Advertisement
1
Standard