【策略产品PRD】小红书订单支付等待时长策略优化

项目背景

作为小红书的策略产品经理。最近发现一个现象：

一小部分的用户（影响面约3%）会在购物订单取消后，（在订单生成时间之后的）30min~120min内，二次生成订单，并完成支付。

经了解，现有的产品逻辑是：不管针对什么样的用户，30min内没付款就取消交易。

现在的这种时间限制似乎有点影响用户体验。

直觉假设是：如果将订单待支付的时间延长，应当能增加订单的付款成功率。
为此，决定用策略的手段验证、优化这一问题。

本文分析思路如下：
1.【功能体验】深入体验小红书平台支付模块
2.【竞品分析】选取5个典型电商平台的支付模块作为调研对象，并汇总调研结论
3.【策略四要素分析】小红书用户支付时间分析
4.【PRD需求文档】输出PRD需求文档

1.体验小红书平台支付模块

1.1简易流程图

小红书支付流程.png

1.2.关键节点

a）提交订单，订单状态为待支付后，开始等待支付的倒计时30分钟，此时开始锁定商品库存。
b）等待支付倒计时30分钟结束后，订单尚未支付，则订单状态改为，已取消，同时释放商品库存。
*以上规则仅限于 非活动的 自营与第三方商家商品。

【竞品分析】典型电商平台支付时间分析

1.调研结果汇总

2.调研分析

选取了天猫，网易严选，得到APP，12306，有赞，keep等电商平台，分别体验各自对于支付时间的设定以及对应的提醒策略。
a) 1hours 以下：小红书、天猫的聚划算，限时抢购、12306、支付等待时间均在1hours以下。
分析：天猫的营销活动频道以及12306，特点在于对商品库存的估量非常刚性，而且活动时效性很强。而订单待支付后，会占用库存，若最终没有成交，则影响了其他有购买意愿的用户，对整体销售产生负面影响。因此，这类对于库存敏感，时效性强的，等待支付的时间往往不会太长。

b）1-2hours：keep电商的待支付时间在2hours。
分析：由于keep的产品特性，用户在运动与购买商品的场景间切换，太多因素会离开了商城而没有支付订单。而且，keep商城是一个自营的B2C模式，自家对于供应链的把控力更强，因此，把等待支付时间设置为2hours也是合理的。

c）2hours 以上：天猫/淘宝系常规商品买卖。由于天猫/淘宝 是一个纯粹的电商平台，用户使用场景是逛，选购为主。因此，必然存在对比，存在考虑的需求。如果等待支付时间太短，一来会给用户造成压力，二来也对于促成交易不利。再者，作为头部电商平台，完全能够把库存锁定造成的压力让开店卖家想办法承担。因此，24小时的等待支付时间是合理的。

综上，在考虑支付等待时间这个问题时，需要结合产品自身的特性，用户使用场景，以及业务指标。

3.【策略四要素分析】小红书用户支付时间分析

一小部分的用户（影响面约3%）会在购物订单取消后，（在订单生成时间之后的）30min~120min内，二次生成订单，并完成支付。这个现象反映的问题有两个：
a）30mins的统一等待支付时间，对于小部分用户并不能很好的匹配使用场景。
b）30mins的统一等待支付时间，能平衡当前大部分用户和商家的需求。

3.1待解决问题

a）针对不同用户，不同场景，不同商品，个性化调整订单的支付等待时间。
b）降低用户因为订单超时而二次发起订单的数量，提高首次下单转化率。

3.2影响用户支付时间的因素

3.3输入项与计算规则

a）从用户-用户使用场景-商品三个维度进行输入项的拆解并且制定每一个变量的影响权重。
b）指标与计算规则

3.4输出

以30mins为最小值，根据该用户此次支付订单的实际情况计算权重值，再根据权重值延长支付等待时间。
上限：30mins，最低支付等待时间不能低于30mins。
下限：120mins，最高支付等待时间不能高于120mins。
步长：5mins，以5分钟为一个计算单位向上取整。
由于缺少历史数据作为测算参考，先采取平均值的方法计算得每一项贡献的支付等待时长。后续可根据运营情况迭代。

【PRD需求文档】输出PRD需求文档

0.项目背景

3%的用户会在订单取消后30-120min后二次下单，所以为了提升用户体验以及提高用户支付成功率，需要对支付时间限制、和订单取消后的流程进行优化。

1. 项目目标

通过调整支付等待时间的策略，提高订单单支付转化率。

2. 需求概述

a）优化支付时长策略，满足因时间限制未能完成支付的用户场景。
b）设置消息提醒规则，满足因外界干扰而未能完成支付的用户场景。
c）调起第三方支付前的30mins倒计时不利于用户完善快递信息或进行充值。

3. 需求详述

需求a的解决方案：
1.指标与权重：

2.计算规则：
以30mins为最小值，根据该用户此次支付订单的实际情况计算权重值，再根据权重值延长支付等待时间。
上限：30mins，最低支付等待时间不能低于30mins。
下限：120mins，最高支付等待时间不能高于120mins。
步长：5mins，以5分钟为一个计算单位向上取整。
由于缺少历史数据作为测算参考，先采取平均值的方法计算得每一项贡献的支付等待时长。后续可根据运营情况迭代。

需求b的解决方案
可通过设计不同的短信文案，设定不同的定时推送规则，提醒用户。

需求c的解决方案
问题描述：
从生成订单到确认支付之间的等待时间只有30mins。如果对于用户需要变更地址信息，或者需要资金转移来支付的，很容易造成订单流失。
问题分析：
由于尚未支付并未锁定库存，此时的倒计时，更多是为了营造紧迫感，让用户加快决策。而当用户确实需要较长时间离开当前页面，再次返回时，这个订单已失效了。
解决方案：
1)离开重新进入页面时，倒计时30mins重新开始计算；
2）点击“继续拔草”回到页面时，倒计时30mins重新开始计算；

4. 统计需求

核心指标：订单存活率
观察指标：短信送达率、APP通知点击率、订单冻结期间库存紧张度、订单取消率

5. 功能优先级排序

a）订单支付时长策略调整
b）支付提醒文案推送
c）提交订单信息页面30s倒计时完成后，点击继续拔草重新计时