腾讯一站式运营中台打造技术设计实现（亿级月活产品运营）

在腾讯公司内部有非常多以技术架构为主的精彩的中台的搭建经验分享。那么中台产品需要产品经理吗？如果需要的话，他和架构师的分工是什么？中台产品经理到底做什么？笔者以中台产品经理的视角，以“极光运营中台”的经验为基础，谈谈构建一站式运营平台的产品方法思考。（极光目前服务CSIG的6条产品线-腾讯手机管家、QQ同步助手、腾讯相册管家、腾讯wifi管家、QQ安全中心、换机助手，覆盖亿级月活产品的运营中台）

（一～三）部分为中台产品方法、（四）部分为中台搭建实战和增长应用案例。

一、中台产品需要产品经理吗？

回答是肯定的。

中台产品和C端产品一样有很多产品的通用素质，着重分享与C有区分的产品工作。

1、是产品也是用户：

中台产品的构想，完全是由于作为一个C端产品经理的自己出发。深深被日常的“提数，配单，打包，数据回收”往返于各种平台的重复工作困扰。自身需求的需要，可以说是搭建运营中台的一个原始起点。

2、多角色需求验伪：

类似用户调研，但是调研对象主要是产品运营角色。

全角色访谈

刚开始访谈是完全围绕产品和运营角色。随着着访谈深入，发现运营需要依赖很多其他角色（测试，数据运维，开发开发）于是将利益相关者都补充到调研中-测试、数据运维、终端开发、设计师，覆盖运营中台真正要解决的全部问题。

真正去理解业务

• 相比C端调研，中台需求调研用户量不大，全部采用定性研究-访谈形式。
• 在访谈脚本上，优先他们最熟悉也最关心的自身业务开始，非常容易挖掘到痛点。而非一来就是“你想要一个什么样的运营中台？”
• 还有一个重要原因，业务的需求千差万别，但是中台不可能面面俱到，但需要提供一套统一的方案尽可能预见和包含大部分共性场景。通过不同业务的叙述，非常容易提炼到共性需求是什么？
• 面对小众的需求，可以再向其他角色验证这个需求从中长期来看的真伪。

例如：在对“应用安全”的产品webber访谈时，发现他们有自己的一套后台来输送“有QQ和微信账号风险“的用户。

运营中台是否要提供一个接入其他后台数据源的能力？

调研中发现有较多业务涉及到其他的数据来源后台，这个需求有一定共性，只是其他产品需求暂时不迫切。

而当能力上线后，实际上有14%的业务都使用了接入数据源能力！

拉上架构师一起访谈

惊叹于开发的沟通能力的同时，发现拉开发一起去访谈，除了提升参与感和使命感，也能从中长期帮助他们构思中台方案。

3、持续关注行业：

行业能力分析，在后文“平台搭建”部分会有详述。这里谈一些关注行业的“野路子”

成为竞品的会员

成了神策的订阅会员后，他们的客户经理会把最新行业方案会通过微信客服发给我。

另一方面会员在体验demo上也会非常方便。

参与行业产品的会议

在参加行业头部的某saas方案提供商的会议沟通中，了解到对方的通道sdk覆盖量级以及每日的通道触达比例，能大致对标自身产品在行业中的能力位置，方便为产品将来to b做能力定位。不是面对面谈，是很难获取这些数据的。

了解对方商业模式

行业产品与腾讯内解决方案最大差别，其实就在于商业模式。商业模式决定了各自的节奏。行业面向头部客户提供1V1定制方案，中腰部客户以接入现有通用方案为主。

在腾讯内实际运营方案的需求上可以更多一线经验验证，也可以反向推动能力迭代。换句话说，我们与客户之间几乎没有gap。

4、找到推动业务接入的支点：

别以为内部中台推广是没有阻力的。旧平台旧方案虽然痛，但业务的惯性是很强的，克服惯性的动力从哪来？

mvp-打造标杆：

挑选新业务线来接入，既不存在重新开发之痛，新方案也方便和旧方案做对比。

例如在手管产品完全接入之初，就选用了未接入过push的体检业务，从头开始，也打响了第一战。

了解接入方的核心诉求

当推动同步助手接入的时候，对方的核心诉求是提升主动，通过手管在提主动的数据效果，和实际对同步助手的可提升空间分析，帮助团队一锤定音，敲掉接入上的不确定性。

纳入业务自己的流程中：

新业务在开发的时候往往还不会考虑到业务的运营场景，但是实际上开发的时候完全可以把push，弹窗的触发和上报做完。

例如省电业务在第一期开发的时候就直接把开始充电和电量变化的触发和上报一起做了，做到了业务和业务push等运营场景一起上线，一上线就吃到运营场景的数据红利，扶持新业务渡过”初创期“。

用业务数据来做新特性宣讲：

产品往往会听说“**业务最近数据涨的很好”先准备学一波经验，这个时候带业务案例和数据的宣讲起到的就是这个作用。

二、中台产品经理和中台架构师的分工是什么？

说了上面的这么多，其实已经回答了中台产品在产品通用素质上的工作。

那在中台设计的专业维度上，中台产品经理和中台架构师的分工是什么？

产品经理主外

——类似工业设计师，负责外观设计，交互界面设计。

需要理解业务逻辑，产品设计逻辑，同时还要了解中台涉及到的技术原理。

和交互设计师一起完成中台操作层设计。

架构师主内

——类似机械设计师，负责机械结构设计。

需要非常扎实的技术原理知识体系。

和终端以及其他后台角色沟通完成中台架构设计。

三、产品角度的中台设计

1、中台的使命

用业务角度来说：

就是把适合的内容在合适的时间合适的场景传递到适合的人手上

打个比方来说：

中台就像是一家大餐厅，顾客会有自己的口味爱好，我们的目标就是让顾客吃到最喜爱的菜品，让顾客成为我们的忠实顾客。

2、中台模块组织

要实现上面的输送效果，中台需要包含6个模块：

1、业务-食材

2、业务上报-用户口味

3、任务-菜单

4、下发通道-厨房

5、优先级模型-上菜次序

6、业务场景-就餐场合

四、中台产品搭建实战

1、业务

业务是中台管理的基础维度

那到底业务怎么理解？

我们把功能按照相对独立的模块，可以一定程度在模块内完成一个需求的自闭环，这样的模块可以拆成一个业务。

手机管家业务可以这样划分：垃圾清理，应用安全，病毒检测，这三个业务（不枚举每个业务）

为什么业务是基础维度？其实这里踩过一些坑

行业产品都是以场景作为基础维度，极光也是这么设计的。

当场景越来越多发现，每个场景业务都要接入一遍！可怕的重复造轮子竟然出现在中台产品上！

其实业务在各个场景上是可以复用的！定义好业务在不同场景通用属性，定义好业务在不同场景的不同属性。就可以把通用场景属性直接复

用到多场景。

那为什么行业竞品反而要以场景作为维度呢？当把极光售卖给中石化时就理解了这种出发点，很多b端产品只会接入一个场景，他们可能是只需要push或者只需要微信通知，因此单一场景的接入更容易满足他们的需求！

2、业务上报

业务上报可以告诉中台用户喜欢、不喜欢的业务是什么，以及最近消费业务的频次等。

业务上报主流解决方案有三类-个性化上报、业务通用上报、无埋点上报。

2.1业务个性化上报：

个性化上报，主要是分业务的需求差异比较大，强依赖业务本身完成上报。

例如垃圾清理关注用户手机有多少垃圾，病毒检测也关注本地有没有可以软件安装包。一个业务关注的多个指标可以综合来判断业务对于用户的价值，因此需要用业务来bound；

2.2业务通用上报（后文rfm模型的基础依据）：

业务之间基本需求一致，记录用户使用该业务的频率frequency、间隔recency、和正负反馈monetary；这里由中台来记录用户对于某个业务rfm的数据。

不同业务的单位不一样，例如垃圾清理的间隔频率较高单位用小时，病毒检测频率较低单位用天。

2.3业务上报的使用案例-新增用户激活

三种用户分类：

主要根据新增用户的业务个性化上报和通用上报和信息将新增用户分为：

A.有上报新增渠道号的B.没有上报新增渠道号但使用过手管的用户C.没有上报新增渠道号也没有使用过手管

A.有上报新增渠道号的——渠道号信息激活

案例：用户在应用市场搜索“号码鉴定”搜到了手机管家，这个时候顺手下载了手管。用户就带有了来自**应用用市场-号码鉴定渠道的这样一个渠道。

中台承接方案：此时中台上已经配置好了各种渠道号的对应激活内容弹窗。用户一打开手机管家成功通信后拉取到了对应弹窗，就会弹出引导用户使用。

B.没有上报新增渠道号但使用过手管某个功能——功能行为激活

案例：用户在安装一周内使用过手管的“帐号风险监测”功能，而后就不再使用手管。

中台承接方案：一旦行为数据匹配到中台已经配置的外部引导内容，即对用户下发。形式按照优先级-外部push>通知栏消息>桌面图标（综合转化率与用户体验排序）

C.没有新增渠道号也没有使用过手管——冷启动

案例：用户没有渠道信息，且安装后也没有使用过手管，或者手管下发的激活内容不感兴趣。这个时候就将使用极光的冷启动方案。

中台承接方案：按照手管历史转化行为排序，剔除掉用户不感兴趣的功能，对用户进行触达和转化。

最终效果：

3、任务

有了前两步的业务+业务上报，只需要补齐一些配置即可生成任务。

3.1任务配置：

通过提炼运营操作场景，原来需要在打包平台（素材打包）、云推平台（配单）、提数平台（用户画像提取）的多分支流程合入到同一个一站式平台上。

3.2任务组（abtest）

这里着重介绍abtest的设计方案：

极光对于流量的处理方式也有两种-

• 流量互斥，先选择流量分层，同一层的流量再分桶，同层不同桶流量之间互斥。
• 流量正交，不同层流量之间的多桶流量正交。确保实验的随机性也就是实验结果更可信。

最终对比实验组内的关注指标，可以只配置单层，也可以配置单桶，用于正式阶段的稳定投放。

更多流量实验模型可以参考笔者整理的（空对照组、PSM模型、RDD模型、非依从实验Trigger、MBA实验等详述）

腾讯文档实验模型评估

https://docs.qq.com/sheet/DZGRrZ01hVHpFaFJv

实际使用示意图：

4、下发通道

下发通道，就像厨房做菜，通常来说我们有两种选择：自己的厨房来做菜——app自身通道，或者自己做不过来，别人做的更快更好，那我们也可以去采购别人做好的菜——拓展通道。

不同通道的账号体系不一样，用账号地图来匹配拓展通道的用户，确保触达的正确性。

4.1极光集成扩展通道

4.1.1集成通道方案

极光sdk集成了多个扩展通道能力，同时还可以持续通过代理服务与接口对接的方式与其他通道sdk数据进行对接，动态扩展通道触达能力。

• 手机厂商推送服务QueryPushTunnelServer&AndriodManuPushServer-通过手机厂商自带的推送服务来下发消息；
• 微信小程序/服务号通知WeChatAccessServer-通过对接小程序/服务号后台下发消息；
• 短信代理服务MobileMessageServer-通过调用第三方短信服务来下发短信。

4.1.2集成通道的使用

通常在使用扩展通道的目的都是唯一触达（相对应的是重复触达，重复触达容易增加卸载风险）

极光设计了对于通道进行优先级控制，按照优先级层级对通道进行触达指定，一旦在某一层完成了触达，任务即停止，不再触达下面的通道。

4.1.3扩展通道效果

通过扩展通道，对不存活的用户触达（消息送达）达到45%以上渗透（渗透取决于各通道能力&接入扩展通道数量）

4.2账号图谱

由于扩展通道涉及通道较多，不同通道识别用户的id不一样，而极光需要一张统一的账号图谱来覆盖多个通道的用户id。

4.2.1用户唯一账号user-id：

通过集成多个通道用户id信息的统一user id，作为一个复合型代表一个人在多个通道唯一性身份的id，这个uid的依据就来自下面的设备vid和社交aid。就像我们的身份证可以对应驾照对应护照对应港澳通行证的一对多关系。

4.2.2设备账号vid：

通常有guid，imei，oaid和idfa。完成对于联盟、手机厂商到消息推送的用户定位。

4.2.3社交账号account-id：

例如微信和qq。完成对于小程序/服务号通知下发。甚至手机短信下发。

5、优先级模型

优先级确定有三层

5.1rfm自动模型：

通过上面“2⃣️业务上报“部分获得的用户上报信息，业务的频率frequency、间隔recency、和正负反馈monetary，进行单一变量实验。

确定业务优先级与用户行为对关系：

• 间隔recency——拆分为三个触达窗口期：冷却期，联络期，挽回期

业务使用间隔越短的冷却期应减少打扰；间隔适中期间，保持联络；挽回期增加联络。

• 频率frequency——与忠诚度成正比，达拆分为忠诚&普通用户

业务忠诚度高的用户减少打扰，业务普通用户尝试其他功能触

• 活跃天数monetary——不通业务偏好的用户对于主动活跃天数有明显差异，拆分为三个梯队：高频、中频、低频

高频业务优先推荐，中频业务其次，低频最低

通过上面的实验数据，通过忠诚度和触达窗口可以划分为6种用户聚类：忠诚活跃用户、普通活跃用户、忠诚用户、普通用户、忠诚预流失

用户、普通预流失用户。

每种聚类提供相对应的用户自身偏好功能，保留符合命中区域策略内的任务，剔除未命中任务进行下发。

5.2转化率奖惩模型：

有了上面5.1的rfm模型之后，自动化的优先级达到最佳转化的目的就有了底层的实现。

5.2.1为什么要做转化率奖惩？

这时出现了一个新问题。就是高转化业务永远获得更高流量，低转化业务永远垫底。对于业务侧无法通过“自身努力”调整业务获得明显的逆袭。对用用户侧感知也会经常收到相似的推送。

长此以往，业务间的流量变成“一潭死水“

5.2.2如何做奖惩？

简单的说“点击率提高强奖励，点击率下降弱惩罚”，曝光-点击这一层是业务自身最容易通过abtest去优化的一层，我们用点击率作为指标，帮助努力的业务逆袭

计算规则如下：

5.2.3自动化流量分配效果如何？

流量被盘活-原来头部效应明显的业务，变得有起有落，业务有动力主动优化

5.3业务人工干预：

人工对于业务进行优先级按照比例排序，这一层优先级高于上面两层自动化模型

5.4全局风控：

出于用户体验，和合规风险。务必进行全局维度风控，这样各个业务不需要关心和其他业务的冲突，中台会从全局去控制体验。

5.5优先级控制效果

5.5.1曝光转化率提升

通过提高了触达对准确性，最终提升了运营内容从曝光到点击的转化。

以手机管家为例，接入极光前运营场景的点击率均值5.16%接入后提升到10.03%提升将近一倍。

5.5.2负反馈收敛

解决了原来业务各自开发各自触达，一发版本就有很多新业务涌向用户对负反馈问题。

同时在应对合规和一些特殊节点的运营内容控制要求上，也非常灵活。即配即生效，不需要等版本和开发。

6、业务场景

不通的业务场景的样式有差别，能力支撑上也有差异。

6.1单一场景：

顾名思义，任务只投放到一个场景，例如只投放push或者只投放banner位置。不同业务的性质不一样，决定了对应运营素材的样式不一样。例如垃圾清理偏向工具样式，病毒查杀偏警告样式。

6.2串联场景：

6.2.1串联场景逻辑：

简单的说，就是根据用户在第一个场景的决策，出对应的第二个场景，甚至第三个场景。在串联的场景中帮助用户完成转化。

但是场景之间有冷却期，例如用户在场景一点击了负反馈，那么场景二会冷却一段时间后再曝光，也可以终止任务，或跳过场景二进入场景三。

任务串联能力目前在业界也较前沿（对于中台和客户端的交互要求较高，也更适用于强运营诉求的场景）

6.2.2串联场景案例：

手机管家在与国家反诈合作“最新诈骗案例”普及时

——通过替换“诈骗高风险人群画像”图标　>该人群通过点击“识破新诈骗”图标>进入手机管家>推送相应诈骗案例消息，实现人群科普。

6.3分场景触达效果

通过整合外部触达场景，可以将业务的曝光触达率达到83%

触达率=单一场景曝光uv/单一场景极光后台下发uv

*push弹窗触达率，主要受悬浮窗权限授权限制；

*通知栏触达率，主要受通知栏权限授权限制；

*桌面图标触达率，主要受到华为，oppo，vivo，小米四大厂商在手管机型中的占比限制

整合触达率=总和场景曝光uv/总总和场景后台下发uv

后记

写给C端产品转中台产品的建议

在腾讯内部其实可能也有非常多的C端产品有过这样的十字路口，要不要自己搭一个运营中台。

全文主要说一些我们自己搭建的优势和挑战，帮助大家加强信心，做一个转型必要性的判断。

至此，包含中台产品通用能力，产品搭建实战，通道能力应用案例基本讲完了。