（一～三）部分为中台产品方法，（四）部分为中台搭建实战和增长应用案例。
一、中台产品需要产品经理吗
回答是肯定的。
1.是产品也是用户
中台产品的构想，完全是由于作为一个C端产品经理的自己出发。深深被日常的“提数，配单，打包，数据回收”往返于各种平台的重复工作困扰。自身需求的需要，可以说是搭建运营中台的一个原始起点。
2.多角色需求验伪
类似用户调研，但是调研对象主要是产品运营角色。
1）全角色访谈
2）真正去理解业务
运营中台是否要提供一个接入其他后台数据源的能力？
而当能力上线后，实际上有14%的业务都使用了接入数据源能力！
3）拉上架构师一起访谈
惊叹于开发的沟通能力的同时，发现拉开发一起去访谈，除了提升参与感和使命感，也能从中长期帮助他们构思中台方案。
1）成为竞品的会员
另一方面会员在体验demo上也会非常方便。
2）参与行业产品的会议
在参加行业头部的某saas方案提供商的会议沟通中，了解到对方的通道sdk覆盖量级以及每日的通道触达比例，能大致对标自身产品在行业中的能力位置，方便为产品将来tob做能力定位。不是面对面谈，是很难获取这些数据的。
3）了解对方商业模式
行业产品与腾讯内解决方案最大差别，其实就在于商业模式。商业模式决定了各自的节奏。行业面向头部客户提供1V1定制方案，中腰部客户以接入现有通用方案为主。
在腾讯内实际运营方案的需求上可以更多一线经验验证，也可以反向推动能力迭代。换句话说，我们与客户之间几乎没有gap。
4.找到推动业务接入的支点
别以为内部中台推广是没有阻力的。旧平台旧方案虽然痛，但业务的惯性是很强的，克服惯性的动力从哪来？
1）mvp-打造标杆
挑选新业务线来接入，既不存在重新开发之痛，新方案也方便和旧方案做对比。
例如在手管产品完全接入之初，就选用了未接入过push的体检业务，从头开始，也打响了第一战。
2）了解接入方的核心诉求
当推动同步助手接入的时候，对方的核心诉求是提升主动，通过手管在提主动的数据效果，和实际对同步助手的可提升空间分析，帮助团队一锤定音，敲掉接入上的不确定性。
3）纳入业务自己的流程中
新业务在开发的时候往往还不会考虑到业务的运营场景，但是实际上开发的时候完全可以把push，弹窗的触发和上报做完。
例如省电业务在第一期开发的时候就直接把开始充电和电量变化的触发和上报一起做了，做到了业务和业务push等运营场景一起上线，一上线就吃到运营场景的数据红利，扶持新业务渡过”初创期“。
4）用业务数据来做新特性宣讲
产品往往会听说“**业务最近数据涨的很好”先准备学一波经验，这个时候带业务案例和数据的宣讲起到的就是这个作用。
二、中台产品经理和中台架构师的分工是什么
说了上面的这么多，其实已经回答了中台产品在产品通用素质上的工作。
那在中台设计的专业维度上，中台产品经理和中台架构师的分工是什么？
1.产品经理主外
——类似工业设计师，负责外观设计，交互界面设计。
需要理解业务逻辑，产品设计逻辑，同时还要了解中台涉及到的技术原理。
和交互设计师一起完成中台操作层设计。
2.架构师主内
——类似机械设计师，负责机械结构设计。
需要非常扎实的技术原理知识体系。
和终端以及其他后台角色沟通完成中台架构设计。
三、产品角度的中台设计1.中台的使命
打个比方来说：中台就像是一家大餐厅，顾客会有自己的口味爱好，我们的目标就是让顾客吃到最喜爱的菜品，让顾客成为我们的忠实顾客。
2.中台模块组织
要实现上面的输送效果，中台需要包含6个模块：
四、中台产品搭建实战1.业务
业务是中台管理的基础维度，那业务怎么理解？
我们把功能按照相对独立的模块，可以一定程度在模块内完成一个需求的自闭环，这样的模块可以拆成一个业务。
手机管家业务可以这样划分：垃圾清理，应用安全，病毒检测，这三个业务（不枚举每个业务）。
为什么业务是基础维度？其实这里踩过一些坑。行业产品都是以场景作为基础维度，极光也是这么设计的。
当场景越来越多发现，每个场景业务都要接入一遍！可怕的重复造轮子竟然出现在中台产品上！
其实业务在各个场景上是可以复用的！定义好业务在不同场景通用属性，定义好业务在不同场景的不同属性。就可以把通用场景属性直接复用到多场景。
2.业务上报
业务上报可以告诉中台用户喜欢、不喜欢的业务是什么，以及最近消费业务的频次等。
业务上报主流解决方案有三类-个性化上报、业务通用上报、无埋点上报。
1）业务个性化上报
个性化上报，主要是分业务的需求差异比较大，强依赖业务本身完成上报。
2）业务通用上报（后文rfm模型的基础依据）
业务之间基本需求一致，记录用户使用该业务的频率frequency、间隔recency、和正负反馈monetary；这里由中台来记录用户对于某个业务rfm的数据。
不同业务的单位不一样，例如垃圾清理的间隔频率较高单位用小时，病毒检测频率较低单位用天。
3）业务上报的使用案例-新增用户激活
3.三种用户分类
主要根据新增用户的业务个性化上报和通用上报和信息将新增用户分为：
A.有上报新增渠道号的用户；
B.没有上报新增渠道号但使用过手管的用户；
C.没有上报新增渠道号也没有使用过手管。
1）有上报新增渠道号的——渠道号信息激活
案例：用户在应用市场搜索“号码鉴定”搜到了手机管家，这个时候顺手下载了手管。用户就带有了来自**应用用市场-号码鉴定渠道的这样一个渠道。
中台承接方案：此时中台上已经配置好了各种渠道号的对应激活内容弹窗。用户一打开手机管家成功通信后拉取到了对应弹窗，就会弹出引导用户使用。
2）没有上报新增渠道号但使用过手管某个功能——功能行为激活
案例：用户在安装一周内使用过手管的“帐号风险监测”功能，而后就不再使用手管。
中台承接方案：一旦行为数据匹配到中台已经配置的外部引导内容，即对用户下发。形式按照优先级-外部push>通知栏消息>桌面图标（综合转化率与用户体验排序）。
3）没有新增渠道号也没有使用过手管——冷启动
案例：用户没有渠道信息，且安装后也没有使用过手管，或者手管下发的激活内容不感兴趣。这个时候就将使用极光的冷启动方案。
中台承接方案：按照手管历史转化行为排序，剔除掉用户不感兴趣的功能，对用户进行触达和转化。
4）最终效果
4.任务
有了前两步的业务+业务上报，只需要补齐一些配置即可生成任务。
1）任务配置
通过提炼运营操作场景，原来需要在打包平台（素材打包）、云推平台（配单）、提数平台（用户画像提取）的多分支流程合入到同一个一站式平台上。
2）任务组（abtest）
这里着重介绍abtest的设计方案：
极光对于流量的处理方式也有两种：
实际使用示意图：
5.下发通道
下发通道，就像厨房做菜，通常来说我们有两种选择：自己的厨房来做菜——app自身通道，或者自己做不过来，别人做的更快更好，那我们也可以去采购别人做好的菜——拓展通道。
不同通道的账号体系不一样，用账号地图来匹配拓展通道的用户，确保触达的正确性。
1）极光集成扩展通道
①集成通道方案
极光sdk集成了多个扩展通道能力，同时还可以持续通过代理服务与接口对接的方式与其他通道sdk数据进行对接，动态扩展通道触达能力。
②集成通道的使用
通常在使用扩展通道的目的都是唯一触达（相对应的是重复触达，重复触达容易增加卸载风险）。
极光设计了对于通道进行优先级控制，按照优先级层级对通道进行触达指定，一旦在某一层完成了触达，任务即停止，不再触达下面的通道。
③扩展通道效果
通过扩展通道，对不存活的用户触达（消息送达）达到45%以上渗透（渗透取决于各通道能力&接入扩展通道数量）。
2）账号图谱
由于扩展通道涉及通道较多，不同通道识别用户的id不一样，而极光需要一张统一的账号图谱来覆盖多个通道的用户id。
①用户唯一账号user-id
通过集成多个通道用户id信息的统一userid，作为一个复合型代表一个人在多个通道唯一性身份的id，这个uid的依据就来自下面的设备vid和社交aid。就像我们的身份证可以对应驾照对应护照对应港澳通行证的一对多关系。
②设备账号vid
通常有guid，imei，oaid和idfa。完成对于联盟、手机厂商到消息推送的用户定位。
③社交账号account-id
6.优先级模型
优先级确定有三层：
1）rfm自动模型
通过上面“2业务上报“部分获得的用户上报信息，业务的频率frequency、间隔recency、和正负反馈monetary，进行单一变量实验。
确定业务优先级与用户行为对关系：
间隔recency——拆分为三个触达窗口期：冷却期，联络期，挽回期
业务使用间隔越短的冷却期应减少打扰；间隔适中期间，保持联络；挽回期增加联络。
频率frequency——与忠诚度成正比，达拆分为忠诚&普通用户
业务忠诚度高的用户减少打扰，业务普通用户尝试其他功能触。
活跃天数monetary——不通业务偏好的用户对于主动活跃天数有明显差异，拆分为三个梯队：高频、中频、低频
高频业务优先推荐，中频业务其次，低频最低。
通过上面的实验数据，通过忠诚度和触达窗口可以划分为6种用户聚类：
每种聚类提供相对应的用户自身偏好功能，保留符合命中区域策略内的任务，剔除未命中任务进行下发。
2）转化率奖惩模型
有了上面5.1的rfm模型之后，自动化的优先级达到最佳转化的目的就有了底层的实现。
①为什么要做转化率奖惩
这时出现了一个新问题。就是高转化业务永远获得更高流量，低转化业务永远垫底。对于业务侧无法通过“自身努力”调整业务获得明显的逆袭。对用用户侧感知也会经常收到相似的推送。
长此以往，业务间的流量变成“一潭死水“。
②如何做奖惩
简单的说“点击率提高强奖励，点击率下降弱惩罚”，曝光-点击这一层是业务自身最容易通过abtest去优化的一层，我们用点击率作为指标，帮助努力的业务逆袭。
计算规则如下：
③自动化流量分配效果如何
流量被盘活-原来头部效应明显的业务，变得有起有落，业务有动力主动优化。
3）业务人工干预
人工对于业务进行优先级按照比例排序，这一层优先级高于上面两层自动化模型。
4）全局风控
出于用户体验，和合规风险。务必进行全局维度风控，这样各个业务不需要关心和其他业务的冲突，中台会从全局去控制体验。
5）优先级控制效果
①曝光转化率提升
通过提高了触达对准确性，最终提升了运营内容从曝光到点击的转化。
以手机管家为例，接入极光前运营场景的点击率均值5.16%接入后提升到10.03%提升将近一倍。
②负反馈收敛
解决了原来业务各自开发各自触达，一发版本就有很多新业务涌向用户对负反馈问题。
同时在应对合规和一些特殊节点的运营内容控制要求上，也非常灵活。即配即生效，不需要等版本和开发。
6）业务场景
不通的业务场景的样式有差别，能力支撑上也有差异。
①单一场景
顾名思义，任务只投放到一个场景，例如只投放push或者只投放banner位置。不同业务的性质不一样，决定了对应运营素材的样式不一样。例如垃圾清理偏向工具样式，病毒查杀偏警告样式。
②串联场景
③串联场景逻辑
简单的说，就是根据用户在第一个场景的决策，出对应的第二个场景，甚至第三个场景。在串联的场景中帮助用户完成转化。
任务串联能力目前在业界也较前沿（对于中台和客户端的交互要求较高，也更适用于强运营诉求的场景）。
④串联场景案例
手机管家在与国家反诈合作“最新诈骗案例”普及时——通过替换“诈骗高风险人群画像”图标>该人群通过点击“识破新诈骗”图标>进入手机管家>推送相应诈骗案例消息，实现人群科普。
⑤分场景触达效果
通过整合外部触达场景，可以将业务的曝光触达率达到83%。
五、后记
在腾讯内部其实可能也有非常多的C端产品有过这样的十字路口，要不要自己搭一个运营中台。
全文主要说一些我们自己搭建的优势和挑战，帮助大家加强信心，做一个转型必要性的判断。
至此，包含中台产品通用能力，产品搭建实战，通道能力应用案例基本讲完了。
由于篇幅有限，许多细节未能深入（每个深入可能又是一章单独长篇大论）也欢迎大家留言一起探讨运营平台的建设经验！
作者：swanshi，腾讯CSIG高级产品
本文由@腾讯大讲堂原创发布于人人都是产品经理，未经许可，禁止转载。