必读 | 回顾2020年最掉头发的一个项目

2020年精力分配比较多的一块，是围绕消金业务增长，做产品上的运营能力建设，也是工作以来独立负责的第一个比较大型综合的系统。

现在想想过程很不顺利，因为没啥经验走了很多弯路。这次开个“上帝视角”，宏观回顾下应该怎么去做这个事情。希望以后类似工作能做得更高效。

 

01

背景

跟大多数做消费金融业务的公司一样，“用户增长”永远是一个经久不衰的话题，里面也有很多值得学习的增长策略和玩法。

我本身不是做增长策略，但是作为系统产品，如何利用自己的能力为业务赋能，提高用户增长效率是我需要考虑的问题，所以需要建立一套为业务增长赋能的整体系统方案，是今年工作的一个重点，这也是去年年终述职定下的大方向。

 

02

目标

为消金业务增长团队，提供一套免开发的增长策略系统解决方案，能够满足复杂的增长策略定制化和自动化落地的诉求。

PS：实际上其实完全免开发是无法做到的，即使能做到也是极高的研发成本。系统要做的就是尽可能满足常用场景，大型活动以及特殊运营策略，仍然需要开发。

 

03

业务场景调研

通过跟业务同学反复沟通，以及调研市面上同类消金产品的增长相关事项，从策略逻辑上可以抽象为两类：

• 主动营销，从时机上可以分为“定时批量营销”和“实时触发营销”，主要区分是是否由用户行为出发。这种方式主要特征就是“用户被动，业务主动介入”，由策略团队提前制定好规则，对预定的目标客群进行营销，业务目的上比较直接。

• 专题运营，也就是常见的运营活动，比如抽奖活动、邀请有礼活动、红包雨活动等。这种方式的主要特征就是“业务被动，用户主动参与”，这种策略本身起到的是制造氛围的作用，一般是借势配合节假日使用，业务目的上比较间接。

这里总结一个调研的经验就是：一听二问三确认，所以至少有3轮沟通。

• 听，听业务描述如何落地做用户增长这个事情，简单说就是怎么做的，目的是为了进行流程梳理。因为调研对象不是具体的产品，这里可能信息会比较散，竖起耳朵听就行。

• 问，主要沿着业务流程问2点：分支环节和特殊场景。分支环节主要是在主干流程基础上，是否有其他分支，场景则主要按照4要素即“人+环境+时机+事件”进行描述。目的是梳理全场景，尽量不重复不遗漏。在场景划分上借鉴《有效需求分析》里面的标准：独立、可汇报、可暂停。

• 确认，将输出的业务流程和场景跟业务讲一遍，确定诉求，因此开展后续的产品设计工作。

按照抽象的两类落地方式，输出对应的业务流程和场景。

1）主动营销

业务流程：

梳理场景和需求点：

2）专题运营

业务流程：

梳理场景和需求点：

对于活动组件可配，这块是我觉得最复杂的一块内容，主要体现在2个问题：

• 什么样的活动需要支持可配？

• 组件拆分的粒度到什么程度？

最初1.0的想法是，通过跟业务沟通未来可能会进行的活动类型，以及调研市面上竞品主要的活动玩法，所以准备将每种活动抽象成【单元】，提前定义好单元，上线一个活动就配置一个活动。

例如九宫格抽奖活动是一个单元，包含活动标题、规则描述、抽奖转盘（奖品概率池）、分享组件等揉在一起。

但是后面觉得这个粒度太粗了，而且没有体现《领域驱动设计》一书里面提到的“组件需要靠近业务变化原点”的原则，所以重新又构想了一遍。

2.0的构想是，在【单元】基础上再拆一层，拆到功能组件，若干个功能组成一个活动，举个例子：

[1] 本质是一个固定按钮，提供的能力是“可点击+跳转一个页面”；

[2] 和 [4] 是一张固定图片，展示活动title和补充信息；

[5] 是一个分享能力，支持拉取微信QQ会话框，发送分享图文，图文样式和跳转URL可配；

只有 [3] 比较复杂，除了展示配置的优惠券信息这个能力外，还包含活动逻辑。这个就看后续其他活动是否大概率会重复用到这个能力，如果有，那可以把逻辑框架写到组件里；如果没有那还是临时开发。

通过多个功能组件拼接，形成一个完整的活动。然后输出一个活动URL，供曝光广告跳转。

因为比较复杂而且设计和开发成本较高，做这个能力的前提是，业务有被验证正向收益的案例和需要频繁上线运营活动的诉求。今年自己没有推动做这部分，一直还在构想中，原因就是目前上线的临时活动一直未被验证。

 

04

系统概要设计

1）产品架构

在详实的场景调研的基础上，才开始真正产品的重头戏系统设计上。不像做策略或者体验方向的产品，系统产品往往没有MVP一说，或者即使MVP也是一个需要全流程涵盖的框架体。可以没有后台界面、可以没有配置文件，但是实例模块、流程节点一个不能少，否则系统是残缺的，没有业务可用性。

主要从5个层次进行产品架构拆分

① 系统用户：系统针对的目标场景主要为了部署+分析需要，所以面向运营和业务分析人员（角色区分，实际可能是同一个人）

② 管理平台：业务人员直接可视化操作的后台。设计原则是：一个模块负责一类事情

• 客群管理：通过上传、标签筛选等方式新增、管理客群，是营销策略的前提

• 营销计划：创建、管理营销策略

• CMS：管理资源位和广告

• 专题活动：新建、管理专题活动

• CRM：管理用户信息，包含画像标签、基本信息、业务信息、营销信息等

• 模板管理：用于新建营销策略用到的实际营销模板。包括消息模板（短信、push、AI话术等）、金融属性调整（提额策略、降费策略）、权益（优惠券、红包、实际奖品等）

• 运营报表：收归所有的营销策略、专题活动数据，自动化统计收益指标

• 系统设置：日志、基础配置、权限等通用功能

③ 应用服务：系统提供的基础服务能力，非后台类功能

• 消息通知：聚合了包括短信、push、AI电话、弹窗在内的消息触达能力，形象说就是“解析模板内容+发送”

• 金融属性调整：整合金融属性调整能力，“解析模板内容+调整用户金融属性”

• 权益奖励：定义权益规则，负责定义优惠券、红包等并执行绑定用户的动作

• 人群跑批：支持按照策略实时触发or离线跑批，需要过滤免打扰周期内的用户

• AB Test：负责按需随机分流，并将实验域用户进行保护

• 系统监控：按设置阈值监控运营数据，并提供及时熔断能力

• 自动化埋点：所有环节按照规范进行埋点，通过kafka方式落入数仓作为基础数据源

• 活动功能组件：定义的各类活动组件，组件内包含表现层+逻辑层

④ 数据加工：因为系统一般不使用源数据，而是由一定逻辑加工后的生产数据。独立一个数据加工层

• 标签库：定义的各类画像标签，由标签规则+标签值组成，用于筛选客群

• 实时action：定义的用户行为触发场景，例如打开App、访问首页、点击button、退出App，用于实时营销

• 特征变量：定义的用户维度的个性化参数，例如{姓名}{性别}等，用于个性化营销场景

• 黑/白名单：处于客诉过滤/实验场景，特殊名单，判断优先级较普通客群要高

⑤ 基础数据：主要是各个业务系统抽取的源数据，一般需要进行生产加工后才能供系统上层使用。消金业务数据源主要包括业务自产数据、风险数据和集团公共数据3部分组成。

 

2）埋点体系

这部分单独拎出来讲就是，最初跟进项目时对系统埋点不太重视，只关心系统能力上是否建设完善。但是后面因为频发的性能问题、策略冲突导致需要排查问题，以及分析增长策略收益时，方才发现埋点的重要性。整个增长业务的数据链路粗粒度上可以视作如下：

前半部分是营销阶段，更多的是业务为转化用户而付出成本；后半部分是获利阶段，被转化用户完成了目标动作（例如授信、用信）产生了业务收益。

业务增长是围绕用户来做的，所以运营系统的埋点需要按照【人】的维度全流程串联起来整个流程。埋点需要满足的诉求就是业务根据一个用户ID能够查到是什么环节被命中的，什么环节流失的，以及流失的原因是什么，收集了这些基础数据，如此才能迭代优化业务增长策略。

 

05

系统详细设计

1）名词梳理

先梳理一下系统内的名词概念：

• 标签：定义离线特征，例如设备型号、用户年龄、地理位置、订单状态等

• 实时action：定义实时行为特征，例如 登录、访问、点击、退出等

• 人群：分为实时人群和离线人群，通过实时action圈选和离线标签组合圈选的方式进行圈选定义的标签/action集合，最终输出的是一套名单

• 消息模板：定义不同的消息发送内容，可以有push、短信、公众号消息、站内信、弹窗等类型

• 营销计划：将人群和消息模板关联的策略，是业务主动触发的营销形式

• 广告：定义某个运营活动的入口，提供信息披露、吸引点击的目的

• 广告位/资源位：放置广告的地方，一般是开发的固定入口

• 优惠券模板，券规则的定义框架，本身不具备业务可用性（例如饮料）

• 优惠券，在券规则框架下的实体对象，例如3天免息券（例如饮料中的脉动）这样的券规则，以及库存、分享通知等

• 优惠券码，具体一张免息券（具体某一瓶脉动），唯一码值标记

• 优惠券包：若种优惠券合起来的，奖励时会将将券包里面的券全部发给用户账上（类似于旺旺大礼包）

• 提额/降费/红包，类比优惠券

• 权益：对奖励给用户的积极权益的一个抽象概念，类型可以是优惠券，可以是红包，可以是提额资格或者实物奖品。一个奖品定义包含类型、库存等属性。奖品的中奖概率也是在里面配置上的

• 组件：主要是通用功能组件化，例如分享、通知、抽奖等

• 专题活动：是个大实例，包含主要包含活动基本信息、活动组件、奖品。其中活动组件有非常非常多的样式，开始可以提前定义好一些常用组件

2）实例建模

我自己认为系统建模是影响系统能否良好运转（可扩展、稳健、易用）的一个最重要的设计环节。对象与对象之间的依赖和对应关系直接体现了系统产品对业务的理解深度。

营销计划建模：

专题活动建模：

实例建模是从系统视角结构增长业务，会影响数据库设计。最初1.0的时候经常考虑不周把很多实例对应关系固定成1:1，导致无法良好扩展，因为一些小需求变动甚至有可能导致系统重构。

不过过多的多对多关系带来的问题是开发成本大，所以要考虑的事情就是做好两者平衡，不能为了过于快速简单忽略业务扩展性，但是也不能为了无意义的通用让系统开发成本太高，失去提效的意义。

3）系统后台设计

后台设计是整个系统设计里面最“简单”的部分，后台的本质就是“表单+对库的增删改查”，有成熟的系统交互可以参考。所以这部分整理一下示意，具体界面不放了。

客群管理：

营销计划管理：

专题运营管理：

CMS：

CRM：

营销模板：

运营报表：

系统设置：

 

最后

这套运营系统本质上就是一个大批量数据加工和应用方案，以往不被重视的性能问题，在这套能力建立的过程中尤其被重视。线上问题往往不是因为逻辑不严谨造成的，而是因为在有限的并发下无法短时间处理超大的数据。所以后续在类似的项目上，不单单只是功能测试，压测这一点也需要考虑。

这套能力到现在线上实际没有做到写的这么全，很多地方也没做到设计的比较合理，所以这里也只是开个上帝视角，如果重来一次的话应该会这么走。不过方向总是没错的，下半年能够帮助消金业务带来不少的增量收入，可以印证这套能力的价值。

2021，希望可以再上一层楼。满怀希望！

↘好文推荐：

盘点：2020年PMCAFF最受欢迎的文章！

字节跳动的产品经理是怎么工作的？

优惠券设计 | 从生成规则到优惠金额分摊

点个“在看”吧