在b端产品中，会提供用户自定义设置的选项，用户可以根据实际的业务场景进行自定义配置，但是业务是动态变化的，当设置的配置项已经无法满足现在的业务时，用户就会去调整配置项。
举个例子，房产中介公司A对于“优质客户”的回访有统一要求，要求在优质客户咨询后当天就进行回访，为此在“某会员管理系统”中设置了H类客户（H类客户，即优质客户）下次回访时间：0天。
方便提醒销售人员进行跟进，但实行该规定一段时间后，收到了用户大量的投诉，用户认为受到了骚扰，为此A公司修改了下次回访时间的设置，从0天改成了3天。
这里就是“下次回访时间”配置项最初设置的值和实际的业务场景发生了冲突，0天导致了用户投诉，从而产生了一次配置项的改动，而配置项改动后也会带来一个问题，产品数据应该如何变化呢？本文就想和大家讨论这个问题。
考虑影响数据范围
当“配置项”被用户改动后，我们首先应该考虑数据的影响范围，假设“配置项”规则改动的时间节点为X，那么我们的数据范围就会被划分为两个部分，在时间线上以X作为时间分割点，X左边即发生在X之前时间，所产生的数据结果即为历史数据；X右边即发生在X之后时间，所产生的数据即为未来数据。
一起通过房产中介公司A的案例来验证一下，A公司设置的“下次回访时间”为0天，但由于陆续受到很多用户的投诉，因此A公司修改了“下次回访时间”为3天。
那么房产中介公司在4月份登记的优质客户A、B、C和5月份登记的优质客户D、E、F分别属于什么数据范围呢？
这里5月1日是在时间线上的一个分割点，在这一天A公司修改了“下次回访时间”的配置项，那么优质客户A、B、C就属于是历史数据范围，而优质客户D、E、F就属于未来数据范围。
A公司优质客户生成时间范围
了解影响范围后，就能推导出“配置项”改动是否会影响数据变动了，通常我们认为，“配置项改动”会影响未来数据，而不影响历史数据
因为从时间线上看，未来数据所产生的结果，晚于“配置项”规则的修改，所以会以新规则统计，就像优质客户D、E、F是在“下次回访时间”规则改动后产生的数据结果，就需要以最新的规则来统计回访日期，而历史数据所产生的结果，是已经发生存在的，不需要以最新的规则来统计
那么事实真的如此吗？
会改变历史数据的场景
未来数据，在“配置项改动”后需要发生变化，是毋庸置疑的，而历史数据在某一些特殊的场景下，才会发生变化。
1. 什么是历史数据
对于历史数据，我们先来看下这个历史数据，2021年我26岁，那么从2022年，2023年的时间视角看，不管发生了什么，2021年我26岁都是一个既定事实，26岁这个“数据”就是历史数据，是已经发生的数据，不会随着其他条件的改变而发生改变，这就是1个历史数据。
什么是历史数据？是过去的、已经存在的的数据结果，从时间线上看早于现在发生的。这也是为什么我们会认为“历史数据”一般不会受到“配置项改动”而改变
另外，改变历史数据的影响非常大，例如19年我在某品牌的积分对应该品牌的白金会员，但在20年因疫情影响调整了会员等级和积分的对应关系，这时我的积分对应了该品牌的致悦会员，如果调整历史数据，就会涉及到会员权益的问题，需要补偿19年白金和致悦之间的权限差异。
所以呢，通常改动历史数据是比较少见的，也是需要慎之又慎的。但是在一些特殊的场景下，必须要对“历史数据”进行改动。
第一种是受制于历史数据产生时的条件不成熟；第二种是因历史数据结果产生早于了“配置项”的产生，下面就让我们一起看下具体的场景吧。
2. 历史条件不成熟
这一种场景是比较罕见的，主要是受制于历史数据产生时的条件影响，包括当时条件不成熟、当时环境约束等无法改变的客观原因，而随着社会和人类的进步，在当下能做出更准确的判断了，才会对历史数据进行变动。
例如国家对于法律误判的补偿，就是1个典型受制于历史数据条件的案例，这里的历史数据是产生时间点的技术、侦查或证据等客观原因而作出的法律判决，出现误判的原因是当时客观条件的不足或者不充分导致的。
而在当下这个时间点客观条件的改变，例如更有力证据的检出等，在新老客观条件的冲突下，导致了误判的产生。
由于历史判决在当下时间点，已经变得不再合适，如果不对此进行改动，会产生有失公平公正的不良影响，而改变历史判决作出合适的新判决，并对于当事人作出补偿的方式，也是一种保障人权的体现，因此需要在当下结合新的客观条件，做出更合适的判决。
3. 历史数据结果早于配置项产生
第二种场景是相对比较常见的，是由于数据结果早于配置规则导致的，一般的，数据结果是在配置规则后产生的，先有规则才能产出具体的数据结果。
当数据结果早于配置规则时，就会出现冲突，当配置规则未产生时，数据结果是按原有规则进行统计的；当配置项规则产生后，数据结果需要遵循新的规则进行统计，新旧规则的冲突就导致了历史数据发生了变动。
国家的退税，就是一个典型案例，在3月年度汇算的时候，因政策变动、人为规则改变（增加抵扣专项等）等原因导致需要重新对个税进行计算。
再举个例子，某公司考核方案是对员工kpi分数进行等级划分，不同等级对应了不同的绩效和晋升，2020年的A、B、C等级划分人数比例是2:7:1。假设2021年的kpi分数产出后，公司考虑增加A、C两个等级的比例，从而让员工具有进取精神和紧张感，修改后的等级划分人数比例为A:B:C = 3:5:2。
这里就出现了数据结果出现早于配置规则，在新的等级人数划分规则未出现时，是按2020年的等级划分人数规则进行划分的，而当新的人数划分规则出台后，原有的kpi定级就需要进行重新评定了。
4. 应对的产品方案
在实际业务中，“客观条件不成熟”的场景是相对罕见的，而“数据结果早于配置规则产生”的场景，就比较容易发生。
在该场景下如果不改变历史数据所带来的影响是十分严重的，按原有规则产生的数据对于当下采用新规则来说，是没有意义的，那么对于“需要改动历史数据”的场景我们该以怎么样的产品方案来应对呢？
首先，我们需要确定更新数据的方案，当数据结果早于配置规则出现就意味着新旧规则的同时存在，而新规则是未知的不确定的，是无法提前进行预测的，提前预置规则是非常困难和性价比很低的方案。
因此我们可以采用评估新规则受影响的具体字段和时间范围，以人工干预清洗数据的形式对这部分数据以最新的规则进行更新。
其次，需要提前告知用户具体字段在哪一个时间段内会发生“历史数据变化”，尽可能降低用户的不安。
一方面是因为数据是用户行为产生的，原则上数据归属用户所有，如果随意修改数据而不对用户进行告知，会导致用户产生“数据不安全”，“对产品不信任”等负面影响；另一方面，主动告知影响范围，也会减少用户产生“数据为什么发生变化”的疑惑。
最后，评估“历史数据”改变给用户带来的影响，有无影响用户正常业务，是否直接或间接给用户带来损失。对于产生影响和损失的，需要及时给予用户补偿，以缓解和安抚用户负面情绪，避免因此而造成和用户的纠纷以及可能存在的诉讼等更不良的影响。
例如A公司使用了某款数据分析产品，根据该产品提供的数据对员工进行kpi考核，改变历史数据就会影响到A公司已经完成的考核，如果不告知用户和进行补偿，很可能会引起用户的追责和诉讼。
总结
当“配置项”发生改变时，通常未来数据是肯定发生改变，而历史数据不发生改变，但是在一些特殊场景下，历史数据也需要被改变，而且不改变会导致一些不好的影响，所以需要通过人工干预数据的方式来进行数据清洗和更新，并且需要提前通知用户和沟通补偿方案，尽可能降低用户负面情绪所带来的更恶劣影响。
