表格改变字段时该如何兼容历史数据
⇨⇦
当原有产品无法满足当前业务发展时，有时候我们会通过改动表格中的字段设计满足业务新需要、服务新场景。而改动＂数据表格＂的字段很容易引发数据冲突的情况，所以我们有必要去解决＂表格改变字段＂后产生的数据冲突，去兼容历史数据，减少改动对数据产生的负面影响。那么问题来了，我们该怎么去兼容历史数据呢？
业务是不断变化发展的，产品也是会随之不停迭代的，数据表格作为基本组件也常常需要变动，这在我们的日常工作中是非常常见的。
比如下面这个例子，一款分析淘宝商家移动端店铺数据的产品，其中菜单＂流量来源＂是对店铺流量的分析，在店铺发展初期＂淘内免费＂、＂付费流量＂、＂自主访问＂能够支撑业务方对于店铺数据的分析，但是随着店铺业务不断发展做大做强，对于流量分析的颗粒度要求越来越细，只是对流量的简单划分已经无法满足业务方的需求。希望能对于淘内流量能有更细的分类，帮助业务方对店铺流量有更细致的了解，从而根据不同流量大小调整运营策略，促进店铺销售数据的发展。
现状：淘内免费 付费流量 自主访问
期望：手淘搜索 我的淘宝 淘内免费其他 手淘微淘 手淘扫一扫等
需求：改动＂流量来源＂数据表格中的字段
当原有产品无法满足当前的业务发展时，为了满足业务的新需要，服务于新的场景。不得不要求我们去改变最初的产品设计，改动表格中的字段设计。而改动＂数据表格＂的字段很容易引发数据冲突的情况，包括数据类型冲突、数据格式冲突等。
如果在改动表格字段时，不去考虑数据冲突的影响，不去考虑如何兼容历史数据，会导致产品内的数据在完整性和一致性上出现问题，比如上文中案例如果不进行历史数据兼容处理，选择在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 兼容历史数据的价值和场景
表格字段的改动会导致历史数据和改动后数据的冲突，而数据冲突会导致在产品层面的数据没有连贯性，进一步导致了用户无法理解前后数据，对产品产生了疑问，以至于产生了负面情绪。
简单的对表格字段进行增减，对于用户的影响相对于较少，降低了用户对数据的可读性，比如上文案例中增加减少字段，不做处理的话，用户会对部分情况有数据部分情况无数据产生疑惑增加了理解成本。
但是对于更改统计逻辑的，就不只是简单用户体验上的问题了，会给业务带来实际的影响，比如上文中意向产品中可选择的产品变更了，如果不及时对于历史数据进行兼容，做相关的变动说明处理，很容易给业务员带来之前的商品仍然可以进行销售的误判，最终导致下错订单甚至下单后无法发货，给公司业务带来实质的亏损
由此可见，兼容历史数据的价值，在于解决这一系列的数据冲突，既保证了产品层面的数据连贯性，也让用户了解到数据变动的原因，降低了用户的负面情绪和理解成本。更重要的是，不仅可以 能帮助用户复盘业务情况，对业务起到指导作用，而且避免事故和损失的发生
但是兼容历史数据也不是在所有场景都适用的，当我们涉及到的改动非常大的时候，比如业务发生巨大的变化导致原有表格字段全部推翻重新设计时，就不建议采用上文的兼容方案，可以选择新老数据交替过渡，原有的表格提供对老数据的支持，新建一个表格用于支持新字段的展示，通过这种方式，完成从历史存量业务到新业务的过渡；又比如整体项目需要重构，可以选择数据迁移方案
现在当我们再次遇到历史数据冲突需要兼容的情况时，可以判断如何选择了吗？