用户运营平台产品设计指南
“用户画像”、“用户标签”、“大数据”这些名词是我们近些年来常听的词，可是这些词却很难直接的产生价值，我们都知道大数据有用，画像也有用，但到底怎么用？又怎样具象成一个产品却很少人能够说清楚。
如何采集数据，形成服务再到供给运营，这也是这篇文章想分享的核心。
在市场上神策、易观数科会将其称之为智能用户运营平台。这篇文章会和朋友们阐述用户运营平台的产品设计，帮助大家理解其底层支持和产品表现。
产品设计的讲解将分解为3部分，分别是：选用户、做运营、看效果。
一、产品建设背景
产品建设的背景如下：
1. 数据不可用
数据不可用原因有很多种，没有埋点落库是比较好理解的。
其次则是数据分散，没有将分散在不同业务的用户数据进行关联，这会导致用户画像不够立体，甚至无法识别是否是同一用户。
假设我们无法识别用户在成交前的关键路径，则很难分析其决策偏好及流失过程，运营的深度也会受限。
而许多数据的使用方式也仅停留于浅层的报表应用，数据分析很重要，但分析后也要将其运用于运营。
2. 运营无法管理
这一点指的是大多数企业运营管理都强依赖人力，缺乏平台沉淀运营逻辑。当人员变动，依靠人力、代码维护的旧逻辑会很容易被忽略，而运营策略的跟踪、改进就可能不了了之了。
如何让不同的角色迅速了解自身业务对用户的运营策略和效果，这也是建设的目标之一。
3. 运营成本高
运营成本高，原因是投放、干预类的需求非常高频，但却每个需求都需要经过产品、研发、测试及发版的过程，就算再高的上线效率，上线的周期也会滞后。
复用率低，则是由于依赖研发的运营策略很难规模化。
4. 效果追踪困难
效果追踪困难主要的原因是较难形成统一的业务标准，评估标准不同则无法对比。我们之前听过一个段子汇报时每个部门的ROI都是正的，但企业却在亏损。虽说是段子，但却很真实。
标准不一，只看正向指标不看负向指标，那当然人人都是喜报。每个业务的形态都不一样，标准很难制定，那能否尽量的去找到运营的同类项呢？
这4点就是用户运营平台想解决的问题了，接下来会进行产品核心架构解读。
二、产品架构解读
用户运营平台的产品分解为：选用户、做运营、看效果。
将其分解为产品术语则是：在圈选目标用户并设置运营规则，基于运营渠道发送指定运营内容，效果追踪后再进行自助优化调整。
对上图的解读如下：
- 用户圈选：选择访问商品页未成交，且有工作的男性。
- 运营规则：今天晚上8点对用户进行风控判定，如风控通过进行A/B实验，1组由推荐算法决策推荐商品，另一组由运营设置渠道和商品。
- 运营渠道：选择弹窗资源位渠道。
- 运营内容：设置弹窗落地页跳转商详页。
- 效果评估：投放后追踪漏斗数据及成交数据。
选用户对应用户数据平台，做运营对应规则引擎和用户交互平台，看效果是分析中心。
大致理解了所提供的运营服务，我们再逐步理解这核心服务对应的底层支持和产品表现。
三、用户运营平台：选用户
选用户对应前文的痛点是数据不可用，我们要让数据可用，也要解决数据分散的问题，将分散在不同业务的用户数据进行关联，识别是否是同一用户。
最终实现可视化选取目标用户。
1. 底层支持：用户数据平台
要让数据可用，需要建设的是用户数据平台，它是一切的开始。哪怕不用于实际干预用户的运营，进行画像分析、个性化推荐也离不开它。
从用户运营平台的角度，我们要去采集全站的数据让数据多元客观，然后去过滤掉无效、异常的值，在关联成为同一用户，保障画像更为立体。
最后则是将一条条明细的数据，加工成可用的圈选条件，并将其供给运营。
理解表现层之前先了解其底层支持，知其然也知其所以然。
1）数据采集
运用数据的前提是拥有数据，采集数据则是第一个环节。人工采集就是上传数据导入数据库，自动采集则是埋点上报、第三方数据传输相关的工作。
2）数据处理
第二个环节是数据处理，主要包含了数据落库后的清洗、合并、去重、加工4个步骤。
清洗指发现并修正数据中可识别的错误，包括检查数据一致性，处理无效值和缺失值等。
合并和去重概念，关于数据上的理解可以查阅的这篇文章:《Tableau基础·如何合并你的数据？理解与逻辑（上）》，Tableau已经描述的非常全面了。
合并的目标有2个，一方面是关联不同业务的核心数据，让用户画像更为立体。另一方面，在离线查询大批量的时候查询速度能够更快。
不同的数据存储在不同的表，我们希望在查询订单时同时查询用户的关注数据，常见的办法是连表查询。
但这种方法只适合小量的数据，当数据量达到百万级开始连表查询就会非常慢了，而这个时候就会用到宽表，它可以理解为一张拥有大量数据字段的表。例如在订单表增加用户的公众号关注数据。
加工逻辑，则涉及到条件的组合。
我们的原子数据如：年龄、性别，这是可以直接使用的查询条件，但如果我们想要的是“中年男性”这个条件，就涉及到加工了，它能让我们查询数据时更加敏捷。
3）数据管理
数据采集、处理后下一个环节是数据管理，它是数据服务的基础，它负责定义数据标准，管理数据权限，并保障数据质量。
标准是指，我们怎么定义一个完整的数据，需要有名称、值类型、取值的范围、加工的逻辑等。而权限则决定这个数据归属于谁管控，密级程度又决定了不同角色的操作，包括读、写以及使用。
最后的质量部分则是通过对应的监控措施保障数据质量，数据是否及时更新，更新的进度和速度是否符合预期，生成的数据是否符合规范，量级波动是否达到了告警线。
假设一切正常，它又是否正常的被下游消费，消费过程又是否存在阻塞。
4）数据服务
数据服务，这个词广义的说数据的采集、处理、管理都是一种服务。在这里特指的是供给实际运营的服务，例如：人群服务、风控服务、运营服务。
① 风控服务
具备了数据，就能够对不同的场景制定不同的风控评分规则，用于识别黑产、金融产品售前评估、金融产品的定价。异常监控则指当号码、账户发生了冻结等情况可能造成用户的违约，在金融产品层面做预警。
② 运营服务
智能推荐实质也依赖于数据平台，通过用户的特征输出推荐结果。RTA则运用于广告，基于特征决定是否参与定价。
③ 人群服务
人群服务会运用于用户运营平台的“选用户”环节，数据的管理能够提供可选择的用户条件，进行前端渲染。
而选完条件后则涉及数据的去重，不同人群包之间的计算，在最后的运用环节又涉及到了加解密。这个部分在下文会详细描述。
描述完了底层支持，下一个部分就是用户运营平台的表现层“用户圈选”，那数据平台到底是怎么为“用户圈选”提供能力的呢？
2. 产品表现：用户圈选
在选取用户时须考量的产品功能为：圈选方式、圈选频次、圈选条件及人群服务。实质上这4个功能的底层支持都来自于用户数据平台，用户运营平台则负责服务的运用及表现。
1）圈选方式
① 条件选取
这是在可视化、自助化选择用户条件后，通过与其取值范围进行比较经计算生成人群数据包的一种形式。
一般来说，具备抽象为可视化条件的数据使用较为高频，数据准确性较高。它的底层原理是对条件和计算进行标准化，然后拼接类似SQL的数据查询语句。
② 智能选取 & 自主上传 & SQL提取
智能选取、自主上传、SQL选取，是对“条件选取”的补充。
智能选取主流分为2类，1类是用户规模无法满足要求时对用户进行相似度计算，从而扩大用户的规模。
另类的运用场景则是运用算法模型选取用户，结合运营的效果数据对模型进行调优，不断寻找最优的高响应人群。
SQL选取与条件选取的原理相近，它主要运用在数据未被标准化，无法可视化选择的场景。
另一个场景则是追求更快的查询速度，因为标准化的查询语句追求的是通用性，查询速度对比自主撰写语句时大多较慢。
2）圈选频次
① 单次提取
单次提取，指一次性提取数据，当前时间提取后数据不再发生变化。
运用的场景多为在做运营实验，而运营实验的效果还不够好，暂时没有固化为标准的运营方案；另一个场景则是用户运营的规模数据量大，担心投放时再取数其时间过长，先提前提取数据。
② 动态提取
动态提取，指相同的条件在不同的时间提取。这种情况，基于数据的时效性，其数据可能会发生变化。常见于定期固定的运营计划，如：用户成交10日后赠送积分。
自主上传则没有动态提取这一说法，都是一次性的操作。
3）圈选条件
下方的交互仅面向于条件选取，而SQL、上传、智能的交互都是不同的表现方式。
条件的来源主要有4种，除了接口上报都应来源于用户数据平台所管理的数据，然后再基于其数据标准，渲染前端的页面。
- 实时事件：主要面向时效性要求高的场景，是用户实时发生的行为，例如用户访问某页面。
- 接口上报：实质上是非标准化的实时事件，一般在临时性的活动会使用，如活动任务完成。
- 用户特征：对时效性要求低，一般用于定时的运营，且无须查询用户的关联数据。
- 宽表字段：概念与用户特征相近，但主要用于数据时效性要求低且需查询用户关联数据的场景。
在这里额外描述一下关于“用户特征”和“宽表字段”的区别，详见下图：=
关于非实时的查询条件主要分为宽表字段及用户特征。
为了能够快速地查询更多用户数据，会将用户数据基于userId集成在一张数据表中，由于存储了大量不同业务字段，也称之为宽表，如：在订单表基础上增加用户年龄、性别等字段。
宽表字段是明细数据，数据量多意味着查询的速度会受限，但你也能迅速地提取其关联数据；当需要快速进行点查询且不需要用户的关联数据时，则会使用用户特征。
例如：需要对前一日关注公众号的用户并发放短信，会使用具有明细数据属性的宽表字段，从而获取其手机号。但如果是在活动的页面，需要实时判断用户是否关注从而引导用户关注，则会使用用户特征。
理解了条件的来源，下一个部分会介绍条件的比较方式，它和数据的值类型有关。前端页面也应基于值类型渲染比较条件。
时间条件一般不会进行枚举，因为日子一天天的在过，很难将它数清楚。
其对应的条件选择交互式日历选择器或日历范围选择器，而动态时间则一般使用T+N的形式，在这里T指的当时（一般为天），而N也可以为负数。
例如：关注时间=T-1，意思为1日前关注的用户。
而数字、字符串的比较方式都相对接近，只是数字和时间能够有“大于”、“小于”这类的比较方式，但字符串没有。
4）人群服务
前面的部分描述的是如何选取用户，而这一部分则是选了后还要做的事情。其执行流程如下：
通过条件查询得到了人群包，然后对不同人群包进行交并叉相关的数学计算。在计算后进行数据去重，最后再查询这批用户的数据提供于内容话术及接口使用。
接下来详细介绍下这几种服务：
① 交并叉
② 去重
去重就好理解了，核心原因是防止数据重复，避免因数据重复在查询数据时浪费资源。
③ 关联数据查询
这里分别在内容话术和接口使用提供2个例子。
对于内容话术，我们推送了一批待续费保单的客户给予售后部门进行引导续费，但如果需要能够指导策略，还需要给予售后关于的保单详细信息，如：保额、保费、投被保人关系等。
而接口使用，则与调用接口要求的入参有关，如风控接口一般会需要用户的身份证和手机号等。
四、用户运营平台：做运营
产品和运营的工作主要为策划和执行，而痛点也由此而生。
策划的痛点是过往的逻辑难以追溯，很难能体系化地了解过往的运营思路，过往面对谁做了什么事效果如何，当前又是否正在运行？我们的新方案总是从零开始，需要重新地踩过往的一个个坑。
而执行痛点则是要上线一套成体系的运营方案链条太多，不同任务完成的方式不一有的需要配置有的又需要研发，不仅接口人不同，上线的周期即慢又零散，非常依赖于项目管理的能力。
有没有一个方式能够尽可能地让多变的运营规则实现配置化，让运营能够实现线上管理呢？
这里的解法是规则引擎负责运营规则的组合，而交互平台则提供组合的内容，再提供不同运营视角的管理视图以及自助化的配置工具。这2者如果能够做到极致，那就是no-code。
1. 底层支持：规则引擎与用户交互
1）规则引擎
规则引擎业界也称自动化营销平台，规则引擎这个名词有点抽象，不妨理解为但运作一件事的规则或逻辑。
这里又来到了耳熟能详的的5W2H法环节，规则引擎是什么时间对什么人在什么地方以什么方式做什么事（5押）。
什么时间做和对谁做是触发条件，对谁做在实时事件触发的场景，例如用户签到立即下发奖品，这种情况事件即是触发条件又是判断条件的一部分。
判断条件的本质是过滤，例如过滤昨日签到用户中的黑产用户，除了用户本身的特征，我们还会接入风控、推荐等接口。
流程控制从计算机运算角度是改变流程执行顺序的指令，浅层的理解为判断条件和执行条件的衔接器。
在实际运营中不一定每次判断生效都会立即执行，会加以时间等待或者分组执行。例如：当用户访问页面后等待15分钟触发运营逻辑，等待指令就是流程控制。
执行条件就相对简单了，但在思考的时候不要被束缚。
一切对用户的运营干预手段都可以是我们的覆盖范围，无论是触达还是弹窗，无论是非人工、人工还是智能，做B端重要的是连接和共赢。
理解了规则引擎核心的4要素，下一个问题就是如何能够让研发、产品、运营不同的角色都可以使用，适用的角色每向前一步，易用性就更高一层。
如果连研发敏捷提升都无法做到，那这套引擎就没有存在的意义了。
关于敏捷，我理解的是低代码或者无代码实现运营需求，并且能够自主测试无须发版，所以对应的解决方案是可视化的拖拉拽，上图是易观数科的智能运营Work Flow，是一个很好的案例。
但对比no code我个人还是倾向于low code，no code基本是通用的模型和标准化的模版，无需研发、人力投入，即可快速上线应用。
它可以参考网页、活动等标准化服务的提供商，这种方式的缺陷是，强依赖于模版。如果不具备适合的模版，其实用性会大打折扣，而且很难兼容复杂逻辑，最简单实际上也最不灵活。
low code，则是通过建设一些基础设施，实现部分逻辑配置、部分编码，实现部分逻辑可配置，测试可自助。适用于有一定研发理解能力的产品、运营等同学。
2）用户交互
交互，顾名思义是交流与互动。规则引擎负责规则组合，而交互内容负责规则最后的一个节点：执行。
我们希望做用户运营便需要与用户产生联系，这则依赖于能够触及用户的渠道，不同的渠道又有各自特点交互内容。
这一章节没有太多复杂的底层支持逻辑，基本就是渠道能力的建设，渠道内容的维护和管理，更多要关注的反而是视野。
这幅图枚举了大致可能与用户交互的渠道以及渠道支持承载的内容方式，渠道不仅推送，还有企微这类私域的聊天讯息，其次还有电话对应的人工服务以及站内的资源位。
下发的内容也不仅是文字、图片，也可以下发任务或者奖品。任务可以理解为你希望用户完成的事情，奖品则是完成什么事情后你所要提供的激励。
在这里大家可能会有的疑问是，落地页不就一般承载了任务和奖品么，这一点来说是的。但就是有的场景会没有落地页，例如智能外呼、短信。这时候则会运用到通用化的用户任务体系和奖品了。
至于说内容的产品支持工具，还包含二维码、海报、短链、落地页生成等，这些产品怎么实现并不是这篇文章的重点，这里也不做描述了。
2. 产品表现：方案管理及方案配置
做运营的痛点是：管理困难、成本高及上线周期长。
线上的列表视图只是最浅层的管理，我们还应该还应提供不同类型的视图帮助运营同学了解运营方案的运行状况和业务逻辑。
而成本、周期的问题，则应通过自助化、一站式、可视化的配置来解决，这个部分则依赖则是4-1的底层支持。
1）方案管理
方案管理，首先定义何为运营方案，它包含三部分：目标用户、运营策略、效果评估。
对方案的管理，常见的是列表视图，包含基础的列表及列表筛选。这一点就不描述了，而当我们要了解业务运行状况时就会使用到：执行视图、逻辑视图等。
① 执行视图
从运营的角度，任何的投放类的运营基本都涉及到KPI，先无论效果如何，每个运营策略要先关注执行是否按时、按量执行。这是运营效果的基础。
时间部分，主要分为开始时间、持续时间，部分的业务是对任务完成时效有强诉求的。
而量级部分首要的是任务的成功率，在产品设计时再往前做一步还可以基于对应方案的总量级、成功量级做同比或者做趋势，方便我们定位问题。
② 逻辑视图
逻辑视图，承载了运营方案的逻辑。其次想帮助运营同学建立运营的全局视角。
这一部分对于不同的产品形态、业务目标，其差异就很大了，下图举一个基于商品的逻辑视图。
商品视图是单一商品在不同的运营场景，在什么时间节点、使用了什么渠道进行运营。
每一个渠道都可能拥有自己的细分目标，点击“目标：引导加购”，则能够进入详细的运营方案，从而查看运营逻辑。第二幅图则是从品类的角度，来查看场景运营是否缺失，这个视图不关注渠道、时间等具体的细节。
这只是2个示例，大家可以基于自己的业务形态去设计自己的管理视图。
2）方案配置
上文的商品视图，只承载了逻辑的一部分，更详细的逻辑则会进入运营方案页面。它包含了运营方案的面向用户、运营策略、评估指标。
接下来为大家讲解的部分是，一个方案配置的表现层是怎样的。配置的方式，业界主要有2类，一类是流程视图，另一类是表单视图。
流程视图可以参考钉钉宜搭、易观数科，在这里只做简单的图片展示。
钉钉宜搭：
易观数科：
表单视图，也是比较主流的方式。个人的设计将运营方案拆分为了4个部分：运营频率、面向用户、运营策略、效果评估。这一小节，先阐述前3小点。
① 运营频率
一个运营方案，首先要处理的是在什么时间范围内运营，其次是以什么样的频率在什么时间运营。
事件触发则不依赖时间，基于事件发生实时触发，这一类型没有运营时间的概念。而循环触发、单次触发则会有时间的概念。
循环触发，是指多次的触发任务，触发事件仅适用于每日定时任务，间隔日定时任务。对间隔日定时任务举一个例子辅助理解：每周一都要上班。
单次触发，则是一次性的任务了，可以是方案建立后立即发送或者定一个创建方案完毕后的时间进行发送。交互示意如下：
② 面向用户
这个部分，在讲解用户数据平台的表现层时是有详细介绍的，在这里只做交互示意。
③ 运营策略
上图是一个简单的模式，能够服务大多数的场景。但在实际的过程中还是会涉及到判断、执行条件的组合。
复杂的模式，会在上图额外增加运营规则字段，规则由研发可视化托拉拽配置而成，然后规则再渲染执行相关的渠道、内容提供运营填写。
但规则多了，也就难以维护和理解。除了流程视图，怎么样做能够更易用、更易懂，我目前也没有很好的答案。
灵活和通用，真的没那么容易做取舍。
五、用户运营平台：看效果
终于到了主流程的最后一个部分：看效果。
回顾一下看效果的痛点：评估标准不一，无法对比，并且缺乏负向评估。
这一部分从个人的角度主要是需求方，而非实现方，所以没有太多的底层实现可以分享，而表现层则是基于运营方案的执行结果，对干预成功的用户进行漏斗统计、ROI计算，以及下钻的画像分析。
这里主要描述漏斗统计和ROI计算的一些思考：
1. 漏斗统计
漏斗的统计主要看端到端的转化，指标的定义如下：
- 目标用户总数：用户圈选组合后的用户总数；
- 干预成功用户数：经过防骚扰屏蔽、红黑名单或运营策略等判断条件过滤后下发成功数量；
- 点击人数：下发用户后，用户进入落地页的人数；
- 转化人数：点击用户实际完成转化目标的数量。
转化人数的概念非常的广，取决于你希望这个用户完成的行为指标。这个指标每个运营方案都可能不太相同，包括成交、续费、访问、关注等。
如果你不是数据产品关注的核心应该是梳理不同业务的转化指标，并交付数据部门实现统计再集成进你的平台。
2. ROI统计
ROI统计这是一个比较难设计的模块，在这里可能也只是抛砖引玉。
之所以说难，难在不同的业务指标不相同，统计的方式也不同，如果强行输出，可能得不到大家的认可。
这里个人的思路是分业务计算，抓小局放弃大局。理解梳理不同业务的计算方式，并为其提供通用的配置计算能力。帮助不同部门的内部能够比较，能够衡量。
ROI的计算公式，相比传统的计算方法额外多了一个参数：“负向指标经济价值”。
道理也很简单，每发一篇公众号文章，有人关注也会有人取关，有正向也当然会有负向。但这并不是说不需要继续运营了，而是要让分子大于0，并且尽可能地靠近、超出分母。
以上图的第二个例子进行解读，假设是某东Plus会员年卡，临近过期用户仍未进行续费，这时平台运营会将这部分用户推送至外呼专席，由外呼同学引导用户进行续费。
过程指标体现了结果指标的完成方式，要提升结果指标的经济价值，要么减少完成过程的损耗，要么提升完成结果的单价。
而负向指标，即这种运营行为可能导致的损失，这是这个运营举措带来的负向影响，如第一个例子中的取消关注。
负向指标同样需要换算为经济价值，如：1个公众号粉丝的费用，1个小程序UV的费用。正负向的结合，才能使计算更为客观。
六、写在最后
这篇文章，写的很艰难也很畅快。艰难是我从未想过我最熟悉的B端产品，沉下来写会多了这么多的产品方向。畅快则是终于我不用管那该死的边界、价值、实现难度，能够设计理想中应该包含的东西，应该呈现的交互样式。
完整的用户运营平台非常复杂、成本也很高，它要求你的业务是强依赖于召回，并具备足够大的业务量级与收益。否则，我还是建议从这里去汲取灵感，自己做自己的MVP。
思维可以更开阔一些，有了用户数据平台，基于特征做拖拉拽的BI报表也可以，画像分析也可以。有了规则引擎解决审批流配置、调研问卷的问题也不错。做了渠道能力，为外呼团队、客服团队提供支持也是很好的路径。
其实能设计这样一个产品真的运气挺好的，它把我过往的产品经验进行了连接。在第二份工作的时候，我做的B端产品非常多，包括：页面配置、任务、奖品、用户特征等等，但它们的连接都非常的疏离。
这一次才有点点所谓生态的感觉了，而不是假大空的一个名词。
最后呢，还想要建议B端产品在设计时尽可能的屏蔽底层逻辑，减少配置项。这么多的可视化、自助化配置，确实减少了研发的成本，但只是转换成了是产品和运营在负重前行。
回到C端也快3个月了，写一篇B端产品的毕业论文，还还2个月不更的债。
非常感谢你看到这里，谢谢宁。
#作者#
WISE，微信公众号：Becomewiser。腾讯产品经理，专注于精细化运营、用户数据体系建设等领域。
本文
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
