Episode 7 內容運營面面觀

好了，上次的內容，讓很多運營同事出來大吐苦水，甚至有個實習生同學出來告訴我，2千條數據匹配的例子弱爆了，15萬條數據匹配才是真苦逼有木有！另外@果仔也提到了看能不能聊聊消息推送的事情，我想想，那么就一起放在這一集里聊吧。

開篇前，必須先說明一下，內容運營的活兒，我已經多年沒有做過了，所以，以下內容可能過時，可能有偏差，敬請包涵，如果其中有謬誤，也歡迎指出，共同提高。

Chapter 1內容運營的初期事項

Step 1 內容供應鏈

內容供應鏈這個詞是在上汽工作的時候，從IBM那邊舶來的詞匯。開始的時候，我始終想不明白，供應鏈關內容什么事兒，或者內容關供應鏈什么事兒，這倆是怎么湊到一塊去的，后來仔細想想，發(fā)現這個詞也不無道理。

事實上，不管是社區(qū)型網站/產品，還是交易型網站/產品，還是門戶網站/產品，在建立初期，都會考慮幾件事：

• 網站/產品上有哪些內容
• 這些內容從哪里來，由誰提供
• 這些內容要如何組織與呈現
• 這些內容如何做篩選，什么是好的內容
• 這些內容給誰看，達到什么樣的目標

好了，你看，你有來源，有展現，有標準，有受眾，有目標，確實類似供應鏈流轉方式。

過去我們可能會說，內容建立初期的首要問題是解決內容從哪里來到哪里去的流程問題。而現在如果從我個人的角度再來看內容建設初期任務，可能會更進一步的變成：網站/產品提供的內容傳達了網站/產品的價值觀，因此在內容建設初期，除了確認流程問題之外，還要確立內容評價標準。

內容供應鏈雖然只是一個名詞，但是我覺得至少在目前，它還是體現了進步的理念，即：

將你的內容視為你的商品，從初始階段就定義這個商品的銷售對象、選品和展示方式。進而確保上線后的后臺內容流轉與前臺展示。

Step 2 內容初始化

內容初始化是另一個在內容運營初期要做的事情。

什么是內容初始化，對的，就是在你構建好的內容框架下，去填充一些內容，而這些內容是內容運營初期網站/產品上的核心部分。

對于社區(qū)型網站/產品來說，可能是假扮成用戶或者定向邀請一些種子用戶開始做一些內容填充，然后后來來的用戶大致知道這個社區(qū)是什么樣的社區(qū)，怎么玩；對于交易型的網站/產品來說，商品信息、圖片展示就是內容初始化的重點；對于門戶網站/產品來說，新聞、資訊就是內容初始化的重點，等等。

Chapter 2 持續(xù)運營

Step 1 內容引導與UGC構建

完成了初始化，就會走到正式運營階段，內容運營的展開，離不開的是當用戶進入之后，要如何引導用戶去看到內容，如何讓用戶滿意這些內容，如何促進用戶建立UGC（社區(qū)型網站/產品的互動、回復、發(fā)表等；交易型網站/產品的成交、評論等；門戶網站/產品的發(fā)言、評論、回復，等），如何篩選用戶內容，如何阻擋垃圾信息，這些就是很重要的內容。

雖然我們一直說“自運營”是最高的境界，但是在這個境界之前，必須要做的引導，如果沒有這一步，那是不可能實現健康有序的“自運營”的。

Step 2 內容推薦與整合

當網站/產品內容逐漸充實，內容運營人員的日常工作中最重要的就是：內容推薦——讓優(yōu)質內容露出及內容整合——讓同屬大類的優(yōu)質內容集結。

這一點上，大家通過知乎的推薦、日報、出版可見一斑。

在這里我覺得可以多說一些，正好拿知乎的內容運營舉個例子:

知乎的內容推薦機制有幾個部分組成：

• 關注話題與關注對象的Timeline，這個我不截圖了，大家都懂的。
• 話題動態(tài)推薦新近發(fā)生的有關關注話題的動態(tài)。

• 熱門內容通過發(fā)現推薦（編輯推薦+熱度）

新人通過首場秀推薦

• 知乎閱讀

• 知乎微博及個人自媒體等新媒體轉發(fā)
• 知乎的XXXX年的總結（或許也可以算）

知乎的內容整合通過幾種形態(tài)展現：

• 知乎日報

知乎圓桌

• 知乎周刊

• 出版發(fā)行

過去嘗試過在問題下的答案總結其他（我只列舉了大的方面，更細節(jié)的設計在此不涉及），比如過去通過問題去集結的各種TOP XX等。

Chapter 3 通知與消息

好了，我們要來聊一下通知與消息的推送了。

網站/產品觸達用戶有各種渠道、各種手段，但是用的最多的可能就是各種通知與消息，在Web上，我們通常會見到 消息中心 模塊，這個模塊會對用戶進行站內的消息通知（當然它還可以做其他的消息推送），我們還會看到各種營銷郵件、營銷短信；在App上，我們看到的推送渠道觸點就更多：系統推送、應用內推送等等。

這些都是推送的渠道。

Step 1 推送渠道的選擇

推送渠道的選擇上，當然要考慮兩方面因素：

• 推送內容的對象

在選擇渠道時，優(yōu)先考慮渠道是否覆蓋推送對象，如果之前用戶根本不看郵箱的EDM，那么你通過這個渠道去推送用戶消息，就是無意義的，如果用戶對手機應用上的小紅點有強迫癥，那么你就應該更多的使用這種渠道和方式去進行推送。

• 推送內容的時效性

推送對象確認了，就要考慮推送的內容的時效性如何，如果是非常緊急的推送，那么就要盡可能的利用用戶最常使用的渠道去告知，比如，如果站內發(fā)生了拖庫，用戶信息可能被泄露，你通知用戶更改密碼就要用最直接的方式，如：用戶短信推送、網站彈浮等等；如果你的消息沒有這么強的時效性，你就可以選擇更柔和的推送渠道，發(fā)封郵件、給個登錄提醒，給個站短，之類的。

Step 2 推送內容的撰寫

不知道大家的習慣如何，通常我收到系統消息（不管什么渠道），都會只看標題或者最前面的一些文字，以確定要不要展開它，還是直接就忽略掉。

所以推送內容務必要直接了當，當然，這種直接了當是根據你用戶的習慣來的，如果你的用戶是小清新，你可能就需要包裝成讓他想讀的文字，如果你的用戶是圖便宜的，可能全場1折起的標題就比你先說個小故事要更容易讓用戶去閱讀。

Step 3 推送效果的判定與后期運營

推送了自然要知道有沒有達到目的，那么對推送后的用戶行為的監(jiān)測就是有必要的，對用戶行為數據的分析就是很重要的。

通過分析數據，我們可以知道用戶對哪些渠道是信任的、有興趣的，對哪些渠道是不感冒的、觸達不到了，也可以明白用戶對哪些消息是樂于了解的，對于哪些消息是不感興趣的，還可以知道什么樣的文案和內容是可以促進用戶進一步的動作的，那么，在日后的運營中就可以有意識的進行調整和提高，已達到更好的效果。

這里補充一些關于推送效果判定的說明。

通常，用戶從收到推送到完成轉化的路徑是這樣的（簡單畫一下，如果有遺漏在所難免）：

在用戶的路徑中，各個環(huán)節(jié)應該都有統計數據，關鍵看網站/產品有沒有在數據方面有這方面的考量和設計，如果沒有，那么就要加上。

這里的數據表現結構肯定是個漏斗：

所以，你需要了解就是，漏斗的每個環(huán)節(jié)分別的轉化率是多少，比照渠道、內容、用戶選型去看。從而完成分析。

不知道這么說，是否把這個事情說清楚了，噗噗。

Notice：避免用戶打擾

即便用戶對推送這件事情很接受，我們也不應該時時刻刻對用戶進行推送，否則就和狼來了一樣，用戶膩了就不看了。所以這一點還是需要提醒需要進行消息推送操作的同學的。

To Be Continued……

#專欄作家#

張亮，微信公眾號：zhangleo1983，人人都是產品經理專欄作家。知乎大V，互聯網從業(yè)者；《從零開始做運營》作者。聊產品聊運營，偶爾深度。分享一切有益有趣的內容。

本文原創(chuàng)發(fā)布于人人都是產品經理，未經許可，不得轉載。

系列文章：

從零開始做運營（Episode 1）

從零開始做運營（Episode 2）

從零開始做運營（Episode 3）

從零開始做運營（Episode4）

從零開始做運營（Episode5）

從零開始做運營（Episode6）