Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
我思故我在a
Python专题
提交
58e77677
Python专题
项目概览
我思故我在a
/
Python专题
与 Fork 源项目一致
Fork自
GitCode官方 / Python专题
通知
1
Star
1
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
DevOps
流水线
流水线任务
计划
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
Python专题
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
DevOps
DevOps
流水线
流水线任务
计划
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
流水线任务
提交
Issue看板
体验新版 GitCode,发现更多精彩内容 >>
提交
58e77677
编写于
5月 24, 2021
作者:
M
MaoXianxin
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
更新一篇人人都是产品经理文章 专家运营到底是在运营什么
上级
21adcc82
变更
2
隐藏空白更改
内联
并排
Showing
2 changed file
with
40 addition
and
0 deletion
+40
-0
README.md
README.md
+4
-0
人人都是产品经理/专家运营到底是在运营什么.md
人人都是产品经理/专家运营到底是在运营什么.md
+36
-0
未找到文件。
README.md
浏览文件 @
58e77677
...
...
@@ -37,3 +37,7 @@
**今日新增**
[
WAVE SUMMIT 2021飞桨九大全新发布,敲响产业智能化升级最强音
](
./PaddlePaddle/WAVE
SUMMIT 2021飞桨九大全新发布,敲响产业智能化升级最强音.md)
往期精彩链接:
[
点击这里
](
./PaddlePaddle
)
## 人人都是产品经理
**2021-05-24-新增**
[
专家运营到底是在运营什么
](
./人人都是产品经理/专家运营到底是在运营什么.md
)
人人都是产品经理/专家运营到底是在运营什么.md
0 → 100644
浏览文件 @
58e77677
不知道有多少网站在日常运营工作中会用到“专家运营”这个词,问答社区(知乎)、技术社区(CSDN)、在线教育(MOOC)?其实,我说的“专家”很容易解释:
**在所属领域足够专业,并能利用自己的专业知识为网站贡献有价值内容的用户**
。也就是说,专家只是某一部分“特殊用户”,因为他们对网站内容的影响力远高于普通用户,作为网站或产品的运营方需要有专人负责运营这部分用户,换句话说,喂他们吃草,指望他们持续供奶。
事实上,专家运营和所有的运营工作一样,是一项繁杂而敏感的工作。专家领域不同、水平不同、贡献程度不同;再加上个人性格差异,以及某些行业从业者特有的交流方式(我没有在黑程序员),日常的运营工作会显得非常琐碎,做起来也缺乏成就感。上述的这些感受都来自于个人工作中的亲身体验,相信也能引起很多同行的共鸣。
作为一名理科生,始终坚信世间万物都是有规律可循的(除了和女友相处),就像程序员的职业生涯都是起始于一句“Hello World”,休止于一个找不到的Bug一样,作为负责专家运营的童鞋,也应该学着让自己的工作有一个看上去高大上的开始,我为这个起点想了个略带艺术范的名字 — 专家画像,英文可以叫做Zhuangjia Huaxiang。
### 什么叫做“专家画像”?
用户画像的概念大家应该很熟悉,引用一个忘了在哪看来的定义:能够客观、准确、可视化地描述目标用户的工具或方法。
所以,专家画像就是指能够客观、准确、可视化地描述专家用户的工具或方法。
### 怎样建立专家画像?
建立一个完整的专家画像,我一般采用的方式是“标签化”。
所谓标签化,是指我们根据网站或产品对专家的具体需求,将专家的各种属性以标签的形式进行管理的工作方法。
我们需要建哪些标签?标签会涉及到哪些维度?一个专家进行了“标签化”处理之后,我们要进行怎样的后期管理和应用?这三个问题应该是整个工作过程中给我们带来最多困扰的了。
### 需要哪些标签?
这个问题真的是需要你根据自己产品的属性自行解决了。如果我负责知乎的专家运营,专家所属领域就是我一定会加进去的标签,这样当我要用到“体育”类的专家时,只需要在专家管理后台的一次点击就能让所有带有“体育”标签的专家出现在屏幕上了。当然,画像粒度视需求而定,例如体育类别下还有“足球”、“篮球”等一大波标签,显然只标记“体育”,是没办法将足球狗和篮球狗区分出来的。
此外,除了网站根据需要对专家进行的划分,我们对专家某些个人信息的掌握也能对专家运营工作产生正面的影响,这里所说的当然不是将个人信息以商业手段泄露给需求方,本人很反感这样的方式。
举个例子:如果我们掌握了专家的地域信息,当你所在的网站有线下活动时,是不是可以考虑优先将机会提供给我们的专家,算是一种社区福利?如果我们掌握了专家的生日,是不是可以考虑在他们生日的那天,送上一份小礼物呢?不麻烦,但足够有心,也能在很大程度上提升专家对我们的归属感。
### 标签需要哪些维度?
其实上文所说的专家领域某种程度上就算是一个维度了,这里还要单独说一下标签维度;是因为很多童鞋看到标签想到的都是有关专家身份属性的东西,不管是专业领域,还是个人信息,这些是否就足够了呢?显然不是,让我们回到做这项工作的初衷,是的,就是“喂他们吃草,指望他们持续供奶”这个目的。我们掌握了专家的个人信息只是一个防守动作而已,或者说只是完成了一次战役的后勤工作,靠着后勤是打不赢仗的,我们需要进攻性动作,我们要分析所有专家的信息,想想这些专家来能我们创造什么价值。
同样来举例说明,如今的网站很大程度上是作为一个媒介连接了互有需求的两个人群,理想情况下,在我们的“撮合下”,需求双方应该可以达到一个共赢的状态。当需求方信任我们并将他们的需求交付给我们时,我们如何更有效率的在最短时间内将他们需要的结果或者资源提供给他们,也在很大程度上决定了网站存在的价值。所以,我们不妨将我们日常常见的需求同样做“标签化”的处理,并将我们掌握的专家资源与这些标签建立关联关系。场景化一下,需求方需要我们网站提供一些可以做线下沙龙讲师的人选,我们在后台点击“线下讲师”和相关领域标签,所有符合要求的专家资源都会呈现在眼前。看上去很简单的事情,据我所知,很多同行依然要去为了这个需求麻烦程序员跑数据,然后自己Excel个半天时间。
总的来说,通过对专家画像和日常需求的标签化处理,我们可以很明显的提高专家运营的工作效率,将能够流程化的工作尽量流程化,节约工作时间。不过话说回来,专家运营终究是在跟人打交道,不像产品和代码那样有规律可循,还是需要我们根据实际情况,自己来总结经验的,这里只是先抛个砖而已。希望各位真的用心去做这件事情,将心比心,让专家也能感觉到我们的工作是有温度的,自然会对我们更有归属感。
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录