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

　　当原有产品无法满足当前业务发展时，有时候我们会通过改动表格中的字段设计满足业务新需要、服务新场景。而改动数据表格的字段很容易引发数据冲突的情况，所以我们有必要去解决表格改变字段后产生的数据冲突，去兼容历史数据，减少改动对数据产生的负面影响。那么问题来了，我们该怎么去兼容历史数据呢？
　　业务是不断变化发展的，产品也是会随之不停迭代的，数据表格作为基本组件也常常需要变动，这在我们的日常工作中是非常常见的。
　　比如下面这个例子，一款分析淘宝商家移动端店铺数据的产品，其中菜单流量来源是对店铺流量的分析，在店铺发展初期淘内免费、付费流量、自主访问能够支撑业务方对于店铺数据的分析，但是随着店铺业务不断发展做大做强，对于流量分析的颗粒度要求越来越细，只是对流量的简单划分已经无法满足业务方的需求。希望能对于淘内流量能有更细的分类，帮助业务方对店铺流量有更细致的了解，从而根据不同流量大小调整运营策略，促进店铺销售数据的发展。
　　现状：淘内免费付费流量自主访问
　　期望：手淘搜索我的淘宝淘内免费其他手淘微淘手淘扫一扫等
　　需求：改动流量来源数据表格中的字段
　　当原有产品无法满足当前的业务发展时，为了满足业务的新需要，服务于新的场景。不得不要求我们去改变最初的产品设计，改动表格中的字段设计。而改动数据表格的字段很容易引发数据冲突的情况，包括数据类型冲突、数据格式冲突等。
　　如果在改动表格字段时，不去考虑数据冲突的影响，不去考虑如何兼容历史数据，会导致产品内的数据在完整性和一致性上出现问题，比如上文中案例如果不进行历史数据兼容处理，选择在3。19号上线新的统计功能，关于流量的划分就会存在两种不一样的统计方式，19号前的流量数据划分方式和19号之后不一致，按月维度下没有办法对3月的流量数据做一个统一划分。
　　历史数据一定意义上成为了脏数据，有句话说的好叫垃圾数据进垃圾数据出，数据质量对于分析结果的重要性甚至高于分析方式和模型。混入脏数据后产出的结果对业务造成严重的影响，甚至做出了错误的决策，带来不可磨灭的损失
　　因此，我们有必要去解决表格改变字段后产生的数据冲突，去兼容历史数据，减少改动对数据产生的负面影响。那么问题来了，我们该怎么去兼容历史数据呢？
　　01历史数据都是需要保留的吗
　　表格改变字段出现数据冲突的情况后，在我们去兼容历史数据之前可以先思考一个问题：历史数据都是需要保留的吗？一起来看下下面的两个场景。
　　场景1
　　某电商tob产品，在一次迭代中，对店铺销售菜单增加了客单价字段，那么历史数据中的客单价对我们有意义吗？
　　场景2
　　我们设计了一套问卷用于统计国内大学生的不同专业的就业情况，投放问卷一段时间后对问题就行了修改，那么收集的历史数据对我们还有意义吗？
　　通过两个具体的场景，我们可以发现历史数据在不同的场景下的保留策略是不同的：
　　场景1中的客单价能帮助复盘店铺历史的客单价情况，和当前时间的客单价进行对比，对店铺策略起到数据指导作用，在此场景下历史数据具有重要意义，需要保留。
　　而场景2中收集的你的国家是什么和场景题干国内大学生矛盾，问卷的修改也是为了解决这一矛盾才修改题目的，所以该题目收集来的历史数据无效，不需要保留可以直接废弃。
　　历史数据是对过去业务情况的记录和反馈，但并不是所有的历史数据都是有意义的，也不是所有历史数据都需要保留的。当需要考虑历史数据兼容问题前，建议先从实际的场景出发去分析一下历史数据对于业务的价值和意义，如果关联不大或者本身就是错误的数据，直接废弃历史数据就OK了。对于要保留的历史数据，才需要去考虑冲突在哪里，以及怎么去兼容
　　02怎么去兼容历史数据
　　在我们思考了历史数据的价值和意义之后，确定要保留历史数据，那么我们怎么去兼容历史数据呢？首先，我们需要区分不同的数据表格改变方式，会带来怎么样的数据冲突，再根据不同的冲突情况去提出相对应的兼容方案
　　1。增加字段
　　我们经常会遇到在表格上增加字段的情况，比如增加了新的业务字段，增加了新的统计项。
　　如果不做兼容处理，就会出现增加的字段有增加后的新数据，但是没有历史数据。这种情况下，需要我们判断历史数据能否被补全，若能，则补全历史数据；若无法补全，新增的字段历史数据空白展示。
　　2。减少字段
　　当出现减少字段的情况，如果不做处理，会出现减少的字段没有新数据，但是有历史数据。这种情况下，我们的处理方式是保留历史数据，减少统计后该字段空白展示。
　　3。原字段统计逻辑或规则改变
　　统计逻辑或规则被改变时，不进行数据兼容的话，因为新数据和历史数据的统计方式不一致，会导致数据结果出现差异。这个时候，需要我们去判断历史数据能否按新的统计逻辑换算，若能，则按新逻辑重新统计；若不能保留历史数据，并记录统计逻辑的改变记录。
　　4。原字段下钻或合并统计
　　这种改变会出现新字段和历史字段是包含或者被包含的关系，需要我们去补全历史数据，比如字段A被下钻成了新字段B新字段C，根据下钻规则补全新字段B和C的历史数据值。
　　而在实际的场景中，数据冲突会同时存在多种，所采用的方案也是多个解决手段组合的。
　　比如下面这个案例，我们对客户管理模块进行迭代，通过调研发现内部销售团队希望能在客户管理菜单中增加客户微信字段，并提供根据客户等级自动计算出下次回访时间，为此我们对客户管理的字段进行了调整。
　　表格改动为：增加客户微信、下次回访时间字段，减少创建时间字段。这里就涉及到了增加字段和减少字段两种情况，通过分析客户微信和下次回访字段对存量客户具有重要意义，收集到客户的微信联系方式和具体的回访时间，方便业务员展开业务，两个字段的数据也有被补全的条件；而减少的创建时间字段对于业务影响不大，可以废弃。基于上面的考虑，我们对客户管理菜单做了如图处理。
　　迭代发布上线后，产品同学提出下次回访时间直接展示时间，对销售团队来说不够直观，可以对下次回访时间进一步处理，更加直接明了，因为下次回访时间字段中原有的时间格式是支持现在的规则换算的，就可以对时间进行了换算处理。
　　对下次回访时间的展示进行处理，计算下次回访时间和当前时间的差值：
　　原统计格式：yyyymmdd
　　新统计格式：X天后回访；已过期X天
　　随着业务的发展又遇到了字段统计逻辑和规则无法转化的情况，客户管理中意向产品的可选项从商品1，商品2，商品3变成了商品5，商品6，商品7，改动前后的数据没有办法去简单的进行兼容，而前后数据对于业务来说都是具有意义的，那么我们需要在保留两者数据格式的前提下，做一些文案上的提示，例如在操作日志记录系统对于规则的更改。
　　从上面这个案例中我们发现，表格的变动不单单只有出现一种冲突，我们采取的解决方案也是多样的。
　　03兼容历史数据的价值和场景
　　表格字段的改动会导致历史数据和改动后数据的冲突，而数据冲突会导致在产品层面的数据没有连贯性，进一步导致了用户无法理解前后数据，对产品产生了疑问，以至于产生了负面情绪。
　　简单的对表格字段进行增减，对于用户的影响相对于较少，降低了用户对数据的可读性，比如上文案例中增加减少字段，不做处理的话，用户会对部分情况有数据部分情况无数据产生疑惑增加了理解成本。
　　但是对于更改统计逻辑的，就不只是简单用户体验上的问题了，会给业务带来实际的影响，比如上文中意向产品中可选择的产品变更了，如果不及时对于历史数据进行兼容，做相关的变动说明处理，很容易给业务员带来之前的商品仍然可以进行销售的误判，最终导致下错订单甚至下单后无法发货，给公司业务带来实质的亏损
　　由此可见，兼容历史数据的价值，在于解决这一系列的数据冲突，既保证了产品层面的数据连贯性，也让用户了解到数据变动的原因，降低了用户的负面情绪和理解成本。更重要的是，不仅可以能帮助用户复盘业务情况，对业务起到指导作用，而且避免事故和损失的发生
　　但是兼容历史数据也不是在所有场景都适用的，当我们涉及到的改动非常大的时候，比如业务发生巨大的变化导致原有表格字段全部推翻重新设计时，就不建议采用上文的兼容方案，可以选择新老数据交替过渡，原有的表格提供对老数据的支持，新建一个表格用于支持新字段的展示，通过这种方式，完成从历史存量业务到新业务的过渡；又比如整体项目需要重构，可以选择数据迁移方案
　　现在当我们再次遇到历史数据冲突需要兼容的情况时，可以判断如何选择了吗？