前言

运营是个很泛的概念，有用户运营、内容运营、活动运营以及产品运营等，看过运营之光的同学可能还会接触过更多的运营类型，本文这次聚集的是商户运营，这个领域不像用户运营那样有一些指导思想、模型可以实践（最具代表性的是AARRR模型），没有可复制的行业经验，没有理论支撑。
在做商户运营之前，一直带着大家在做模型以及工具的建设，包括商家自身的经营管理、配送管理、商品发布等，但是随着今年基础模型入中台，以及商家提质提效的战役后，模型基本沉淀下来，商家的工具体验上也逐步达到优化极限，在经历了短暂的迷茫阶段以及和业务持续对焦规划后发现了另外一片蓝海，那就是从平台的视角怎么帮助商家做好运营，此前我们提供了很好很丰富的工具给商家使用，但我们却忽视了我们面对的大部分商户是一些白领、高校商户（当然也不乏KA/连锁等运营能力强的商户），他们显著的特点就是自运营能力差、工具上手很慢，需要销售指导。我们给商家提供的数据、营销等工具的专有词汇几乎没有为这群人考虑。

体系抽象

前期我们找到了一些抓手，做了商家任务以及奖励中心用于平台通过激励来保持商家的正常经营，做了商家的信用分，通过扣罚机制宣导平台底线。
做了这些后还是意犹未尽，总想在这些事务里找出一些规律、体系，花了些时间研究了一下用户运营的模型，总结出了商户运营的体系。
先列一下用户运营的AARRR模型

用户运营增长模型

AARRR

用户拉新Acquisition
用户激活Activation
用户留存Retention
用户推荐Referral
商业收入Revenue

商户运营增长模型

AAGRR

新签Acquire
激活Activate
成长Growth
管控Regulate
营收Revenue

针对商户的运营重新做了新的定义，留存换成了商户在平台的成长，推荐在商家的场景上并不合适，更多的是通过销售体系的商机或者线索去做新签，此外新增了管控，从外卖资质的准入门槛以及平台健康的视角上来看，需要一定的平台管控能力来达到商户在平台上的良性循环。
有了这样的一个定义，那就能很明确的知道我们在AAGRR模型上需要做什么，而不是零星的工具独自建设，比如在新签上我们需要更优质的商户，那需要我们建设POI的优质标签模型，在激活上新店的冷启动怎么做流量加权，怎么做好新店引导帮助商家快速营业，在成长上我们怎么做好持续的激励，在管控上如何通过信用分的管控平台规则，在营收上怎么通用智能补贴帮助商家及平台成本最优等等。

运营工具建设

工具建设重点讲任务及权益体系，此外还有商家等级建设（后续添加），这三块组成了商户运营及成长的核心功能。

任务中心

//TODO，待补充

权益中心

权益是激励商家最重要的手段之一，是在商家成长阶段最重要的一环，早期的权益是和任务绑定在一起，当某个任务完成后，直接对接权益方（比如流量、金融等）下发权益，后来在做商家等级、饿掌柜（售卖权益给商户）的时候发现也需要使用同样的权益给到商家，这个时候就不可能各个工具再去对接一次，这就想办法把任务里的权益独立出来，成为权益中心独立系统。为此还深度讨论及分析了任务和权益的定义及职责边界

权益
1、指公民受法律保护的权利和利益。如我国《消费者权益保护法》、《妇女儿童权益保护法》等所说权益。
2、会计学上指资产。属于所有人的叫做所有者权益，属于债权人的权益叫做债权人权益。两者总称为权益。
任务
任务是日常生活中，通常指交派的工作，担负的职责、责任。在众多游戏中
有目的的指引玩家进行游戏活动，并给予玩家一定奖励的手段，即为游戏任务。

统合下来商家任务和权益的特点如下：

• 权益获得的途径多样，可以是奖励、购买、符合等级以及做任务的方式
• 权益有独立的门槛，下发的任务目标不一定和权益门槛直接挂钩
• 商户在享有权益的同时需要时刻检查是否符合门槛
• 权益有履约行为，商户为保留住某项权益而自发进行的商户行为
• 商户任务：商户通过做任务工具下发的任务来获得某项权益，这里的任务具有很强的指派属性

如下图，权益、任务以及其他发放渠道的区分。

权益发放流程

权益中心需要解决如下问题：

• 对外减少和权益方对接成本
• 对内统一接入姿势
• 减少稳定性保障投入

权益中心建设

如上图，在接入层定义了标准的接入方式，用于解决每新增一个权益就需要再次对接的痛苦，此外我们还有一个防腐层，尤其是在接入方比较强势的情况下，还是需要我们去定制接入代码以转成我们的标准接入。

运营策略（方案）建设

在持续不断的工具建设中，我们在运营端不断的在给工具做一些管理后台，在商家端做工具表达，其中在运营管理后台的操作上无外乎是选定一批商户，符合什么样的规则，最后执行相关流程或者动作（比如给商家发任务、提醒商家整改、给商家某项权益、展示招商入口等）。
此外在深入运营工作的时候也发现他们平时的工作方式：发现问题->找出问题主体->针对问题主体做运营动作->此次问题复盘
举个比较典型的案例，合规域的商户整改：

商户整改流程

从DDD的战略分析视角来看，这里面的问题域是“商户整改”，子领域为合规商户策略、治理流程以及治理方式，再结合其他的业务场景，抛开业务依赖从技术抽象的视角上来看，需要建设策略、流程以及行为这些通用技术能力。（PS. 通用能力的建设也是服务于某类特定场景来建设，建设大而全的系统返而会因定位问题、各业务兼容问题以及研发支持能力成为业务瓶颈）。
以此项目为契机我们构建了如下的架构用来支撑商户运营的日常工作。

运营基础架构

运营策略

流程中心架构

流程中心架构

在流程引擎上复用了开源的流程引擎，非常轻量、支持bpmn2.0协议，我们在此基础上扩展了里面的Task以及UserTask模块，用以支持通过rpc的方式做微服务流程编排。行为中心的建设可以参考权益中心那块，总结起来就是把非标准的触达动作标准化，每一个行为都有一个唯一的id以及模板参数。

可视化流程编排

数字化运营（持续建设中）

让我们再次回到运营的日常工作中去，我们给运营提供了非常方便的策略、流程等工具，但是基于什么样的分析才会去做针对性的运营呢？进一步深入运营流程里面，运营同学在做每一次的策略时都会去找商分同学出数据报表，用于在策略圈商以及策略制定上做数据参考，在策略下达后还需要提需求给商分同学做数据复盘，下面整理了一些运营的日常活动路径。一次整体流程到数据复盘超过1个月。

运营决策流程

再提炼一下，在运营的日常工作中，对数据的需求分为如下三类，辅助分析、策略推荐、效果复盘。

数据闭环

针对这三类数据场景我们需要构建如下架构

image.png

辅助分析

核心能力是需要构建OLAP分析能力，间接的是需要我们整理好用于分析的dws或者ads数仓层，在OLAP引擎的选型上，可以有很多比如需要预计算cube纬度的kylin，实时处理时序数据的Druid、基于内存计算的Presto以及基于MPP架构的GreenPlum，当然阿里云上还有ADB以及Hologres等多种OLAP引擎。

策略推荐

策略推荐上更多的是需要结合算法能力（这方面本人算是个弱鸡），比如在营销活动的设置满减力度上，满X减X，需要给出近似最优的推荐值。

效果复盘

效果复盘和前面讲到的盘面分析结合起来看，只不过需要再增加一个策略纬度，针对这次策略命中的商户看数据复盘，此外还需要再建设指标订阅能力，这类指标提前设定好的场景挺适合用kylin。我们在设计指标系统服务层这块引入了GraphQL，它是一个用于数据按需获取查询引擎，经过一些适配，打通了公司内部的RPC间的数据获取。

整体架构

下面的架构还在持续建设中，目前建设好的有策略中心及指标系统，在实时数仓上有少量建设，离线数仓还在整理过程中。

image.png

最后

这篇文章讲了太多东西，是一个从理论到实践的一个整体历程，但未深入到每个模块及技术的细节，后续如果有时间再分篇章详细讲一下里面部分模块的细节，包括模型设计、抽象能力建设等。