跟朋友讨论内容中台，也想了解大家的看法。关于内容中台的几个问题：

1. 内容中台成立的条件是什么？

2. 衡量业务具备做内容中台的标准有哪些？

3. 什么情况下不应当做内容中台？什么情况注定失败？

4. 以当前的态势，你认为内容中台还有存在的必要性吗，为什么？

欢迎以经验或举例说明。我的直观感受是很多内容中台建得很辛苦，但并没有充分发挥价值与用处。

mark一下，有空回1

1、内容中台成立条件为：有多个前台业务需要内容支撑，如果给每个前台配套对应的后台和人员，会造成大量的资源浪费和重复造轮子的开发。

2、衡量业务具备做内容中台的标准：单个业务不足以支撑一个内容中台，起码需要三或者三个以上前台业务，且对内容供给有较大的需求，内容可以帮助业务带来较大的价值。

3、什么情况下不应当做内容中台：需求内容的前台业务过少，单独成立中台反而不如直接放到前台，毕竟最熟悉产品的肯定是前台而不是中台。中台是典型的以效果换效率，降低效果，提高效率，只不过在大多数的业务中，内容是否优质带来的收益远小于中台带来的效率提升。

4、内容中台是否有存在的必要：如上所述，内容中台本质上是一个降低效果提高效率的工具，受边际效应影响极重，理论上对接的业务越多，对应的收益越大。

比如腾讯游戏的内容中台，直接对接IEG的所有游戏，如果让每个业务自己做一个内容库，前台业务去邀约内容、审核内容，虽然内容质量会更高，但相当于每个团队都要重复造一遍轮子，不仅要单独的运营人员还要单独的预算。这部分浪费的成本多到夸张。

所以哪怕内容中台给的质量没有那么高、对前台诉求的理解也不够深入，但对比前台自建内容平台的成本还是要划算的多。

对于法王所说的感觉没有发挥价值，可能是因为前台的业务不是很多，甚至可能只有一个；或者仅是从前台视角而没有从公司视角去看（毕竟从前台视角来看，放中台的效果肯定不如放前台好。）内容中台对内容的理解和诉求不如前台，效率上不仅没有提升、成本也没办法均摊，导致成本比在前台搭建内容平台还要高的多。

那就非常不划算。

锤哥说的很完整啦，我补几个视角：

先说一下我理解的内容中台的工作范围：内容的生产、内容标签、内容审核

然后回答问题

1、一个或者多个前台业务已具备商业化能力；前台业务的内容形态差异不大；

2、第一反应有点没看懂，我按我理解的说了：

①已有内容中台，前台业务需要介入，此时判断接入的标准有哪些：中台已有的内容在新的业务中是否具备可复用场景；中台的内容供应商、MCN、创作者是否具备显著可接入新业务的特征

②没有内容中台但有一个或者多个前台业务（不包括是否统一的内容形态），此时判断要不要做内容中台：内容形态是否趋近，消费场景是否相似，内容供应链是否趋同（简单来说就是越类似越好找共性越方便建立中台）

3、与2-②相悖的情况，基本大概率失败

4、国内来看的话，取决于内容在公司内的定位。比如五大社媒是不太可能存在内容中台的，他们的核心业务只有内容一个，更合理的方式是维系创作者及做好内容分发（商业化除外）；如果只是为了填充公司内各个业务线上勉强需要内容的场景，那中台就有必要性了。

关于内容中台的话，我的理解比较广义，管理业务所需内容的中台，我都称之为中台，而这个业务可能是游戏平台、图文视频内容平台、电商等等。这里讨论的话则定义为图文视频内容平台。

接着一起讨论一下中台和后台的区别。假设现在我有一个游戏内容的门户网站，需要对门户网站里各个模块、门户网站的APP应用里各个模块的内容进行列表排序、重点推荐内容的管理，此时提供直接管理的功能平台我称之为后台。后台就是广义上直接对前台提供数据并管理的平台。

而中台则是为后台提供数据的平台。例如后台需要一些诸如内容标签、内容分类的数据，常规的方式是直接在后台里管理这些数据。如果所涉及的业务里也有其他地方使用这些数据，且不想重复管理这些数据，此时就可以设计一个叫做内容标签、分类的中台为后台提供这些数据管理，避免重复造轮子。这就是中台的一个应用。

从我的例子里可以看出来，中台是介于前台（游戏门户网站）与内容管理后台中间的一个平台，核心在于提供一些统一的、常用的、公用的数据。

再换个例子。如果我是一个运营多款游戏的游戏运营商，需要对用户标签、用户渠道来源以及用户时长等用户数据进行管理，每款游戏虽然玩法不同，但是对于运营所需的用户属性、分类、标签都是公用的，此时为游戏提供运营后台时，这些常用的、统一的数据是不需要为每款游戏都配套一个这样的后台。可以讲其抽象为一类统一数据，供各个游戏运营后台调用。

以上的两个例子，就是我个人工作中遇到的情况。实际上两个例子中，我提供的都是直接的后台，而非中台。那么现在结合例子来讨论一下主题里的问题。

1. 内容中台成立的条件是什么？

成立的条件必须是有多款且数据量足够庞大、共用性高的数据较多的情况下，方才可以考虑内容中台。

再举个例子，曾经我负责微信小游戏生态的游戏平台，限于微信政策当时的小程序只能跳转10个游戏，为了做分发，我们做了20个功能一样的小游戏盒子。此时我就可以提供一个游戏中台，对20个平台的游戏进行统一管理。否则每个平台对应一个游戏管理后台，那效率就非常低了。

2. 衡量业务具备做中台的标准有哪些？

这个问题其实在前一点中已有说明，需要有一定数量的产品共同使用一类统一的数据，同时这类统一的数据量要足够多。

比如曾经我们做游戏门户网站，同公司内另外一个部门也有一个门户网站，但是我们在内容的标签体系上相似性低，此时就无法通过中台来统一管理，还不如各自搭建一套内容标签系统，避免因为搭建了中台，各自需求又不一致，双方都依赖中台的数据时还会有争抢开发资源的情况发生。

3. 什么情况下不应当做内容中台？什么情况注定失败？

我觉得第一个判断标准就是当前产品的用户量，如果用户量不够大，你甚至都不需要靠中台来管理数据，就一个独立的内容管理后台足够满足需求；

其次是需求性不高的数据。例如我曾经为游戏平台接入的各个游戏提供数据后台，当时的游戏多以休闲为主，偶而会接一些RPG。此时RPG游戏运营希望我们提供一个可以分析创角的数据中台，便于之后同类游戏接入。然而以休闲为主为主的我们专门为这个特点开发数据中台，并开发相应指标未必合算。所以当时的解决方案是仅为这款游戏单独开发一个数据后台，其他的通用数据数据还是靠数据中台来统计的。

最后则是共用、通用的数据类型不足。例如前文说到曾经我同公司内两个团队分别做游戏门户网站，但是我们各自的内容标签、分类推荐模型不相同，如果强行的用中台来实现这些看似相通的数据，实际上也还是各自提各自的需求，同时又因为中台对接两个开发团队，无法专精于一方，反倒不如各自自己做后台来管理。

那什么情况下注定失败呢？

只要用户量还没大到需要其他数据来支持，此时开发中台就注定失败。例如我负责的游戏门户网站每天也就几千几万的浏览量，此时就准备什么分类标签之类的中台，价值低还没用，注定是浪费资源的。

所以总结下来，中台靠的足够大的用户规模、足够广的数据需求场景。

4. 以当前的态势，你认为内容中台还有存在的必要性吗，为什么？

这个不好绝对的说需要存在或者不需要存在。曾经第一家公司做手游平台的时候，靠的就是前一款产品的游戏库快速搭建平台内容的，然而碍于内部竞争，最后游戏库没能做成中台，不得不说是一种损失。甚至早期两款产品都是手游平台，使用了一套账号系统，用户数据相通，也是我们当时产品能够快速投放的前提之一。此时的内容中台不仅需要存在，甚至如果从战略层面为了提升效率，需要完善好相应的内容中台。

而后来的公司就只有一个小程序，所有数据都对这一款产品服务，也就没有所谓的中台存在的必要性了。

所以说还是得看具体的业务规模与实际面对的业务场景来谈。