【收藏】从零开始做运营（Episode 7）

Episode 7 内容运营面面观

好了，上次的内容，让很多运营同事出来大吐苦水，甚至有个实习生同学出来告诉我，2千条数据匹配的例子弱爆了，15万条数据匹配才是真苦逼有木有！另外@果仔也提到了看能不能聊聊消息推送的事情，我想想，那么就一起放在这一集里聊吧。

开篇前，必须先说明一下，内容运营的活儿，我已经多年没有做过了，所以，以下内容可能过时，可能有偏差，敬请包涵，如果其中有谬误，也欢迎指出，共同提高。

Chapter 1内容运营的初期事项

Step 1 内容供应链

内容供应链这个词是在上汽工作的时候，从IBM那边舶来的词汇。开始的时候，我始终想不明白，供应链关内容什么事儿，或者内容关供应链什么事儿，这俩是怎么凑到一块去的，后来仔细想想，发现这个词也不无道理。

事实上，不管是社区型网站/产品，还是交易型网站/产品，还是门户网站/产品，在建立初期，都会考虑几件事：

网站/产品上有哪些内容

这些内容从哪里来，由谁提供

这些内容要如何组织与呈现

这些内容如何做筛选，什么是好的内容

这些内容给谁看，达到什么样的目标

好了，你看，你有来源，有展现，有标准，有受众，有目标，确实类似供应链流转方式。

过去我们可能会说，内容建立初期的首要问题是解决内容从哪里来到哪里去的流程问题。而现在如果从我个人的角度再来看内容建设初期任务，可能会更进一步的变成：网站/产品提供的内容传达了网站/产品的价值观，因此在内容建设初期，除了确认流程问题之外，还要确立内容评价标准。

内容供应链虽然只是一个名词，但是我觉得至少在目前，它还是体现了进步的理念，即：

将你的内容视为你的商品，从初始阶段就定义这个商品的销售对象、选品和展示方式。进而确保上线后的后台内容流转与前台展示。

Step 2 内容初始化

内容初始化是另一个在内容运营初期要做的事情。

什么是内容初始化，对的，就是在你构建好的内容框架下，去填充一些内容，而这些内容是内容运营初期网站/产品上的核心部分。

对于社区型网站/产品来说，可能是假扮成用户或者定向邀请一些种子用户开始做一些内容填充，然后后来来的用户大致知道这个社区是什么样的社区，怎么玩；对于交易型的网站/产品来说，商品信息、图片展示就是内容初始化的重点；对于门户网站/产品来说，新闻、资讯就是内容初始化的重点，等等。

Chapter 2 持续运营

Step 1 内容引导与UGC构建

完成了初始化，就会走到正式运营阶段，内容运营的展开，离不开的是当用户进入之后，要如何引导用户去看到内容，如何让用户满意这些内容，如何促进用户建立UGC（社区型网站/产品的互动、回复、发表等；交易型网站/产品的成交、评论等；门户网站/产品的发言、评论、回复，等），如何筛选用户内容，如何阻挡垃圾信息，这些就是很重要的内容。

虽然我们一直说“自运营”是最高的境界，但是在这个境界之前，必须要做的引导，如果没有这一步，那是不可能实现健康有序的“自运营”的。

Step 2 内容推荐与整合

当网站/产品内容逐渐充实，内容运营人员的日常工作中最重要的就是：内容推荐——让优质内容露出及内容整合——让同属大类的优质内容集结。

这一点上，大家通过知乎的推荐、日报、出版可见一斑。

在这里我觉得可以多说一些，正好拿知乎的内容运营举个例子:

知乎的内容推荐机制有几个部分组成：

关注话题与关注对象的Timeline，这个我不截图了，大家都懂的。

话题动态推荐新近发生的有关关注话题的动态。

热门内容通过发现推荐（编辑推荐+热度）

新人通过首场秀推荐

知乎阅读

知乎微博及个人自媒体等新媒体转发

知乎的XXXX年的总结（或许也可以算）

知乎的内容整合通过几种形态展现：

知乎日报

知乎圆桌

知乎周刊

出版发行

过去尝试过在问题下的答案总结其他（我只列举了大的方面，更细节的设计在此不涉及），比如过去通过问题去集结的各种TOP XX等。

Chapter 3 通知与消息

好了，我们要来聊一下通知与消息的推送了。

网站/产品触达用户有各种渠道、各种手段，但是用的最多的可能就是各种通知与消息，在Web上，我们通常会见到 消息中心 模块，这个模块会对用户进行站内的消息通知（当然它还可以做其他的消息推送），我们还会看到各种营销邮件、营销短信；在App上，我们看到的推送渠道触点就更多：系统推送、应用内推送等等。

这些都是推送的渠道。

Step 1 推送渠道的选择

推送渠道的选择上，当然要考虑两方面因素：

推送内容的对象

在选择渠道时，优先考虑渠道是否覆盖推送对象，如果之前用户根本不看邮箱的EDM，那么你通过这个渠道去推送用户消息，就是无意义的，如果用户对手机应用上的小红点有强迫症，那么你就应该更多的使用这种渠道和方式去进行推送。

推送内容的时效性

推送对象确认了，就要考虑推送的内容的时效性如何，如果是非常紧急的推送，那么就要尽可能的利用用户最常使用的渠道去告知，比如，如果站内发生了拖库，用户信息可能被泄露，你通知用户更改密码就要用最直接的方式，如：用户短信推送、网站弹浮等等；如果你的消息没有这么强的时效性，你就可以选择更柔和的推送渠道，发封邮件、给个登录提醒，给个站短，之类的。

Step 2 推送内容的撰写

不知道大家的习惯如何，通常我收到系统消息（不管什么渠道），都会只看标题或者最前面的一些文字，以确定要不要展开它，还是直接就忽略掉。

所以推送内容务必要直接了当，当然，这种直接了当是根据你用户的习惯来的，如果你的用户是小清新，你可能就需要包装成让他想读的文字，如果你的用户是图便宜的，可能全场1折起的标题就比你先说个小故事要更容易让用户去阅读。

Step 3 推送效果的判定与后期运营

推送了自然要知道有没有达到目的，那么对推送后的用户行为的监测就是有必要的，对用户行为数据的分析就是很重要的。

通过分析数据，我们可以知道用户对哪些渠道是信任的、有兴趣的，对哪些渠道是不感冒的、触达不到了，也可以明白用户对哪些消息是乐于了解的，对于哪些消息是不感兴趣的，还可以知道什么样的文案和内容是可以促进用户进一步的动作的，那么，在日后的运营中就可以有意识的进行调整和提高，已达到更好的效果。

这里补充一些关于推送效果判定的说明。

通常，用户从收到推送到完成转化的路径是这样的（简单画一下，如果有遗漏在所难免）：

在用户的路径中，各个环节应该都有统计数据，关键看网站/产品有没有在数据方面有这方面的考量和设计，如果没有，那么就要加上。

这里的数据表现结构肯定是个漏斗：

所以，你需要了解就是，漏斗的每个环节分别的转化率是多少，比照渠道、内容、用户选型去看。从而完成分析。

不知道这么说，是否把这个事情说清楚了，噗噗。

Notice：避免用户打扰

即便用户对推送这件事情很接受，我们也不应该时时刻刻对用户进行推送，否则就和狼来了一样，用户腻了就不看了。所以这一点还是需要提醒需要进行消息推送操作的同学的。

To Be Continued……