2023年你眼中的游戏中台产品是什么样子

你眼中的游戏中台产品是什么样子？前言——产品的价值

在谈论嬉戏中台之前，我想先和大家聊聊产品的思索，由此去引申中台的思索。

无论自然界、人类社会，抑或浩瀚宇宙，一切事物从整体上都在向着无序化迈进，这就是熵增的过程。

随着信息化的快速进展以及疫情冲击下的“后遗症”，我们越来越能明显感觉到，当下社会好像很难根据既定的规章运转下去，熵增现象越来越明显，而当下的业务重心也渐渐的从经营产品偏移到经营用户。

过往许多行业甚至当下一部分传统行业的营销都是在经营产品，简洁来说就是怎样将产品宣扬出去，卖给若干个消费者。而经营用户将这款产品卖给这个客户后，可以让他重复购买若干次，与此同时还可以带动若干个客户，让这若干客户重复购买……以此类推。

期望值的公式=概率x结果/收益

所以，期望值的大小是由概率的大小和收益的大小二者共同打算的，所谓查找最大期望值也就是在概率和收益之间找到最佳的组合和平衡，并以最大期望值来指导我们的行动。显而易见经营产品的期望是远小于经营用户的期望值。

那么在现有经营产品的前提下，假如更好的去经营用户呢？之前有提到说，产品是依照于一套既定的规章下的产物，那在这套熟识的工作流之下，是否能够通过阅历的积淀，开发流程与接入流程的规范下去提升工作效率，以便更好地去经营用户呢？

本篇内容主要内容在于通过中台的概念去提升经营产品的角度，而非大篇幅的经营用户，或许会在将来的文章中去绽开讲讲，敬请期盼。再回到嬉戏中台来说，或许它的存在就是我们查找最佳平衡的解决方案。

一、嬉戏中台的思索

互联网中台的起源的故事与进展的历程想必大家早已经熟知，我也不再去引用于赘述。然而嬉戏行业的中台却很少提及，我想借着这个机会和大家一起探讨探讨，当然究竟只是我的一家之言，确定会有片面的地方还请谅解。

回到中台的核心内容：简而言之就是系统组件化，避开重复造轮子，提升开发的工作效率，降低或削减人工与时间的成本。这么看或许说辞有些模糊，其实中台的设计往往无法脱离业务，所以在概要定义下中台的边界是无法明确的。

俗话说风险与机遇并存，在中台概念火热的背后也存在着盲目跟风，很多本该不属于中台领域的东西被莫名的积累到中台范畴，从而导致中台失去了原有的核心价值。并不是全部的公司或者部门都需要“中台化”，中台化其实是由为“中心化”、“平台化”演化而来的。

随着企业规模的膨胀、业务简单度的提升等过程中不断暴露出来问题，以及对于各部门或者各项目组之间协作的要求就会越来越高，对于已经具有肯定的中心化趋势且存在多条业务线并行的状况下，工具、内容、协作等模块不断抽象出中心内容，但各模块又相互独立存在于各个平台，亟待一个中央模块去连接和组合，那么此时建设中台就很有必要性。

二、嬉戏中台的组成

一个中台部门的搭建不是想当然，除了需要自己强劲的“内功”底蕴之外，还要有八面玲珑的“外功”去搭建。由于中台的全部需求发起点都来源于项目组，以满意项目组需求去搭建组件与功能而非去虚空想象需求。

再加上中台项目往往不像项目那样会直接制造利益价值，所以在前期立项就会面临从里到外的重重阻力。当然这部分内容与各企业的战略规划相关，在项目管理中划分在启动过程组的阶段需要着重去分析考虑的事情，而本次内容更多针对于规划、执行过程阶段。

嬉戏中台体系是由技术中台+业务中台+数据中台等构成。其中业务中台又可以拆分为运营中台、内容中台和营销中台，当然每个企业对于中台的范畴或命名不尽相同，但万变不离其宗。

其中技术中台可以拆分为：引擎平台、工程平台、技术美术平台、AI平台等。

运营中台可以引申为：内容平台、营销平台、用户平台、工具资源平台（GM向）。

拿运营中台来说，采纳多租户模式，通过运营中台为不同的嬉戏项目作为单独的实例供应组织服务。实现多个租户之间共享中台组件，以达到提高复用效率削减开发时间与人力的目的。

三、如何建设嬉戏中台

1.权限管理模型选用

常见的有ACL访问掌握列表、DAC自主访问掌握（ACL拓展）、MAC强制访问掌握、RBAC基于角色的访问掌握，每种的优点、局限性等常规内容可自寻搜寻此处不再多赘述。我个人是采纳RBAC的模型进行运营中台的设计的：

定义：

规定角色可以对哪些资源进行哪些操作规定主体拥有哪些角色当一个操作同时满意a与b时，允许操作。

场景：运营后台管理系统适用资源：不同嬉戏项目组说明：RBAC的思想，来源于现实世界的企业结构。比如销售角色，拥有查看客户信息的权限。当一个销售人员小王入职了，可以把销售角色给予小王，那么小王就拥有了查看客户的权限。这种方式，避开了ACL模型下，每次新人入职，需要逐个配置资源表的状况。同样，权限变动也变得很便利，只要修改角色，即可实现多用户的权限修改。

局限性：RABC并不总能满意全部权限的场景。比如，我们无法对嬉戏运营角色，进行个体定制。比如，嬉戏运营角色拥有创建、删除的权限。假如我们要对运营人员小李，去掉删除的权限。那么，我们就必需创建另一个角色，来满意需求。假如这种状况很频繁，就会丢失角色的统一性，降低系统的可维护性。

2.运营中台

对于嬉戏运营中台来说肯定是多租户模式，不同的嬉戏项目组共用相同的系统或程序组件，并且仍可确保各用户间数据的隔离性。

针对不同嬉戏的业务方提出的嬉戏运营管理需求，通过建立将功能层面高内聚、低耦合的通用嬉戏运营管理系统，以供应业务多重用性、系统易维护性、功能高扩展性的解决方案。

同时为满意各个嬉戏项目组的应用管理需求，设计开发通用的嬉戏运营系统。基于通用的服务端接口级的功能响应，打通与其他服务之间的数据交互，供应支持多租户、自助接入、并具有自由拓展性的系统及服务。

3.营销中台

随着玩家数量的增长，用户、嬉戏内容等数据源急剧膨胀、维护玩家的生命周期变的困难、运营方案迭代缓慢等问题的显现，营销管理平台应运而生。基于对数据驱动业务增长以及精细化运营的迫切需求，需要延长玩家在嬉戏内、嬉戏外的生命周期：

关心运营快速猎取数据，实现敏捷高效的洞察，促进业务快速迭代关心运营分析行为和业务数据，快速提高业务转化与玩家留存关心运营管理用户生命周期，精细化运营及智能增长打通分析-决策-行动完整闭环营销平台定位为建立行为分析产品体系，整合多种运营策略和工具，打通增长、精细化运营闭环，目标降低产品分析、运营的时间人力成本，提升整体效率，丰富扩展产品增长和内容运营力量。

4.专题活动中台

专题活动中台算是非必选的一项架构，是否构建取决于业务对于此类需求的依靠程度，在嬉戏行业中较为多见。

要首先推断在以往的消费类/活跃类的嬉戏活动中是否可以抽象出通用的组件，或者是高频重复消失的活动场景。例如宫格抽奖、转盘等基础规章元素，周期性的特别节日等素材积累就具有很强的通用性和高复用性。

可以理解为简洁的换皮活动，这些都可以由业务属性来做敏捷的配置组合。而对于日常的广告图、盒子图、背景图或banner等可以积累为素材，虽然这些内容或许带有自身很强的定制属性，但作为素材的积淀还是可以考虑保留的。比犹如一个圣诞主题的活动背景，假如时间紧的话，换一些关键元素是不是也可以在另一些项目中使用呢。

（1）提高活动复用率和复用效率

让每一个上线过的活动都变成可复用的模版通过配置即可上线，无需额外开发（2）削减（避开）重复性规律、接口开发

（3）规范用户信息校验、发奖等通用规律，削减测试开发量

（4）做好与外部系统对接的预备

（5）专注页面效果与用户体验提升

四、对于中台产品的挑战

1.沟通协作挑战

其实我刚开头也是在业务部门，我所面对的业务需求都是较为明确直接和相对轻松的。虽然也是面对多方项目组，但没有中台概念以及不用考虑复用的思维，业务需求也是做的顺风顺水。直到经受业务量不断地膨胀之后，愈来愈多的问题暴露出来。

以对接需求为例，对于不同体量不同成熟度项目组的需求协作的意愿也是参差不齐的。体量大或者收益较高的团队由于他们的业务以及流程脉络较为清楚，一方面需要我们能够支持快速响应，在较短的时间快速迭代日常活动的上线，另一方面他们又不会主动考虑实现的简单度，不想由于我们的开发进度来干扰他们的排期进度，处于较难调和的沟通。

但也有类似不是很成熟的项目组找我们对需求时，对于需求的描述不是很精确     ，对于最终功能的表现也不是特殊关怀，甚至某些时候完全是我们替他们在想需求。所以其实在这过程中大量的精力会分散于不同部门之间的沟通协调，反复对同一个需求进行确认，整个结果确定的周期被无效拉长。

说话这门艺术，还是需要始终学习的。

2.规律抽象力量挑战

假如说沟通协作算作一个中台产品很重要软实力的体现，那么规律抽象力量就是一个考验硬性力量的体现了。

由于对于一个中台所要面对的一系列解决方案，都是能够服务于多业务多项目组的，那这这套解决方案的设计不仅需要强大的规律思索力量，更要有抽象延展力量，在满意全部的需求同时也能够敏锐的察觉到不同需求之间的公共特性，从而输出一个面对多租户的产品解决方案。

好比说项目组需要运营平台能够支持一个白名单功能，需要满意针对特定的人群执行特别规律。

这看起来是个很简洁的需求功能点，但是对于中台产品来说需要挖掘一切可以复用的场景，在满意业务需求的功能前提下，抽象出公共规律。很明显这个需求在后期运营中需要复用的场景还会有许多，比如延展到黑名单、活跃用户、大R等用户群体，那么我们就没必要重复造轮子，每次都去开发相同或类似的规律。

在实际的业务场景也会有更多更简单的事情需要解决，这个例子也是起抛砖引玉的作用。

在产品方法论文章中也有提到，有些需求其实是伪需求，还可以连续深挖。白名单功能去抽象拆解，实际就是筛选出一个用户群体，并对这个用户群体实现某种特定的功能。

这样来说的话这个需求就可以这样做：将原本一次性的白名单功能开发，实际转化为用户标签系统的开发。在基于运营平台原有的用户体系，加入用户标签功能，既能满意原有的白名单功能，又可以拓展一系列潜在的用户需求。

3.其他挑战

从整个产品层面来说，对于中台产品的综合力量要求还是很高的。

一方面，需要有强大的业务拆解力量与功能抽象的规律思维力量以及全局统筹的力量，清楚地梳理出业务中的关键路径与业务流，并且能够把控整体的系统迭代力量，在业务实现