策略产品经理基础知识24 策略PRD案例.docx

资源描述

策略产品经理基础知识24 策略PRD案例.docx

《策略产品经理基础知识24 策略PRD案例.docx》由会员分享，可在线阅读，更多相关《策略产品经理基础知识24 策略PRD案例.docx（9页珍藏版）》请在冰豆网上搜索。

策略产品经理基础知识24 策略PRD案例.docx

策略产品经理基础知识24策略PRD案例

策略产品经理基础知识：

2.4策略PRD案例

上周我们分享了，怎么编写策略需求文档，这周我们拿个案例，具体的解释下。

为了让举例的内容更加丰富，我会让解决问题的方案多一些，这样可写的内容也会多一些。

案例的背景

1.业务背景

这是一个电商产品，项目主要是解决订单支付超时而发生的订单失效问题。

为什么要处理这个问题呢？

通常情况下，用户在电商平台下单后，平台为了确保用户在支付时能拿到货，会将商家的库存进行暂冻结处理。

这样虽然能确保用户的利益，但是却增加了商家的库存压力。

例如：

某用户一次性买了100台洗衣机，但是下单后，3天都没有支付。

这就造成商家需要为这100台洗衣机多支付三天的库存钱，手机还好，这要是海鲜下单后三天都不付款，那估计都臭了好几波了。

针对这样的情况，一般电商平台都会设置支付时限，一方面为了通过倒计时提升订单支付的转化率，同时也帮助商家缓解压力。

案例的需求就在这样的背景下产生。

2.需求背景

为了降低商家的库存压力，PM在用户端添加了一个订单30分钟限时支付的功能。

即：

无论任何商品的订单生成后，用户必须在30分钟内完成支付，否则订单会被自动取消，进而为商家释放库存。

功能上线1个月后，PM发现有5%的用户会在订单取消后，30min~120min内二次生成订单，二次购买。

且前后订单信息基本一致，35%的前后订单会在收货地址，款型颜色，方面存在差异。

老板认为：

这说明现有支付时限设定不合适，严重影响了用户体验，希望我们调整支付时限。

而PM认为：

数据表明部分被取消订单并非用户个人意愿造成，所以产品端可以利用某些方式，让订单被取消前就提示用户完成支付。

同时这个办法也可以用在订单失效后，提示用户再次购买。

进而提升订单转化率。

3.需求问题分析

3.1用户场景需求分析

通过用户场景需求分析，我发现用户会在如下场景，发生订单支付失败而二次下单的行为。

下单后发现收货地址错误，修改收货地址时间过长（现有流程，支持用户修改待支付订单的收货地址）；

用户在支付时发现支付方式选错，造成支付失败。

待想起后再次下单。

支付时网络环境差（例如：

在地铁中），待网络环境允许后再次下单。

用户在支付时发现支付终端金额不足，待解决钱的问题后再次下单。

用户纠结于商品价格和款型，下单后依旧犹豫不决，待决定后再次下单。

分析结论：

场景1可以通过，在修改收货地址时暂停倒计时解决；

场景2可以通过，默认选择用户常用支付方式的办法降低问题发生的几率；

场景3和4虽然是可控因素，但是用户再次下单的前提是用户想起了订单，所以可以通过订单状态push的方式提示用户完成支付；

场景5虽然是更不可控因素，但是平台可以通过“帮助用户决策”的方式，提升订单的成交率，即依据商品标签push信息。

3.2支付时限设定分析

从影响因素看，我可以从针对用户类型和针对商品类型两方面元素，制定订单支付时限的解决方案。

经过假设和分析，我发现针对用户类型制定个性化的支付时限并不合理。

最典型的例子就是：

针对新用户和老用户区分支付时限，那会造成用户在从新用户过度成老用户的过程中，每次支付时限都不一样。

无法让用户对支付时限有一个明确的认知，确定该在多长时间内完成支付，更不利于平台教化用户养成有利于支付的认知和行为。

从商品类型出发，平台目前有参与限时促销活动的商品和普通非活动商品两类。

以此订单类型可分为：

纯普通商品订单、纯促销活动商品订单、促销商品+普通商品三类订单；支付时限策略可以结合订单数据，针对三类订单进行区分。

3.3流程优化

分析订单被取消后用户再次下单的场景，综合相关因素我发现：

即便是采取延长支付时限+push提醒策略，还是无法避免订单因为支付超时被取消，导致依然存在购买需求的用户再次下单。

因此通过订单流程分析我觉得可以在订单被取消后，增加一个“再来一单”的快捷下单功能，减少用户再次下单的操作流程。

4.需求解决计划

用户端由功能产品经理解决，本文档详解策略部分+商家端平台推荐支付时限时长的选取策略。

策略需求文档

1.项目背景

最近发现一个现象：

5%的用户会在订单取消后，30min~120min内二次生成订单，二次购买。

老板希望产品同学想个办法，提升这5%用户的购物体验。

同时，产品同学希望借助延长支付时限和智能PUSH的方式，降低订单被取消量。

为此功能PM采取如下措施：

为了方便用户二次下单，用户端对“已取消订单”添加了一建“快速下单”功能，方便这5%的用户快速完成二次下单的支付操作。

为了降低订单因超时被关闭的情况，用户端订单详情和订单支付页，在用户编辑收货地址时，暂停支付倒计时的功能，避免因收货信息编辑而造成的支付时间不够用的情况。

但产品仍存在以下问题，导致订单因为支付超时而被取消，致使有购物需求的用户，需要二次下单：

现有支付时限过短，导致用户因为某种原因造成支付时间超时的问题；

缺少针对用户画像进行的“特殊订单”延时处理功能，导致用户对订单犹豫不决时，造成订单被关闭的情况；

缺少订单push功能，致使因不可控因素导致用户忘记支付订单而产生订单被关闭；

缺少针对已取消订单的唤醒机制，造成订单沉死的状态，生成大量失败的死订单。

2.项目目标

通过定向发送订单支付push和延长订单支付时限，提升订单支付成功率。

实现针对待支付订单类型，通过消息push、短信提示、app内提示窗三个渠道（app打开时，不发送push和短信，打开内部提示窗），向用户发送订单待支付提示的功能。

实现针对待支付订单，借助用户画像和订单类型，适当延长支付时限；并追加二次待支付订单提示的功能。

实现针对已取消订单，利用用户画像和商品画像，通过消息推动、短信提、已取消订单下方商品推荐区三个渠道，向用户派商品“专属优惠券”，推荐同款/同类商品功能的功能。

（依据现有相关推荐逻辑执行，此文档不做推荐逻辑说明）

3.需求概述

（1）商家端

依据用户端用户二次下单的间隔数据，结合竞品分析结果，对商家端提供自主设定支付时限的功能。

（2）策略端

调整支付时限：

订单支付时限分为平台默认时限和商家设定时限，商家设定时限优先级高于平台默认时限。

push策略：

推荐功能包括，用户画像，触发和匹配模块，优惠券匹配和分发模块，消息push模块。

各模块概述和完整流程如下：

用户：

实现对用户特征的挖掘，对匹配策略提供数据基础。

触发和匹配模块：

实现在不同时刻，生成待推送的订单、用户、消息、优惠券功能。

推送逻辑：

控制推送渠道，时间和内容拼装。

4.需求详情

（1）系统默认时限和商家推荐时限设定

1）竞品分析：

通过竞品分析，得出如下结论：

限时抢购类商品需设定较短支付时限，目的在于营造稀缺性，降低商家库存压力，不影响既定时间内容商品销售。

避免发生因为库存冻结产生货品不足，影响用户抢购体验的风险。

分析5%用户的订单间隔时间，以10分钟为一个统计间隔，分析得出50~90分钟为发生的最高频间隔时间。

综上设定订单支付时限策略如下：

限时特价商品，保持现有30分钟支付时间不变。

普通商品，支付剩余时间=30分钟+90分钟=120分钟。

商家自定支付时间分别为：

限时特价商品15min/30min/45min；普通商品30min/60min/120min/150min。

2）优先级应用关系如下

商家设定时限，优先使用商家设定时限，商家未设定时限，使用平台默认时限。

多个商品混合的订单，优先依据时限最短商品计算。

待时间最短商品计时结束后，将订单中该商品购买数量清零，重新计算价格，支付时间时限依据次短的商品计算。

3）Case示例（push策略也将使用该示例）：

订单内容商品如下：

限时特价商品A，商家设定时间为15min；

限时特价商品B，商家未设定支付时限，选择系统默认30min；

普通商品C商家设定时间为150min；

普通商品D商家未设定时间，选取系统默认120min。

用户生成订单后，订单计时策略如下：

初始时间为15min，到时后订单自动将商品A清零0，前台添加“支付超时被清空”提示，系统重新核算价格，支付时限增加15min（B时限-A时限=15min）；

再次到时后，订单自动将B清零，前台在B商品出添加“支付超时被清空”提示”，系统重新核算价格，支付时限增加30min（D时限-B时限=30min）；

依次类推，当订单只剩下商品C时，则时限再增加30min（C时限-D时限=30min）。

（2）待支付订单PUSH策略1