本文主要跟大家分享一下，運營后臺的管理權限如何設計，一起來文中看看~
為了明確詞匯的語義邊界，特對本文中頻繁出現的詞匯進行語義定義，這個定義是筆者的私設，讀者可將其按照語義定義換成自己慣常使用的詞匯。
- 內容對象：信息產品中，承載了信息的對象，該對象可被角色進行操作，類似于UML中的實體類，比如：問卷、博文、商品、購買頁面等。
- 內容數據：運營創建的數據（可以算是OGC），比如：視頻平臺的電視劇視頻、調查問卷、購買頁面等。
- 一次數據：用戶創建的數據（實際是就是UGC，為了區別于二次數據，本文將UGC稱為一次數據），比如：評論、報名信息等。
- 二次數據：通過對用戶的一次數據和用戶在產品中的行為記錄等進行統計，所獲得的數據，比如：PV、UV、訂單總量等。
一、信息產品的結構
在信息產品中，C端業務的核心就是C端用戶對承載信息的內容對象進行操作，操作包括增刪改查四個方面。后臺運營產品的運營能力包括對內容對象的直接操作（也是增刪改查的權限），和對用戶的操作能力進行限制和審核。
假設一個信息產品包括用戶端、運營管理后臺和數據倉庫，結構示例如下：
信息產品結構
有兩種成熟的產品模型：
- 一種是表單產品模型，代表產品是金數據，問卷網等；
- 還有一種是BBS模型，比如：視頻網站（視頻-評論）。
這些產品的數據庫（database）中，都包含內容數據和一次數據，區別在于一次數據是不是按照內容數據的預設格式進行結構化生成的。
運營后臺對內容數據和一次數據的管理思路是不一樣的，權限設計也會有所不同。
二、一次數據的運營管理
不同業務場景下，一次數據的特點也不同，運營的管理需求也不一致。
有這樣三種典型的業務場景：
（1）視頻網站（視頻-評論）
一次數據（評論）是和內容數據（視頻）是有聯系的，在數據庫層面需要做表連接的設計，對運營能力的思考可以從兩方面進行展開：
- 刪除/查看用戶創建的評論；改變評論的結構化數據中的某些值（比如說：點贊數、熱度）。
- 控制用戶對評論的增刪改查權限。
從應用上來說，運營的基礎需求是輿情審查和社區氛圍維持。視頻網站的評論特點可能是瞬發到一個數量級以后，平穩增長直到達到穩定數值。為了維持評論氛圍，運營需要查看評論、刪除違規評論、打撈精品評論，必要時可能需要放出小號來進行控評和引導。
我們用user story來總結用戶需求：
user story：運營管理視頻下評論
總結用戶需求，我們可以這么設計運營對評論的管理功能：
運營對評論的管理
（2）帖子
比如：新浪微博、網易lofter、視頻網站的原創視頻模塊，產品支持用戶創建和上傳帖子、視頻等一次數據。這類數據的特點是：用戶完全自發增加，增加的曲線可能是穩定每日自增的。
對于有些社區，運營可能做到每條新增一次數據都進行審核查看；但對于新浪微博這種MAU超過4億的國民產品（新浪微博 2018年Q1財報發布），全部增量微博全部由運營監督管理查看是一件不現實的事情，運營的需求更偏向于審查核心帖子和完善輿情監管策略。
user story：運營管理社交媒體的帖子
總結用戶需求，我們可以這么設計運營對帖子的管理功能：
運營對帖子的管理
（3）帖子下的評論
這是針對一次數據生成的一次數據，比如：原創帖子下的回復。一般來說，這些評論的控制權力被分配給帖子的創建者，但是在某些情況下，運營有必要參與管理。運營需要直接審核帖子下的單條評論的場景很少，一般是針對帖子進行全體評論的管理。
user story：運營對帖子下回帖的管理
總結用戶需求，我們可以這么設計運營對回帖的管理功能：
運營對回帖的管理
三、內容數據的管理
內容數據是運營創建并投放到C端的內容對象，一般來說無需進行內容復審。比如：40集《鎮魂》網劇就是youku增加的內容數據，觀眾在產品內留下的評論都是一次數據。
user story：運營對內容對象的管理
綜上可設計：
運營管理自建數據
本文為@運營喵原創，運營喵專欄作者。
