operation

做 2b 运营三年，说长不长，说短也不短，且以这个 repo 记录下一些运营相关的总结和谈不上是技巧的把戏。

在开篇之前，感谢下前东家我的第一任领导 @min.wu，没有一个好的领导给一个好方向，是很难做成事情的。如果说 NebulaGraph 的国内运营成就有十分功劳，min.wu 占八分，我占剩下两分吧。

如何从零开始做 2b 运营

当我三年前，面试前东家时，我只有 2c 的运营经验，我后来在前东家分发很多内容在我做 2c 的时候都以“推广”为理由判断为垃圾推广信息被隐藏过，索性的是，现在的技术平台的运营比当初的我更灵活没那么轴。

回到正题，如何从零开始做一个 2b 的运营？

我的答案是：抄作业！

如果你不知道一件事情怎么做，那么最好的开始姿势就是看别人怎么做。当然抄作业不是说看到一份作业就抄，而是你要判断你现在业务处于什么阶段，去抄对应其他公司相同阶段的作业。这有点像是，你一个一年级学生，去抄人家三年级学生的作业，是不合适的。

除了抄对阶段之外，不要照抄，要去多角度去思考他们背后的动机以及相关的环境因素。

我的抄袭对象

三年前，2021 年的时候，PingCAP 已经是一个非常知名的开源项目，所以我花了大概 2 周时间分析了他们的时间线。

PingCAP 时间线

(截图清晰度问题，可查看对应 Excel 表)

我的作业

这里罗列了关键时间线。

折叠进去的关键时间线

关键时间线

• 2019.07 开启 18 个内容分发渠道
  • 渠道选择：前期没有明确的场景，以及目标用户，所以我把目标用户 tag 在程序员，开了 10 多个（没记错应该是 18 个）国内程序员活跃的技术平台（在我司之前，我在国内 2 家技术平台待过），去差别；
  • 内容来源：早期没有具体的应用场景实践，所以内容依靠之前在 AsiaCon（之前的存储负责人是 HBase 的 Committer）、我们自己的线下 Meetup 演讲稿整理整理而成；
  • 内容分发策略
    • 标题：因为国内图数据库教育市场并不如国内成熟，所以在 2019-2020 年之间的对外标题都蹭「图数据库」、「数据库」，甚至 Nebula Graph 不加都会用图数据库，以及市面上一些比较被人所熟知的技术，例如：分布式、HBase（注：这是产品）；
    • 内容形式：因为早期内容过于匮乏，为了保持账号的活跃度，持续曝光产品，所以早期的文章除了会发一次文章之外，还会将文章裁剪成若干块，变成短内容，例如：图数据库应用场景、图的 OLTP 和 OLAP 场景；
• 2019.08 开启公开平台的活动同步
  • 之前活动依靠微信的私域流量，只在公众号、员工朋友圈进行推广，在第三期（第一期和第二期我还没入职）开始，在开源中国、掘金、思否、活动行等公开活动平台进行活动曝光，活动主题策略同早期内容，依旧是靠图数据库这个新名词；
• 2019.09 第一个线上活动
  • 活动形式：参加开源中国的你问我答活动，让开源中国的用户来问图数据库问题；
  • 二次曝光：整理这个活动的 QA，变成「关于图数据库人们都问了啥」主题科普贴，发在了内容同步渠道；
• 2019.10 参加第一个线下大型技术大会 QCon
  • 主要目的：科普图数据库和推广 Nebula Graph，宣传图上面写的是新一代图数据库；
• 2019.11 开启社区周报
  • 主要目的：填补内容不足，以及分发一些 Nebula 使用技巧、Nebula 产品开发动态；
• 2019.12 开始第一场视频直播
  • 活动形式：因为之前老板他们一直觉得直播没有线下见面来的真实，有交流。所以直播一直都是被排斥的活动形式，12 月这场直播是采用了线下报名，线上看直播的形式；
• 2020.01 热点文章
  • 主题策划：因为 1 月疫情起来了，借传播链加入真实的疫情传播 case 写了个“从天津百货大楼 5 病例“迷局”见新冠病毒传播路径”
• 2019.08-2020.06：地推，和用户交流；
• 2020.06.30 开始长达 4 个月的 BD 邮件
  • 现在回看，我们很多用户的名字和邮件的收件人是重叠的。其实，有个优化点是可以留下运营人员的 IM 联系方式。
• 2020.06 开始常规化用户回访
  • 目的：了解用户的使用问题，以及借机推广最新的发型版了；
• 2020.02 论坛和官网上线

我对 2b 的理解

2b 的 b 是 business 的缩写，顾名思义，你的用户是企业而非个人。作为一个有丰富 2c（不是）经验的运营，我觉得 2b 和 2c 的不同点在于：

• 2b：卖的是服务，用户实打实有需求需要用这款产品。包括运营在内，你需要思考的是如何帮用户解决问题，更快用上以及依赖该产品；
• 2c：卖的是情感，用户不一定需要这款产品，但是通过运营手段让用户同你 / 产品产生情感联系。

没错，2c 你有个人魅力是一个非常棒的优势。不过，我觉得目前大多数的社区 / 技术产品运营是兼顾 2b 和 2c 特点的，你既要帮用户解决问题，也要同特定的人群建立情感联系。

细分之内容运营

上面这个是一条信息，或者说是一个内容的一个生命周期，也是比较常见的生命周期；在我看来，内容运营要做的两件事：讲好故事（生产期）、让人更容易听懂这故事（预发布），这里似乎少了所谓的流量和爆款，在我看来那是一个结果，而不是一个目的。

下面分解下，这个流程的各个环节；

内容之策划

策划，一般来说内容人员都具备一定的策划能力，或者不具备无妨。在我看来，运营人员的把控的事整条链路的正常运作，尤其后面的发布，需要将这个内容传播地更远、更好，这是我理解的运营人员的侧重点。但是不是说生产环节的东西不重要，而是运营人员可以少参与，像是一个产品运营一样，重点是如何让它运转起来。后面的发布环节，便是这种运转。

而策划，并非是无中生有，在 NebulaGraph 前期，基本上是没有内容产出的，相关人员的忙着产品迭代，那么有什么事情是策划制作的呢？会变的是代码实现，不变的是顶层设计——架构，所以，前期低频率地产出架构相关内容。当然这里还涉及到后面的内容发布，因为是低频，所以一个内容如果同一时间发布，那么在后续地很长时间这个产品（消息）并消失在人眼前了，所以，这里有一个内容分发的 tips，多渠道分开发，保证某段时期，这个产品活跃在人眼前。

回到策划，策划一般是基于现有、未来一段时间（可以设定为 3 个月）会有的东西进行，这是常规操作，基于产品自身出发的，延伸出来就有相关的内容：

• 特性讲解，涉及特性的原理和相关的使用姿势；
• 使用实践，文档和社区用户实践均可；
• 产品动态，release note 或者是产品介绍，均属于这类；

这是常规的内容，当然作为一个策划人员，你是不能和相关的产出人员（这里假设策划和作者非同一人）说，我要一个特性讲解。换位下，好比有个人和你说，我要一个数据。好的，是什么数据呢？对，这就是策划一定要给出相关的内容主题！一个主题是一个确定的内容方向，但是如何切入这个主题，也是看不同的作者。（详见后面的生产）

除了常规的产品主题，所有运营人员，也是非运营人员都会说的一个事——热点，技术产品追热点要和你的产品相关，比如，2020 年疫情刚起来的时候，我就蹭了个疫情传播链的热点。蹭热点的话，一般是越早越好，根据热度的衰减线

一般来说它不是线性衰减的，而是会有个上升期，根据不同人接触同一信息的先后顺序，内容出来的第二、第三天会达到峰值，随后再一路下跌，在两周时间内会趋于平衡，事实上，一周之后这个热点已经不会再热。

所以，蹭热点一定要早，而且切入点也很重要。这便是后面，主题确定之后的撰写环节了。

内容之撰写

确定主题之后，就需要找相关的人员撰写内容了。这里说个近期事情，我想出一个「世界杯预测冠军」主题，这个主题很确定，但是我一直没有写，为什么呢？因为这个主题涉及了相关的技术点——图计算，所以我拜托了相关同事来写。所以，主题策划和内容撰写，是可以独立分开的。

而内容的编写的切入点也会因为不同的人有所不同，比如：ChatGPT 这个主题，有人写语料库、prompts，这些都是在讲用法，也有人从开源角度切入，提出这个项目是否会开源，从而引出产品背后的公司，以及其相关的开源产品。角度不同，即便是同一主题，也会有不同的效应。

这里讲一个作者（撰写内容人）应该注意的事项，落笔之前需要思考清楚：

• 它（这个内容）是给谁看的；
• 看的人是否能明白我说的是什么；

内容之编辑

编辑，是我整个运营工作中干的最多的事情。为什么？因为，如果前面生产环节，作者没有讲明白这个故事，编辑就要负责将它讲明白，让读者更容易理解。这个环节，只有一个目的：好理解。当然，免不了会有一些 typo fix 的工作在里面。

举个例子，技术文章经常会有遇到流程问题。像这篇稿子 Nebula 基于全文索引擎的文本搜索，第四部分讲述的逻辑，其实是一早是没有流程图的，在我编辑的过程中，试图去理解当中的逻辑，便自行绘制了这个图。记住一点一图胜千言，一个流程图搭配相关的文字，能更好地让读者在脑子形成相关的路线图；除了帮助读者理解之外，一个流程图也能帮助作者来思考是否他讲清楚了流程，因为绘制流程图过程中，我会反复和作者确认，是否是这个意思，一旦你的流程图和文字对上了，就说明彼此验证了。

此外，编辑也得帮稿子理清主线，NebulaGraph 的有个同学写稿子非常喜欢在某个章节加入 tips，这固然是好意，但是过多的 tips 插入会打乱读者的阅读主线，好比你在专注一件事，周遭人疯狂地给你插入其他事情，整个节奏就乱了。所以，并非通用的内容，怎么理解呢？即，它是写给部分感兴趣的人的东西，比如使用文档、某个技术的介绍之类的内容，可以统一折叠到文末，注意的是，这里不要折叠在某个语句里需要解释的不常见名词，因为对不常见名词的解释是可以帮助读者理解的。

一言蔽之：面向读者，在原作者的基础上，加工出更容易理解、方便他阅读的文章。

内容之发布

这里已经同作者基本上无关了，这时候内容一般已经定稿。需要考虑的是如何呈现的问题，一般来说国内的技术平台都支持 markdown，而这个是一个免排版让你专注内容产出的格式。到这里，是不是没有什么可以做的呢了？不是的，下面是一个简单的例子，

和

二者都是同样的内容，有什么区别呢？答案是，读者阅读端的信息传递量。前者是横版的，后者是竖版，在设备高度固定的情况下，横版除了占据更少的高度之外，还可以将剩余的高度用来展示其他信息。当然，这里还涉及到了阅读习惯：先从左往右，再从上往下。所以，横版的流程图更合适。

上面讲的是内容发布当中的正文部分，当然，它也是编辑的一部分。其实，内容发布最重要的是，一般内容运营不会只同步一个平台，而是多平台同步内容，这当中涉及了对平台读者调性的把控。

举个例子，https://discuss.nebula-graph.com.cn/t/topic/11510，这是一个如何做内核代码贡献的教程，它在各个平台的标题是这样的：

• NebulaGraph 自己平台：你的内核开发指北，新手也能搞 NebulaGraph 内核开发，这里强调的是“你”这一个体；
• 技术平台：从一个 issue 出发，带你玩图数据库 NebulaGraph 内核开发，因为在第三方平台，读者大概率是不知道 NebulaGraph 是什么的，所以这里加了一个对它的定义；
• 传统的平台：零基础搞定数据库内核开发，这么抽象的原因是因为虽然它是 NebulaGraph 的内部人员编写的，但是它也可以作为通用型的数据库开发贡献指南。

这里说下为什么技术平台没有抽象产品，因为虽然抽象成「零基础搞定数据库内核开发」模糊特定的产品会带来更大的流量，但是站在 seo 和产品曝光角度，自然是加上产品更加。再举个例子，文章「ChatGPT 加图数据库 NebulaGraph 预测 2022 世界杯冠军队伍」这个标题，某个平台的运营人员和我建议将 NebulaGraph 去掉，我拒绝了，理由：

1. 这篇稿子涉及了两款技术，ChatGPT 和图技术，所以 NebulaGraph 是不能去掉的，加上之后可以有更精准地用户进来；
2. 还是上面的产品曝光的需求；

讲到这里，要说下，多渠道同步内容也许觉得很 boring，但是，可以在各个渠道尝试不同的标题，带来不同的阅读，也是蛮有意思的。

内容之复盘

这里是数据层面的东西，一般来说，可以同类型内容横向对比（热点对热点、特性讲解对特性讲解），发布时间横向对比（比如大家都是周一发的，或是都是下午发布的）。像是公众号，可以查看内容的分布情况，比如，直接打开阅读的有多少，微信群的多少，分享获得的阅读多少，各自占比，同其他文章相比较。

对比的结果是用来优化下次的内容生命流程图的，比如，分享好的话，可以引导多分享等等操作。