百木园-与人分享,
就是让自己快乐。

产品设计中的延迟数据

产品 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日的数据分别如下:

  • 4 月 18 日到期,19 日续费的用户数是 10 个
  • 4 月 18 日到期,21 日续费的用户数是 10 个
  • 4 月 18 日到期,22 日续费的用户数是 5 个

则延迟续费的用户总数为 25 个。这里可以发现,4月18日到期的用户,其续费时间并不是仅仅在4月18日,在19日、21日和22日均有分布。

而小明在统计续费率时只统计了18日到期18日续费的用户,从而使得续费率大大减少,仅20%,汇总续费用户后得出的续费率(20+10+10+5)/100 = 45%,接近历史续费率 50%,是一个较为符合续费现象的数据。

带着这个“到期用户并一定在到期当天进行续费”的疑问,小明找这部分用户调研和走访,发现因遗忘续费、请款流程等原因,一些用户没有办法在到期到日当天就完成续费。

这里就存在一个时间差,这里18-22号之间的4天就是一个时间差,在这个周期内未续费的用户不一定是真的流失,只有当4天之后没有续费,才是一个流失用户,这里的“续费率”就是一个延迟数据,续费周期为4天。本文就想和大家讨论产品中的延迟数据。

01 什么是延迟数据

先给“延迟数据”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 天后更新的延迟字段。

02 什么场景下需要延迟数据

从什么是延迟数据中,我们已经了解到业务场景会导致我们将字段设计成延迟字段,那么具体什么样的业务场景会需要这样设置呢?

当业务场景中定制的规则,存在跨自然天规则时,也就是存在超过1天及以上的时间跨度时,就会需要设计成“延迟字段”。

如果我们不将其设计成“延迟字段”,就会导致统计出结果的时间跨度是小于业务场景中的时间跨度,从而使得最终的数据结果小于真实的业务数据。

以此数据做出的判断和动作都将是错误的,从而产生运营上的失误,甚至严重的带来直接的经济损失。而我们将其设计成“延迟字段”的话,就可以充分准确地反应了真实的业务信息,从而为我们后续的决策和动作提供数据基础。

接下来我们一起来看下这部分业务场景具体有哪些,其中包括业务规则本身要求 和根据业务主动调整两种情况。

1. 业务规则本身要求

这里的业务规则本身,指的是“时间跨度”是由业务自身的规则所导致的,一起看下下面两种交易规则:

  • 用户在证券平台A挂单希望买入股票1,根据证券平台的交易规则,订单只在交易时间段有效,即9:00-12:00和13:00-15:00,超过时间未成交的订单,将作废
  • 用户在电商平台B下单希望买入商品1,根据该电商平台的交易规则,订单在下单后24小时内有效,超时未完成付款,则该订单关闭
  • 证券平台A中的规则,规则本身提供的交易时间段都在自然天内,所以挂单当日的订单是否成交,在挂单当天都可以产出,订单有效时间没有跨天,不存在延迟产出的情况。

    而在电商平台中,用户在N日浏览,在N日创建了订单,而根据平台的订单的支付有效期规则:24小时内有效,超时未完成付款,订单关闭。

    我们可以得出N日创建的订单,实际的支付时间可以是在N日或N+1日。所以如果我们要了解电商平台N日创建的订单的支付成功情况,会有以下几种情况:

    • N 日创建的订单 N 日支付成功,N 日可确认这部分数据
    • N 日创建的订单 N+1 日支付成功,N+1 日可确认这部分数据
    • N 日创建的订单 N 日订单关闭(平台关闭或用户手动关闭),N 日可确认这部分数据
    • N 日创建的订单 N+1 日后因超时 24 小时订单关闭,N+1 日才可以确认这部分数据

    综上可见,我们想要得出N日创建的订单,最终的订单状态,需要等待N+1 日才可以得到,并以此来计算一下对运营动作具有参考价值的字段。这里就是一个因业务规则本身要求导致跨天性的数据延迟。

    2. 根据业务主动调整

    “根据业务主动调整”,通常是指业务并不是一个固定的业务,会因为一些时间、使用角色等外在因素导致变化。

    不同的外在因素使得同一个业务的规则会变化。外在因素改变后,如果我们不去兼容变化后的规则,会导致该业务产出的数据失真,失去意义,无法表现真实的业务情况。

    当业务规则的时间跨度从当天,变成了跨自然天,这里为了适应业务规则的变化,就要求我们改变成延迟字段。

    一起来看一下根据业务主动调整的案例,某电商平台对内部客服有考核客服是否有回复消费者。

    通常情况下,消费者和客服的咨询都发生在自然天内,所以只需要统计消费者咨询后,客服当天是否有进行回复,若没有回复,则计入回复未达标数量为1。

    当该电商平台进入直播/大促等活动时,受限制于活动时间通常在0点开始,这就导致了活动开始前,即11点-0点期间涌入大量的消费者咨询,而客服受到回复能力限制,没有办法一一进行及时回复,产生了大量在0点后的回复。

    这个情况下,要考核客服是否有回复消费者,如果只看只看消费者咨询当天是不太合理的,会产生大量因为客服爆线导致的回复未达标数据,而这部分数据并不是客服主观上没有回复消费者,所以需要这里需要调整为看消费者当天 T和 T+1 天客服是否有回复,这样统计出来的回复达标情况,是相对准确的。

    结合“业务规则本身要求”和“根据业务主动调整”两个一起来看,两者的共同点都是因为“业务中存在跨自然天”的场景,从而需要延迟产出数据,差异在于“业务规则本身”是其业务规则不变的,而“根据业务主动调整”则是业务规则会随着时间等外在因素变化。

    03 设计延迟数据方案需要考虑的点

    在了解完什么是延迟数据和什么场景下会出现延迟数据后,我们就需要设计数据延迟方案了,那么在设计过程中,我们需要考虑哪一些要点呢?

    1. 明确延迟周期

    无论是上文2中业务场景中的哪一种导致的延迟数据,当存在延迟数据的情况时,就需要明确延迟周期,T日的业务,结果需要在T+N日产出,结合不同的业务情况,定义好延迟的天数,这就确定了数据延迟方案中最重要的一步。

    像文章开头中,续费业务中大部分的延迟续费在4天内,因此定义了延迟周期4天,因此数据是在T+4日内出来的。

    在延迟周期内,数据更新的方式又存在两种,一种是每日更新,另一种是在数据产出当天统一进行计算。

    前一种计算方式可以针对实时查看延迟数据的情况,例如T+4的续费率一般在60%,在T+1看到一个续费率是30%,可以了解两者之间的差异,以便于展开一些运营活动。

    另一种就保证了不会因为变化的数据产生一些干扰性和歧义,且计算更加简单,只需要计算一次。

    2. 延迟概念的透出和展示

    确定延迟后,需要考虑用户能否理解延迟这个问题,所以需要在页面上做出相关的说明。不然会存在用户咨询数据为何没有产出的疑问和咨询。

    第一种,可以通过系统的公告的方式来告知用户数据延迟了,这种方式通常针对因临时性原因导致的短暂延迟,所以可以用临时性的公共方案来解决这个问题。

    例如在电商产品在双11等大促期间,因数据量剧增,导致数据晚于原定时间出现,这里就可以上一个公告以进行说明,帮助用户了解数据延迟的原因,避免因数据延迟带来损失。

    相较于第一种常用于解决临时性延迟的方案,另一种,针对长期的延迟,例如产品设计方案设计的需要延迟的场景,我们可以将其作为一个常态化的功能,当数据在延迟日期内,或者包含了延迟期间的数据,我们可以在字段旁边对其做出特殊说明,让用户理解这部分字段是存在延迟的。

    04 总结

    本文,我们一起了解了,延迟数据其实是一种数据更新频率,当本应出现数据的日期没有出现数据,那么就可以认为是一个延迟数据了,其通常出现于因业务因素导致的数据无法更新场景,包括“业务规则本身要求”和“根据业务规则主动调整”这两种情况。

    给作者点赞,鼓励TA抓紧创作!


    来源:http://www.woshipm.com/pd/5510063.html
    本站部分图文来源于网络,如有侵权请联系删除。

    未经允许不得转载:百木园 » 产品设计中的延迟数据

    相关推荐

    • 暂无文章