表格改变字段时,该如何兼容历史数据?

业务是不断变化发展的,产品也是会随之不停迭代的,数据表格作为基本组件也常常需要变动,这在我们的日常工作中是非常常见的。

比如下面这个例子,一款分析淘宝商家移动端店铺数据的产品,其中菜单“流量来源”是对店铺流量的分析,在店铺发展初期“淘内免费”、“付费流量”、“自主访问”能够支撑业务方对于店铺数据的分析,但是随着店铺业务不断发展做大做强,对于流量分析的颗粒度要求越来越细,只是对流量的简单划分已经无法满足业务方的需求。希望能对于淘内流量能有更细的分类,帮助业务方对店铺流量有更细致的了解,从而根据不同流量大小调整运营策略,促进店铺销售数据的发展。

  • 现状:淘内免费 付费流量 自主访问
  • 期望:手淘搜索 我的淘宝 淘内免费其他 手淘微淘 手淘扫一扫等
  • 需求:改动“流量来源”数据表格中的字段

当原有产品无法满足当前的业务发展时,为了满足业务的新需要,服务于新的场景。不得不要求我们去改变最初的产品设计,改动表格中的字段设计。而改动“数据表格”的字段很容易引发数据冲突的情况,包括数据类型冲突、数据格式冲突等。

如果在改动表格字段时,不去考虑数据冲突的影响,不去考虑如何兼容历史数据,会导致产品内的数据在完整性和一致性上出现问题,比如上文中案例如果不进行历史数据兼容处理,选择在3.19号上线新的统计功能,关于流量的划分就会存在两种不一样的统计方式,19号前的流量数据划分方式和19号之后不一致,按月维度下没有办法对3月的流量数据做一个统一划分。

历史数据一定意义上成为了“脏数据”,有句话说的好叫“垃圾数据进垃圾数据出”,数据质量对于分析结果的重要性甚至高于分析方式和模型。混入脏数据后产出的结果对业务造成严重的影响,甚至做出了错误的决策,带来不可磨灭的损失

因此,我们有必要去解决“表格改变字段”后产生的数据冲突,去兼容历史数据,减少改动对数据产生的负面影响。那么问题来了,我们该怎么去兼容历史数据呢?

01 历史数据都是需要保留的吗

表格改变字段出现数据冲突的情况后,在我们去兼容历史数据之前可以先思考一个问题:历史数据都是需要保留的吗?一起来看下下面的两个场景。

场景1

某电商to b产品,在一次迭代中,对“店铺销售”菜单增加了“客单价”字段,那么历史数据中的客单价对我们有意义吗?

产品经理,产品经理网站

场景2

我们设计了一套问卷用于统计“国内大学生的不同专业的就业情况”,投放问卷一段时间后对问题就行了修改,那么收集的历史数据对我们还有意义吗?

产品经理,产品经理网站

通过两个具体的场景,我们可以发现“历史数据”在不同的场景下的保留策略是不同的:

场景1中的“客单价”能帮助复盘店铺历史的客单价情况,和当前时间的“客单价”进行对比,对店铺策略起到数据指导作用,在此场景下历史数据具有重要意义,需要保留。

而场景2中收集的“你的国家是什么”和场景题干“国内大学生”矛盾,问卷的修改也是为了解决这一矛盾才修改题目的,所以该题目收集来的历史数据无效,不需要保留可以直接废弃。

历史数据是对过去业务情况的记录和反馈,但并不是所有的历史数据都是有意义的,也不是所有历史数据都需要保留的。当需要考虑历史数据兼容问题前,建议先从实际的场景出发去分析一下“历史数据”对于业务的价值和意义,如果关联不大或者本身就是错误的数据,直接废弃历史数据就OK了。对于要保留的历史数据,才需要去考虑冲突在哪里,以及怎么去兼容

02 怎么去兼容历史数据

在我们思考了历史数据的价值和意义之后,确定要保留历史数据,那么我们怎么去兼容历史数据呢?首先,我们需要区分不同的数据表格改变方式,会带来怎么样的数据冲突,再根据不同的冲突情况去提出相对应的兼容方案

1. 增加字段

我们经常会遇到在表格上“增加字段”的情况,比如增加了新的业务字段,增加了新的统计项。

如果不做兼容处理,就会出现增加的字段有增加后的新数据,但是没有历史数据。这种情况下,需要我们判断历史数据能否被补全,若能,则补全历史数据;若无法补全,新增的字段历史数据空白展示。

产品经理,产品经理网站

2. 减少字段

当出现“减少字段”的情况,如果不做处理,会出现减少的字段没有新数据,但是有历史数据。这种情况下,我们的处理方式是保留历史数据,减少统计后该字段空白展示。

产品经理,产品经理网站

3. 原字段统计逻辑或规则改变

统计逻辑或规则被改变时,不进行数据兼容的话,因为新数据和历史数据的统计方式不一致,会导致数据结果出现差异。这个时候,需要我们去判断历史数据能否按新的统计逻辑换算,若能,则按新逻辑重新统计;若不能保留历史数据,并记录统计逻辑的改变记录。

产品经理,产品经理网站

4. 原字段下钻或合并统计

这种改变会出现新字段和历史字段是包含或者被包含的关系,需要我们去补全历史数据,比如字段A被下钻成了新字段B+新字段C,根据下钻规则补全新字段B和C的历史数据值。

产品经理,产品经理网站

而在实际的场景中,数据冲突会同时存在多种,所采用的方案也是多个解决手段组合的。

比如下面这个案例,我们对“客户管理”模块进行迭代,通过调研发现内部销售团队希望能在“客户管理”菜单中增加“客户微信”字段,并提供根据客户等级自动计算出“下次回访时间”,为此我们对“客户管理”的字段进行了调整。

产品经理,产品经理网站

表格改动为:增加“客户微信”、“下次回访时间”字段,减少“创建时间”字段。这里就涉及到了“增加字段”和“减少字段”两种情况,通过分析“客户微信”和“下次回访”字段对存量客户具有重要意义,收集到客户的微信联系方式和具体的回访时间,方便业务员展开业务,两个字段的数据也有被补全的条件;而减少的“创建时间”字段对于业务影响不大,可以废弃。基于上面的考虑,我们对“客户管理”菜单做了如图处理。

产品经理,产品经理网站

迭代发布上线后,产品同学提出“下次回访时间”直接展示时间,对销售团队来说不够直观,可以对“下次回访时间”进一步处理,更加直接明了,因为“下次回访时间”字段中原有的时间格式是支持现在的规则换算的,就可以对时间进行了换算处理。

对“下次回访时间”的展示进行处理,计算“下次回访时间”和当前时间的差值:

  • 原统计格式:yyyy-mm-dd
  • 新统计格式:X天后回访;已过期X天

产品经理,产品经理网站

随着业务的发展又遇到了“字段统计逻辑和规则无法转化”的情况,“客户管理”中“意向产品”的可选项从“商品1,商品2,商品3”变成了“商品5,商品6,商品7”,改动前后的数据没有办法去简单的进行兼容,而前后数据对于业务来说都是具有意义的,那么我们需要在保留两者数据格式的前提下,做一些文案上的提示,例如在操作日志记录系统对于规则的更改。

从上面这个案例中我们发现,表格的变动不单单只有出现一种冲突,我们采取的解决方案也是多样的。

03 兼容历史数据的价值和场景

表格字段的改动会导致历史数据和改动后数据的冲突,而数据冲突会导致在产品层面的数据没有连贯性,进一步导致了用户无法理解前后数据,对产品产生了疑问,以至于产生了负面情绪。

简单的对表格字段进行增减,对于用户的影响相对于较少,降低了用户对数据的可读性,比如上文案例中增加减少字段,不做处理的话,用户会对部分情况有数据部分情况无数据产生疑惑增加了理解成本。

但是对于更改统计逻辑的,就不只是简单用户体验上的问题了,会给业务带来实际的影响,比如上文中意向产品中可选择的产品变更了,如果不及时对于历史数据进行兼容,做相关的变动说明处理,很容易给业务员带来之前的商品仍然可以进行销售的误判,最终导致下错订单甚至下单后无法发货,给公司业务带来实质的亏损

由此可见,兼容历史数据的价值,在于解决这一系列的数据冲突,既保证了产品层面的数据连贯性,也让用户了解到数据变动的原因,降低了用户的负面情绪和理解成本。更重要的是,不仅可以 能帮助用户复盘业务情况,对业务起到指导作用,而且避免事故和损失的发生

但是兼容历史数据也不是在所有场景都适用的,当我们涉及到的改动非常大的时候,比如业务发生巨大的变化导致原有表格字段全部推翻重新设计时,就不建议采用上文的兼容方案,可以选择新老数据交替过渡,原有的表格提供对老数据的支持,新建一个表格用于支持新字段的展示,通过这种方式,完成从历史存量业务到新业务的过渡;又比如整体项目需要重构,可以选择数据迁移方案

现在当我们再次遇到历史数据冲突需要兼容的情况时,可以判断如何选择了吗?

产品经理,产品经理网站

 

本文作者 @晌午 。

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部