从0到1构建大促运营活动

前言

一年一度的618、双11，是各大电商平台投入资源最多、用户参与最广泛、流量最爆棚、系统最经受考验的时候，作为程序员的一份子，有幸能在工作中接触到这种流量的洗礼，能在一年中最考验系统健壮性的时刻来接收检验，真是让人斗志满满。每逢大促，琳琅满目各式各样的大促运营活动比比皆是，吸引用户眼球的是各类商品补贴、红包、优惠券、免单，活动玩法有签到、完成任务、游戏对战、组团等，获取收益的方式有抽奖、兑换等，最终这些活动的目的就是拉新促活，为平台带来流量，增加平台活跃度，提高用户参与度，激发下单意愿，提高成交转换率，最终获取平台收益。
今年 618算是临危受命，临时插入需求要支持一波大促运营活动，从需求分析、研发设计、编码实现、测试到最终交付上线，差不多忙了三周，目前活动线上运行稳定，开量情况也不错，最近有一点时间整理下这段忙碌时间里的项目收获，分享下如何从0到1构建大促运营活动。

一、需求背景

依托流量

关于大促运营活动需求背景，是依托大促流量，整合端内各类日常活动、专题活动、业务模块资源进行定向导流，活跃用户流向业务板块，增加整体端内用户留存，并通过任务分享、邀新利益点进行老拉新，增加端内新用户量。活动玩法主要通过页面导流、完成指定任务对参与用户进行虚拟资产发放，用户可通过虚拟资产进行抽奖兑换利益点。这些都是电商内比较传统的需求玩法，说白了就是平台在大促期间投放资金，通过高流量放大镜，把营销活动包装成一个利益点（对用户来说利益点就是通过参与活动任务能够换取物品，薅到羊毛，各种白拿），吸引大量新老用户参与并活跃业务板块，活动的最终目的是拉新促活，实现业务营收。

平台拉新

所谓“拉新”，就是拉新用户，增加平台用户数量，如果新用户通过这波营销活动知道了你的平台，了解甚至喜爱上了你的业务，那这波成本是正相关的，此类用户和平台业务可谓是气味相投，产生粘性留存较高，这波钱花的就是有意义的；如果是薅了羊毛就走这波成本就是负相关的，更有甚者是专业的各种羊毛黑产团队，就是吃互联网这波成本的。所以此类运营活动研发必然要接入风控体系对黑产进行识别和拦截，由于涉及到资金较敏感，研发在设计跟资金或可以变现等价于资金的活动虚拟资产时要非常慎重，金额换算、数据存储的设计和编码一定要确保万无一失，而且在设计环节一定要对可能出现的资产风险问题做程序上的合理规避和拦截，比如在运营配置后台要有醒目的字样提示配置者资金流向，大于一定额度不允许提交配置，异常资金动账要进行拦截和报警，接入风控对羊毛党时刻戒备，运营数据要有实时的可视化输出等等。

业务促活

所谓“促活”，就是活跃平台用户，激发他们的参与，增加用户的粘性，让用户“上瘾”。DAU、UV、PV是ToC平台业务的试金石和考核指标，利用大促背景来进行老用户召回、新用户注册通常比日常推广要更加容易，投放广告进行获客快，回报率也较高。对于促活效果作为研发也一定要配合产品、运营进行促活方案的评估，做好数据埋点的统计工作，让运营可以根据线上业务状态进行适时的调整。业务吸不吸引人是研发无法触及的决定的，我们能保证的是用户服务体验，你的服务请求够不够快，流量峰值时够不够稳，数据会不会出现异常或不同步，这些都是要研发考虑和关注且必须保障的东西。

二、需求分析

2.1 运营玩法分析

各类运营场景的活动玩法，诸如日常签到、组团PK、宠物养成、兑换抽奖等等，各种活动玩法无论包装的多么天花乱坠也都只是一个利益点噱头，每个玩法也并不是单一的，可以根据运营场景进行有机组合，增强活动的趣味性、可参与性，吸引更多用户加入进来。简单列举下几种常见的活动玩法对比如下：
| 活动玩法| 趣味性 |活动特点 |任务特点|利益点|研发难度
|–|–|–|–|–|–|–|–|
|日常签到 | 一般 |简单连签高额补贴、高难度任务补签|单一、限次|虚拟&现实资产|低
|组团PK | 高|多人协作|裂变快|虚拟&现实资产|高
|养成类 | 高 |场景代入感强，虚拟现实结合|任务可定制化投放|虚拟&现实资产|高
|兑换抽奖 | 高|博弈心理，概率黑盒，虚拟资产消耗快| 业务场景较通用|虚拟&现实资产|中

2.2 业务需求分析

本次大促业务方需求是希望通过构建一套兑换抽奖活动来进行平台拉新促活，活动周期视活动效果和业务数据决定，业务方期望研发三周内交付使用并正常开量。
简单分析下，如果要完成这个运营活动，需要活动配置服务、抽奖服务、用户账户服务、奖励发放服务等多个服务进行组合才可以支撑。目前的现实情况是，除了基础通用服务、用户信息服务可以支撑需求，其他的抽奖服务、活动服务、用户账户服务、奖励发放服务均没有。之后几轮的沟通后业务方将奖品发放变更为兑换券线下发放减少了奖励发放环节的开发，抽奖服务找到一套可以复用的服务稍加改造，最后确认的开发任务就只有活动服务、用户账户服务。

2.3 领域对象识别

首先，要识别出业务领域对象，运营活动业务场景的动态参与者有用户和运营人员，静态参与者有活动任务、活动奖励、奖品等。

领域对象	业务参与	业务角色	业务权限	业务地位
用户	动态	活动参与者，进行利益获得	无主动权	业务发起者
运营人员	动态	活动发起者，进行利益发放	有主动权	业务组织者
活动任务	静态	业务驱动桥梁	无主动权	利益点介质，业务中间者
活动奖励	静态	虚拟资产介质	无主动权	利益点介质，业务中间者
用户账户	静态	虚拟资产账户	无主动权	利益点介质，业务中间者
活动奖品	静态	利益点	无主动权	业务闭环

2.4 业务场景拆分

从数据、行为维度进行业务场景拆分。所谓“数据”，就是对象的最原子表示，用来构建对象的数据表示，比如用户的数据，就是个人信息、账户信息等，拆分个人信息的最原子组成就是姓名、性别、用户ID等，最终会把这些原子拆分映射成数据库存储的具体字段。所谓“行为”，就是对象之间关系发生的表示，比如用户参与活动任务、兑换抽奖等。
拆解的越接近领域原子（数据）就越靠近底层，能越能获取到关联关系（行为）。这好比是一张建筑设计蓝图，梳理的越明白，看到的边界越清晰，架构方向和出发点才越正确，实施过程中的可调整性、容错性、扩展性、健壮性越高，应对需求变更、未知外部困难的风险能力越强，项目越容易接近成功。

拆分维度	特征	拆分原子
数据	静态、构建领域对象	用户、奖励 、活动任务、活动奖励、活动奖品
行为	动态、关联领域对象	参与活动（用户->活动） 获得奖励（奖励->用户） 抽奖（奖励->用户->奖品）

从业务发起、业务中间态到业务最终闭环，简单梳理下流程如下，圆形代表动态领域对象，方框代表静态领域对象，箭头代表领域对象之间关系即行为，箭头指向代表数据流向。活动奖励、奖品、任务都是整个业务的中间者，起着连接作用；业务的主动参与者，处于业务流向的顶端，通过与业务中间者发生关系驱动业务发展和流转，最终将业务推展向业务闭环。

三、任务拆解

梳理完需求，清楚了需求范围，下面对研发任务进行拆分，落实到每个研发人员。
前端1人，服务端3人（网关封装1人、业务服务开发1人、异步服务开发1人），抽奖服务外部提供。
开发联调两周，测试一周，灰度1~2天，之后开量。

四、研发设计

需求的复杂度决定了研发设计的复杂度，满足业务场景的适度设计，在可预见需求变更的范围内支持可扩展和迭代即可。谁也无法做到一眼万年，不可能一下就设计和开发出绝对健壮、绝对扩展的程序。软件产品的生命周期非常短暂，在互联网产品中更甚，特别是这种运营活动类产品大多数是瞬间的烟火。相比来说，运营活动页面UI的变更频繁，服务端的核心功能较稳定，外部对接的业务需求变更较频繁。
分别从库表设计、系统架构、技术架构、核心流程几方面进行说明。

4.1 库表设计

库表规划

简单列举下表划分，不输出详细的字段定义了，可根据业务场景定制。

表名	功能概述	拆分方案	数据量分析
任务活动配置表	日&总库存，日&总参与次数，奖励资产	单库单表	小，依赖运营
任务奖励配置表	奖励资产额度，邀请&被邀请关系差异化奖励	单库单表	小，依赖运营
兑换奖品配置表	奖励类型、消耗额度、规则限制	单库单表	小，依赖运营
用户账户记录表	用户虚拟资产信息，账户额度	分库分表	中，依赖用户体量
任务活动领取表	用户任务领取关系记录	分库分表	中，依赖运营活动变更
任务活动参与表	用户任务完成日&总维度记录	分库分表	中，依赖运营活动变更
任务奖励流水表	用户参与任务活动记录明细，奖励状态，奖励额度等	分库分表	大，依赖用户参与度
奖励兑换流水表	用户兑换结果，外部交互存根，兑换状态，资产消耗等	分库分表	大，依赖用户参与度
账户明细流水表	虚拟资产动账记录，资金来源去向明细	分库分表	大，依赖入账、消耗

数据量评估

存放全局通用配置信息的表，数据量小，通用查询量是最大的，需要加入缓存抗量；存放用户个人业务信息的表，数据量增幅大，实时性要求高，一般不引入缓存，要做好数据库索引配置，关注数据库连接数、峰值qps数据。
互联网用户体量大，存储数据必然要对数据库进行分库分表。关于分库分表具体要分多少库多少表需要按照实际用户体量进行，比如评估当前业务场景下最多数据量的表应该就是任务奖励流水表，每个用户每完成一次任务则计入一条流水，若现存日活用户100W，运营每天配置10个任务，假设日活用户均完成10个任务，每天的数据量就是1000W，如果持续1年（365天）数据量就是36.5亿。如果项目的生命周期是5年，数据量将是182.5亿，然后我们根据历史经验尽量让数据库单表最大数据量保持在1000W水平，就是182.5亿除以1000W得到需要的分表数1825张，如果按照分库10个，每个单库200张就可以满足使用。以上只是一个举例和大概的推算方式，具体的数据存储和还要根据场景进行调整，况且日活百万的业务算是比较大的体量了，各方面挑战性、复杂性会指数级增长，要具体问题具体分析。

4.2 系统架构

基于微服务环境，通过RPC进行服务间通信。从调用链路由上到下依次是，前端、展示层、业务层、服务层、数据层，应用结构采用的是传统的贫血模型。

• 前端
  大多数为H5、客户端发起，通过API网关进行HTTP协议交互，通常普遍采用JSON格式进行报文传递。API网关的主要职责是将HTTP请求转换为RPC请求、过滤权限、处理用户登录态、限流控制等。
• 展示层
  展示层应用命名为FRONT，它是网关请求的第一道门闸，也是数据输出的最后一道程序，主要负责参数校验，统一的交互数据组装等。
• 业务层
  业务层应用有BIZ、PROC、WORKER。BIZ负责处理业务请求的核心、复杂、多样化逻辑，是所有业务请求的核心应用，负责服务数据的调度、编排。PROC负责处理异步消息，是内部、外部异步通信的应用。WORKER负责完成定时任务调度的应用。
• 服务层
  在微服务环境中，应用皆是服务载体，除了自身应用提供的数据存储、异步消息处理、定时任务调度等内联服务体系，还有外部应用输出的RPC服务，通过BIZ进行服务的发布和输出，业务与业务之间通过BIZ应用进行RPC通信。
• 数据层
  数据层分为持久化存储、缓存、大数据存储。持久化存储是业务主力军，通过关系型数据库承载，是业务查询的主要请求对象。缓存用来进行提高请求速度，通过KV存储，用以热点数据的抗量。大数据存储目前在业务线中只应用到分库分表的数据聚合，通过ElasticSearch索引进行大数据检索。

4.3 技术架构

4.4 核心流程

4.4.1 奖励入账

入账方式

入账提供两种方式，API可以提供内部任务奖励调用，也可以提供给外部进行任务奖励触发时调用，外部任务奖励触发也可以通过监听MQ进行异步入账。

方式	场景	示例
API	内部、外部	浏览XX页面、分享XX活动
MQ	外部	在XX消费一单、完成XX注册

奖励入账流程

奖励入账整体分为三个步骤，奖励记录落库、奖励结算、账户入账。

• 奖励记录落库确保奖励记录数据持久化，不丢失
• 奖励结算采用MQ异步驱动，WORKER补偿处理中间态数据最终一致
• 账户入账依赖奖励结算结果采用MQ异步触发，支持业务幂等

流程图如下：

4.4.2 抽奖兑换

奖励配置

根据奖品的价值划分了不同等级、不同消耗分值的兑换奖励配置。奖品价值越高的配置需要消耗的分值也越多，中奖的概率也越低，这是一种典型的赌徒博弈的玩法。保守的用户会倾向于消耗小分值开价值较低、中奖率较高的奖品，而狂热用户更倾向于积攒分值去放手一搏兑换价值高、中奖率低的奖品。不同的奖励配置利益点是吸引用户参与活动的根本，奖品的配置也要迎合平台业务人群，中奖概率在考虑成本的基础上合理配置，也要考虑用户的参与度和获得感，有效的正向反馈才可以保证活动的可持续性，正向反馈可通过用户自身参与中奖、实时滚动排行榜、奖励配置池的强文案（概率加倍、奖品上新、必得XXX）诱惑用户持续参与，持续活跃。
除此之外，还要关注用户账户的虚拟资产问题，获取的途径和方式一定要有意义，要达到运营目的才进行发放，消耗的方式就是通过兑换、抽奖等途径进行账户虚拟资产去存量。一定不要出现用户账户资产过多导致兑换率较高带来的成本负债，也不要因此调低中奖率令用户反感，导致后续用户参与意愿下降的问题。相反，也不要获取难度过大、兑换难度高、中奖率极低直接导致用户流失的问题。这是个运营策略问题，运营也不是神，需要可靠的数据支持，研发能做的就是各种维度的提供数据埋点支持，兑换率、中奖率、兑换奖励比率、兑换点击率、全盘账户资产入账与消耗明细，等等。

价值	中奖概率	奖池配置	利益点效果
高	低	高端数码，小轻奢，如MacBook、iPad	噱头、高频曝光点
中	中	大多为平价爆款，实用性较高，如日用品、手办、入门数码	留存硬通货，去存主力军
低	高	附加值较低，如低额优惠券、满减券、免息券	零&低成本活跃

抽奖兑换流程

抽奖兑换要考虑用户体验，实时性较高，但是处理逻辑的复杂性不可避免，一般可以前端加动画效果降低用户的等待体验。主要流程大致分为四个步骤，兑换校验、账户动账&入账记录写入、创建兑换流水、抽奖。

流程图如下：

五、项目总结

• 深入挖掘需求，站在全局视角
  对于研发来说，万事开头难的第一步便是需求分析。充分了解需求、消化需求、甚至要参与项目过程中需求的提出、变更和优化。作为功能的实现者，需求实现的好不好，第一步要看对需求的理解到不到位，个人认知是否与产品、业务的理解是吻合的。有些程序员较为重视自己的业务实现而轻视需求分析和理解，潜意识里觉得需求都应该是产品经理的职责范围，自己只负责实现功能就可以了，工作范围划分确实如此，但实际工作中任何一个程序员也绕不开需求分析。先了解需求产生背景，需求范围边界，需求完成难度，需求给已有功能或系统带来的变更，需求的最终目的，需求的关联方等等，要全局的摸清楚，对于最终的项目成败起到很重要的作用，如果理解存在偏差甚至南辕北辙，最终带来的是无尽的修改和加班，最终还有可能影响需求的交付及效果。
• 提高专业度，在实践中提升
  提到专业度，这是一个比较宽泛的概念。作为软件研发一员，不光要有过硬的研发技术、实践中积累的大量经验，还要有对业务的充分理解、对现实世界进行概念边界拆分、对服务架构的能力。工作需要全情投入，项目需要用心呵护，优质项目离不开优质的人员和良好的沟通协作。
  大促是练兵场，因为高流量冲刷下，系统日常的不足会被放大，日常看不出的问题，大促时都会原形毕露，所以这是难得的机遇，全业务链路在高流量下进行服务协作，是日常压测模拟不出来的，自己的技术应用、方案落地到底如何，大促之后的系统指标会是最好的答案。系统的稳定来源于技术知识的极致运用和丰富的实战经验，面对技术革新，不能安于现状固守不前，持续学习并实践，在可以承受试错成本的项目中尝试革新，把一点一滴积累的实战经验反馈在未来项目的优化、迭代、升级中。软件开发是一个实战科目，看书看课是学方法论、开拓技术视野，学和用是天与地不相干的两回事，强化练习，敢于尝新，多做总结，才能在这项实战科目中不断提升，逐渐变强。