淘宝买菜累计下单玩法的前世今生与技术思考

设计模式 5月前 0 17

概述

淘宝买菜作为手淘的用户生鲜消费第一入口，通过“次日自提”与“小时到家”两种不同的履约模式，满足用户针对高性价比、可选范围广的生鲜商品需求。其中，次日自提服务(原“淘菜菜”)，已成为针对价格力敏感用户、工薪家庭在手淘提升复访复购的社区团购平台，给这些用户培养了“买菜上淘宝”的生鲜心智，为手淘带来了大量下沉市场用户的来访用户数增量(增量DAU)与下单人数增量(增量DAC）。

累计下单玩法，是淘宝买菜次日自提服务中的一种老客复购提频互动精准营销方案。其主要通过“X天下Y单发Z权益”的活动主玩法，附加抽奖等辅助玩法，实现千人千面的老客复购策略投放，显著提升平台增量DAC，实现用户的精细化运营。

累计下单玩法自22年11月上线以来，取得了不错的增量效果。玩法也随着业务目标的不断调整，进行了一系列迭代，目前已经迭代到了4.0版本。在迭代过程中，累计下玩法配置愈发灵活，运营精细化随之提升，已经成为了淘宝买菜次日自提模式老客运营的一项核心产品，为平台增量DAC指标贡献着显著力量。

项目背景

淘宝买菜次日自提服务在22年中期，针对中低购买频次用户，平台没有激励活动与营销抓手，引导这部分用户进行购买提频跃迁。而次日自提中的互动场（签到领钱、天天领鸡蛋）活动用户相对平台大盘，购买活跃度相对较高，且这部分用户对权益较为敏感。

于是，业务侧在次日自提互动域签到频道提出了“累计下单”任务玩法，其主要通过“X天下Y单发Z元”的下单玩法，提升目标用户购买频次，让其“经常买”也“买得多”。

项目里程碑与业务流程

项目里程碑如下所示：

图1 淘宝买菜次日自提累计下单产品发展里程碑

1.0阶段：暗盒玩法

核心玩法：用户在来访签到页时，如果用户满足指定特征，则会弹出累计下单任务活动楼层，楼层中有用户“已攒金额”与“累计金额”的展示，用户通过每天下单的方式，可以得到对应任务推进进度所配置的金额奖励，当用户攒到“累计金额”后，系统一次性将已攒到的“累计金额”买菜金红包奖励发放给用户。

1.0阶段业务流程如下所示：

图2 累计下单1.0阶段业务流程

为什么称其为“暗盒”玩法：这是因为对于C端用户而言，其只能看到当前已攒金额，其如果想获得任务的大额奖励，其需要通过不断地每天下单来“攒钱”，对于需要几单才能真正完成这个任务获得奖励，用户是不感知的，是“暗盒”的。

线上Demo：

图3 累计下单1.0阶段产品Demo

2.0阶段：明盒玩法

目的：进一步提升任务完成率，提升活动期间用户购买天频。

核心玩法：在1.0版本的基础上，将前台任务的难度与获得奖励的条件透出，用户能够清晰地感知到他当前的任务进度，还需要下几单才能获得最终的奖励。换言之，整个玩法对用户来说是“明盒”的。

2.0阶段业务流程如下所示：

图4 累计下单2.0阶段业务流程

线上Demo：

图5 累计下单2.0阶段产品Demo

3.0阶段：抽奖玩法

背景：在2.0阶段后，为了提升玩法的趣味性与随机性，业务引入了抽奖玩法，通过配置不同的抽奖奖品与概率控制玩法成本，也可以以抽奖奖池中的奖品“最高金额100元”为噱头，吸引用户参与任务，提高下单频次。

3.0阶段业务流程如下所示：

图6 累计下单3.0阶段业务流程

线上Demo：

图7 累计下单3.0阶段产品Demo

4.0阶段：全链路引导+过程奖励玩法

背景：

1、累计下单为签到频道的内置玩法，受限于签到频道自身的规模，对满足活动参与要求的用户的曝光率较低，需要增加多个触达的入口（例如首页、购后页），提醒用户参与累计下单活动；

2、3.0版本及之前的策略都是结果奖励。用户只要中途未完成任务，就无法获得任何奖励。对于部分用户来说，任务完成的难度较大，任务整体完成率较低。因此需要实现从“累计返”到“单单返”的能力，促使这部分用户完成下单，获取奖励。

业务流程：

图8 累计下单4.0阶段业务流程

线上Demo：

图9 累计下单4.0阶段产品Demo

技术思考与实现

架构演进

第一阶段(1.0~3.0)：快速迭代，互动域实现自闭环

累计下单玩法，在技术侧是被抽象为一种特殊的任务类型，沉淀在淘宝买菜互动平台应用中的。互动平台作为互动前台应用的核心中台，提供了以“任务”为载体的互动玩法能力，通过不同的任务类型，实现不同的任务领取、推进、完成、奖励发放逻辑，支持了签到领钱、天天领鸡蛋、分享助力等互动产品的底层计算逻辑。

互动平台的整体业务架构图如下所示：

图10 次日自提互动平台整体架构

细化到累计下单玩法，其主要链路图如下所示：

图11 累计下单用户触发活动链路

图12 累计下单用户下单推进活动链路

在第一阶段中，累计下单玩法，在业务上还是被定位成互动域下签到产品的一个For复购的子玩法。因此整体的架构设计，分为前台和中台两个部分：

中台指互动平台应用，将累计下单玩法抽象成一个任务类型。通过领取任务->下单推进任务->任务过期失效，来管理用户在命中累计下单玩法的活动行为。通过不同的规则模板与计算逻辑，来校验用户是否可领取、下单是否能推进任务进度、退款是否回扣任务进度等一系列动作。除此之外，互动平台还负责把控活动奖励的发放/扣回逻辑处理。
前台指签到应用，其主要负责调用任务平台查询对应的累计下单任务，将原始任务数据解析为前台活动楼层数据，与前端进行交互。

在这种较为简单的架构下，使得整体的技术实现做得较轻量级。数据的流转、交互也相对简单，能够支持产品在前期进行快速迭代，拿对应的业务结果。

第二阶段(4.0)：接入权益统一供给池，实现场域全链路投放

1.0-3.0版本持续的迭代，使得整个累计下单产品的玩法变得多样，用户也相对更有动力去参与活动。在整个用户从 “触达任务->领取任务->下单推进任务->获得奖励” 整个玩法的漏斗中来看，用户的参与率也在逐步提高。

但是，从漏斗分析中可以看出，如果平台最终的目标是让更多的用户参与进来的话，其实最重要的反而是第一步“触达任务”这个动作。而受限于签到产品整体的规模与用户心智影响，其实只有小比例的用户能够每天都感知到他有累计下单这样一个玩法活动在身上。

换言之，即使用户第一天通过POP触达方式，跳转到签到频道页领取了任务，然而在第二天的时候，用户如果忘记了点击签到页按钮，那么他可能大概率不记得他曾经领取过这样一个下单任务。

基于这个假设，我们发现累计下单玩法其实已经不能囿于签到频道页这样一个单独的场域进行透出了，而是应该在端内的各个场域都对用户进行透出与触达，时刻提醒用户他有这样一个营销玩法活动，提升用户的下单欲望，提高平台CVR转化。

因此，玩法需要在全链路、各个场域对用户进行触达，且不同的玩法，可能对用户传递的内容与规则页不太一样。因此，我们期望有一个统一的玩法供给接口提供给前端。前端可以基于不同的场域、不同的玩法类型、不同的场景来约定不同的参数，通过这些参数的组合，来走到服务端不同玩法的定制逻辑。这样的话，接口层面进行了统一。

在这个接口中，服务端提供了一个统一的权益玩法模型，该模型除了囊括券玩法、抽奖玩法等狭义上的权益信息外，还囊括了特价商品、互动任务玩法等信息。

基于此，我们将原先的“权益活动”域与“互动玩法”域在依赖关系上相互独立的局面进行了调整。针对首页、购后页等非互动频道需要将互动玩法透出的场景，将权益活动平台升级为了权益投放平台，而将互动平台作为权益投放平台的一个底层玩法供给，接入到了整体的权益统一供给池中。这样一来，所有需要在非互动频道页需要透出的互动玩法，都通过权益投放平台作为统一通道的方式，向C端用户透出。

基于以上论述，我们可以梳理得到升级后的累计下单权益供给统一架构如下图所示：

图13 累计下单权益供给统一架构

对于C端用户来说，在其来访首页时，在整体的权益投放统一供给池中，判断其是否命中累计下单任务活动的数据链路如下图所示：

图14 权益统一供给池视角下的用户触发累计下单玩法数据链路

任务渲染流程

用户在来访累计下单活动相关触点时，前端会调用导购投放平台相关资源位，导购平台会在资源位请求调用下游权益投放平台权益统一供给接口，在供给接口调用互动任务渲染接口。任务渲染的具体流程如下所示

图15 累计下单任务渲染流程

下面对于每一个流程节点做具体说明：

查询任务模板：基于场景与任务类型召回所有累计下单任务模板，并进行一些基础的通用校验。
查询任务规则：基于任务模板，召回对应配置的规则模板。
任务规则匹配：基于任务模板维度，校验其配置的规则信息。
聚合每个模板对应所有匹配子结果，得到该模板最终规则匹配结果。
匹配成功：直接到第7步。
匹配失败：基于匹配失败的任务模板id，查询该用户该模板id当前时间是否有已存在的任务实例，如存在则将该模板重新放回到有效模板列表中
聚合得到所有有效任务集合。
查询任务记录。
查询奖励发放记录：如当前任务已存在实例，则查询对应实例奖励发放记录列表。
后续处理：模型转换。

任务领取流程

用户在看到任务楼层后，通过点击“领取任务”按钮或通过签到频道页POP进行任务领取动作。用户触发动作后，前端直接调用任务领取的网关接口，任务领取的具体流程如下图所示：

图16 累计下单任务领取流程

下面对于每一个流程节点做具体说明：

网关入参调用：用户在端上做出领取动作后，前端直接调用网关领取接口。
校验任务模板：召回指定任务模板信息，并进行一些基础校验。
查询是否已领取任务：基于模板id查询任务实例DB，判断当前用户是否已存在进行中的有效实例。
校验是否可领取：基于模板id召回对应任务规则列表，进行领取规则校验
创建通用任务实例：基于任务模板配置生成任务实例模型。
任务实例后置处理：设置一些累计下单任务定制字段保存到任务实例中。
任务实例落库：保存任务实例到DB中。
构建接口返回：将保存好的任务实例进行模型转换，封装到返回结果中。

任务推进流程

用户在领取任务后进行下单，系统会基于订单消息进行解析，尝试对累计下单任务进行推进，并发放对应的奖励，任务推进的整体流程图如下所示：

图17 累计下单任务推进流程

下面对于每一个流程节点做具体说明：

交易订单消息触达：用户在下单成功后，交易平台发送消息到各个下游。
构建订单事件：基于消息构建互动域的订单事件，触发订单消费流程。
订单幂等校验：召回DB该用户支付任务实例，幂等判断该订单是否已经被消费。
任务推进规则校验：过滤第3步中目前正在进行中的支付任务实例，召回对应任务规则列表，进行逻辑计算校验。
多任务优先级规则校验。
计算本单推进累计下单进度。
将计算得到的结果保存更新。
保存本单任务记录。
判断是否需要发奖：如果本单需要真实发放奖励，则执行第10步。
执行发奖：构造发放金额参数，调用下游接口进行奖励的发放。
抽奖玩法后置处理：如果当前是抽奖玩法，则进行抽奖玩法的一些定制逻辑。
发送下游通知消息，用于下游业务将奖励结果对C端用户透出。

总结与展望

淘宝买菜累计下单产品在0到1不断建设的过程中，其拥有了越来越多的产品能力，业务价值也逐步提升。从玩法上而言，其逐渐从单一的“下X单攒钱发买菜金”的单一需求，逐渐演变成了权益可运营(买菜金、抽奖资格)、玩法可运营(累计返、单单返)的多种沉淀能力；从场域上而言，其也从最开始的签到频道的一个子玩法，逐渐成长为了淘宝买菜次日自提下的一个全链路平台玩法，实现了平台对用户的精细化运营。在这个过程中，技术侧为实现业务需求，跟随业务小步快跑，也在领域抽象、流程设计、架构升级层面做了一系列思考与措施，在保证产品的敏捷迭代的同时，也保证了研发效率的提升以及系统复杂度的可控性。从长远而言，累计下单产品还会为了平台业务目标的转变，丰富其玩法内涵，技术侧也将基于业务的诉求，不断探索演进，抽象沉淀出更加敏捷灵活的产品功能与系统能力，持续赋能业务精细化运营能力，高效支持助力其达成一个又一个目标。

扫码领红包

微信赞赏支付宝扫码领红包