运营后台的管理权限设计

　　本文主要跟大家分享一下，运营后台的管理权限如何设计，一起来文中看看
　　为了明确词汇的语义边界，特对本文中频繁出现的词汇进行语义定义，这个定义是笔者的私设，读者可将其按照语义定义换成自己惯常使用的词汇。
　　内容对象：信息产品中，承载了信息的对象，该对象可被角色进行操作，类似于UML中的实体类，比如：问卷、博文、商品、购买页面等。
　　内容数据：运营创建的数据（可以算是OGC），比如：视频平台的电视剧视频、调查问卷、购买页面等。
　　一次数据：用户创建的数据（实际是就是UGC，为了区别于二次数据，本文将UGC称为一次数据），比如：评论、报名信息等。
　　二次数据：通过对用户的一次数据和用户在产品中的行为记录等进行统计，所获得的数据，比如：PV、UV、订单总量等。
　　一、信息产品的结构
　　在信息产品中，C端业务的核心就是C端用户对承载信息的内容对象进行操作，操作包括增删改查四个方面。后台运营产品的运营能力包括对内容对象的直接操作（也是增删改查的权限），和对用户的操作能力进行限制和审核。
　　假设一个信息产品包括用户端、运营管理后台和数据仓库，结构示例如下：
　　信息产品结构
　　有两种成熟的产品模型：
　　一种是表单产品模型，代表产品是金数据，问卷网等；
　　还有一种是BBS模型，比如：视频网站（视频评论）。
　　这些产品的数据库（database）中，都包含内容数据和一次数据，区别在于一次数据是不是按照内容数据的预设格式进行结构化生成的。
　　运营后台对内容数据和一次数据的管理思路是不一样的，权限设计也会有所不同。
　　二、一次数据的运营管理
　　不同业务场景下，一次数据的特点也不同，运营的管理需求也不一致。
　　有这样三种典型的业务场景：
　　（1）视频网站（视频评论）
　　一次数据（评论）是和内容数据（视频）是有联系的，在数据库层面需要做表连接的设计，对运营能力的思考可以从两方面进行展开：
　　删除查看用户创建的评论；改变评论的结构化数据中的某些值（比如说：点赞数、热度）。
　　控制用户对评论的增删改查权限。
　　从应用上来说，运营的基础需求是舆情审查和社区氛围维持。视频网站的评论特点可能是瞬发到一个数量级以后，平稳增长直到达到稳定数值。为了维持评论氛围，运营需要查看评论、删除违规评论、打捞精品评论，必要时可能需要放出小号来进行控评和引导。
　　我们用userstory来总结用户需求：
　　userstory：运营管理视频下评论
　　总结用户需求，我们可以这么设计运营对评论的管理功能：
　　运营对评论的管理
　　（2）帖子
　　比如：新浪微博、网易lofter、视频网站的原创视频模块，产品支持用户创建和上传帖子、视频等一次数据。这类数据的特点是：用户完全自发增加，增加的曲线可能是稳定每日自增的。
　　对于有些社区，运营可能做到每条新增一次数据都进行审核查看；但对于新浪微博这种MAU超过4亿的国民产品（新浪微博2018年Q1财报发布），全部增量微博全部由运营监督管理查看是一件不现实的事情，运营的需求更偏向于审查核心帖子和完善舆情监管策略。
　　userstory：运营管理社交媒体的帖子
　　总结用户需求，我们可以这么设计运营对帖子的管理功能：
　　运营对帖子的管理
　　（3）帖子下的评论
　　这是针对一次数据生成的一次数据，比如：原创帖子下的回复。一般来说，这些评论的控制权力被分配给帖子的创建者，但是在某些情况下，运营有必要参与管理。运营需要直接审核帖子下的单条评论的场景很少，一般是针对帖子进行全体评论的管理。
　　userstory：运营对帖子下回帖的管理
　　总结用户需求，我们可以这么设计运营对回帖的管理功能：
　　运营对回帖的管理
　　三、内容数据的管理
　　内容数据是运营创建并投放到C端的内容对象，一般来说无需进行内容复审。比如：40集《镇魂》网剧就是youku增加的内容数据，观众在产品内留下的评论都是一次数据。
　　userstory：运营对内容对象的管理
　　综上可设计：
　　运营管理自建数据