编辑导语：在付费软件中，有时因遗忘续费、请款流程等原因，一些用户没有办法在到期到日当天就完成续费，所以存在着时间差，在这个周期内未续费的用户不一定是真的流失，这里的“续费率”就是一个延迟数据。本文作者以产品A为例，分析产品中的延迟数据，一起来看一下吧。
产品 A 是一款付费软件，小明是产品 A 的运营同学，近日正在针对产品 A 的续费情况做数据分析，希望来判断产品 A 近期的续费状况。小明调研后获得了4-18～4-22的续费数据，并对比了去年同一日期的续费率，获得了以下的折线图：
2022和2021年续费数据对比
观察图表中的数据，可以发现，蓝色折线代表了2022年4月18-22日的续费率，呈快速上升的表现，短短5天从20%到110%，甚至出现了超过100%的反常数据，正常认知下续费率是不会大于100%的
同时对比去年同一时间的续费率，续费率是稳定在50%左右的，因此我们可以得出4月份的这部分调研续费率数据是存在误差的，对此小明作出了进一步的调研。
为此小明专门调查了4月18日-22日到期用户的续费时间，分析后得到如下表格：
4/18-4/22续费情况
研究这个表格我们可以看出，随着日期往后推移，在某一天续费的用户其到期时间分布的是在不同的日期的，例如以4月22日为例，4月18日到期了100 个用户，但其续费的用户并不是仅在4月18日续费。
从表格中我们可以发现，4月18日到期的用户数除了在18日续费了20个，19、21 和22日均有续费，其中4月18日到期4月18日续费是属于按时续费，存在 20 个用户。
而4月19 ，21和22日续费，其续费时间已经大于4月18日这个到期时间了，这些日期续费就属于一个延迟续费，这3日的数据分别如下：
则延迟续费的用户总数为 25 个。这里可以发现，4月18日到期的用户，其续费时间并不是仅仅在4月18日，在19日、21日和22日均有分布。
而小明在统计续费率时只统计了18日到期18日续费的用户，从而使得续费率大大减少，仅20%，汇总续费用户后得出的续费率（20+10+10+5）/100 = 45%，接近历史续费率 50%，是一个较为符合续费现象的数据。
带着这个“到期用户并一定在到期当天进行续费”的疑问，小明找这部分用户调研和走访，发现因遗忘续费、请款流程等原因，一些用户没有办法在到期到日当天就完成续费。
这里就存在一个时间差，这里18-22号之间的4天就是一个时间差，在这个周期内未续费的用户不一定是真的流失，只有当4天之后没有续费，才是一个流失用户，这里的“续费率”就是一个延迟数据，续费周期为4天。本文就想和大家讨论产品中的延迟数据。
先给“延迟数据”1 个定义：延迟数据是指推迟产出的数据，像文章开头的续费率中，4月18日的续费率在4月18日产出，是一个理论上的数据产出时间。
我们认为4月18日到期的用户是否会续费在4月18日当天就能确定，但是由于现实情况中“不是所有用户都能够在到期当天”完成续费。
导致了4月18日到期的用户在后4天都有续费产生，因此4月18日的续费率是一个“4月18日到期，4月18日之后4天”续费的一个数据。
这就存在了一个推迟产生的过程，而这个推迟产出的数据，也就是我们所说的延迟数据。
在定义中我们看到延迟数据出现的原因是因为业务场景导致的，顾名思义就是产品设计时，从业务方面的因素考虑，当真实的业务是一个延迟场景时，为了让数据更真实地还原业务场景，将字段设计成延迟字段。
例如在续费率的案例中，因为续费这个场景是个延迟场景，用户因为请款、遗忘等原因，导致了本应该在到期当天的续费动作，发生在了到期日之后的日期中。
如果我们不将“续费率”设置成一个延迟数据，在不延迟的情况下18日到期的续费率就是18日到期然后18日续费的客户，而真实的业务中，18日到期的客户会在18-21日都产生续费动作。因此“续费率”需要设计成一个T+4 天后更新的延迟字段。
从什么是延迟数据中，我们已经了解到业务场景会导致我们将字段设计成延迟字段，那么具体什么样的业务场景会需要这样设置呢？
当业务场景中定制的规则，存在跨自然天规则时，也就是存在超过1天及以上的时间跨度时，就会需要设计成“延迟字段”。
如果我们不将其设计成“延迟字段”，就会导致统计出结果的时间跨度是小于业务场景中的时间跨度，从而使得最终的数据结果小于真实的业务数据。
以此数据做出的判断和动作都将是错误的，从而产生运营上的失误，甚至严重的带来直接的经济损失。而我们将其设计成“延迟字段”的话，就可以充分准确地反应了真实的业务信息，从而为我们后续的决策和动作提供数据基础。
接下来我们一起来看下这部分业务场景具体有哪些，其中包括业务规则本身要求 和根据业务主动调整两种情况。
这里的业务规则本身，指的是“时间跨度”是由业务自身的规则所导致的，一起看下下面两种交易规则：
证券平台A中的规则，规则本身提供的交易时间段都在自然天内，所以挂单当日的订单是否成交，在挂单当天都可以产出，订单有效时间没有跨天，不存在延迟产出的情况。
而在电商平台中，用户在N日浏览，在N日创建了订单，而根据平台的订单的支付有效期规则：24小时内有效，超时未完成付款，订单关闭。
我们可以得出N日创建的订单，实际的支付时间可以是在N日或N+1日。所以如果我们要了解电商平台N日创建的订单的支付成功情况，会有以下几种情况：
综上可见，我们想要得出N日创建的订单，最终的订单状态，需要等待N+1 日才可以得到，并以此来计算一下对运营动作具有参考价值的字段。这里就是一个因业务规则本身要求导致跨天性的数据延迟。
“根据业务主动调整”，通常是指业务并不是一个固定的业务，会因为一些时间、使用角色等外在因素导致变化。
不同的外在因素使得同一个业务的规则会变化。外在因素改变后，如果我们不去兼容变化后的规则，会导致该业务产出的数据失真，失去意义，无法表现真实的业务情况。
当业务规则的时间跨度从当天，变成了跨自然天，这里为了适应业务规则的变化，就要求我们改变成延迟字段。
一起来看一下根据业务主动调整的案例，某电商平台对内部客服有考核客服是否有回复消费者。
通常情况下，消费者和客服的咨询都发生在自然天内，所以只需要统计消费者咨询后，客服当天是否有进行回复，若没有回复，则计入回复未达标数量为1。
当该电商平台进入直播/大促等活动时，受限制于活动时间通常在0点开始，这就导致了活动开始前，即11点-0点期间涌入大量的消费者咨询，而客服受到回复能力限制，没有办法一一进行及时回复，产生了大量在0点后的回复。
这个情况下，要考核客服是否有回复消费者，如果只看只看消费者咨询当天是不太合理的，会产生大量因为客服爆线导致的回复未达标数据，而这部分数据并不是客服主观上没有回复消费者，所以需要这里需要调整为看消费者当天 T和 T+1 天客服是否有回复，这样统计出来的回复达标情况，是相对准确的。
结合“业务规则本身要求”和“根据业务主动调整”两个一起来看，两者的共同点都是因为“业务中存在跨自然天”的场景，从而需要延迟产出数据，差异在于“业务规则本身”是其业务规则不变的，而“根据业务主动调整”则是业务规则会随着时间等外在因素变化。
在了解完什么是延迟数据和什么场景下会出现延迟数据后，我们就需要设计数据延迟方案了，那么在设计过程中，我们需要考虑哪一些要点呢？
无论是上文2中业务场景中的哪一种导致的延迟数据，当存在延迟数据的情况时，就需要明确延迟周期，T日的业务，结果需要在T+N日产出，结合不同的业务情况，定义好延迟的天数，这就确定了数据延迟方案中最重要的一步。
像文章开头中，续费业务中大部分的延迟续费在4天内，因此定义了延迟周期4天，因此数据是在T+4日内出来的。
在延迟周期内，数据更新的方式又存在两种，一种是每日更新，另一种是在数据产出当天统一进行计算。
前一种计算方式可以针对实时查看延迟数据的情况，例如T+4的续费率一般在60%，在T+1看到一个续费率是30%，可以了解两者之间的差异，以便于展开一些运营活动。
另一种就保证了不会因为变化的数据产生一些干扰性和歧义，且计算更加简单，只需要计算一次。
确定延迟后，需要考虑用户能否理解延迟这个问题，所以需要在页面上做出相关的说明。不然会存在用户咨询数据为何没有产出的疑问和咨询。
第一种，可以通过系统的公告的方式来告知用户数据延迟了，这种方式通常针对因临时性原因导致的短暂延迟，所以可以用临时性的公共方案来解决这个问题。
例如在电商产品在双11等大促期间，因数据量剧增，导致数据晚于原定时间出现，这里就可以上一个公告以进行说明，帮助用户了解数据延迟的原因，避免因数据延迟带来损失。
相较于第一种常用于解决临时性延迟的方案，另一种，针对长期的延迟，例如产品设计方案设计的需要延迟的场景，我们可以将其作为一个常态化的功能，当数据在延迟日期内，或者包含了延迟期间的数据，我们可以在字段旁边对其做出特殊说明，让用户理解这部分字段是存在延迟的。
本文，我们一起了解了，延迟数据其实是一种数据更新频率，当本应出现数据的日期没有出现数据，那么就可以认为是一个延迟数据了，其通常出现于因业务因素导致的数据无法更新场景，包括“业务规则本身要求”和“根据业务规则主动调整”这两种情况。
晌午，微信公众号：晌午自习室，人人都是产品经理专栏作家。5年产品经验，专注于数据方向，目前是电商客服领域的产品 。
本文原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Unsplash，基于CC0协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。