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