如何撰寫一份有內涵的網站運營優化方案（親身案例）

仲介交易 SEO診斷 淘寶客 雲主機 技術大廳

今天七夕，幾個待婚兄弟紛紛打電話去漢庭、格林開了房，我也迫不及待的播出了號碼，結果命途不濟，房已定涸，這一怒非同小可，我決定寫一篇文章來告誡自己：開房要趁早!

最近在微信「網站運營108將」公眾號上，好多人問我怎麼撰寫一份運營方案，我一一 回答，感覺忙不過來，正好上上週末我在家做了一份資料運營方案(網站優化方向)， 所以我打算用親身實戰的經驗來通俗化說一下：我是怎麼搞網站運營優化方案的。

業務旺季來了，領導說：韓利呀，這個核心業務的資料運營你來做吧，儘快出一份網站運營優化方案。 我欣然應諾(嘻嘻，我的工作態度一直鮮活，來了新活，總是特別興奮，一來自己平時靠個人站琢磨的東西終於又可以及鋒一試了;二來剛剛轉型做職業社交業務，由此一役，更能總結到不少運營知識了)

那麼，我該從何入手呢：按慣例，肯定是從資料下手，去發現網站本身的問題。 往期經驗，資料我一直認為有三大來源：網站監測工具的點選流資料、日誌數 據和體驗資料。 前兩個數據來源不用贅述，凡是做運營的童鞋都知道。 體驗資料是什麼呢?體驗資料，就是你自身作為一個使用者，帶著使用者的任務目標去體驗你即將 運營的網站的各個業務流、交互細節，發現問題;當然，錦上添花的事情，你還可以體驗下競爭對手的網站。 某種情況下，競爭對手的體驗資料的說服力勝過網站監 測工具和日誌資料帶來的說服力。 當你真正基於自己真實體驗而發現網站大問題時，領導和業務相關人員也就無話可說了。 往期經歷告訴我：網站日誌資料和網站監 測工具的點選流資料因為資料監測方法不同、指標定義不同、個人資料分析經驗多寡會造成很多費舌扯皮的事。 畢竟你給業務相關人員(比如產品經理、演算法、 BD)指手畫腳，說三道四人家心理肯定不願意。 尤其是一個單位牛人如麻的時候，誰都不願意承認錯誤。

一、確定KBR，並分解之

在天極的時候，@宋星經常來給我們做內訓，那時候我跟他學了一套網站分析思路(正是網站運營108將火的時候)：

確定你的KPI>>>找到影響你的KPI的驅動因素(全域驅動+局部驅動)>>>分析網站及業務模組，發現問 題>>>測試改進問題(管道+產品)>>> 改進前後比照，應用效果好的優化。 然後不斷迴圈此運營邏輯。 圖示如下：

所以，我根據招聘業務的關鍵KBR做了一番思考，最終決定攻佔<簡歷投遞量>這個指標，將它翻倍(定目標的時候，我總是缺乏理性，一般 都會把領導嚇一跳，當然我一般都完不成自己定的目標，但是，你懂的。 目標本來就不是拿來完成的，而是用來激勵自己和團隊成員的，所以有時候我經常發現因為 領導離業務較遠，所以定的目標都很武斷時，很多員工都會說，這個領導真二，拍下腦袋目標就定了)

定義了KBR後，接下來分解它，找到全域驅動因素和局部驅動因素，如下圖，我將驅動因素和指標直接掛靠在一張圖上，這樣比較醒目(標黃部分為全域驅動因素):

二、理清業務邏輯，尋找分析資料源

確定好了KBR，並分解了KBR，我決定從關鍵驅動因素轉化率入手去發現問題。 轉化率是一改定全域的指標。 因為對業務流程還不是很熟悉，我拿出了500小號作為體驗使用者來進行深入體驗，最後總結了網站的關鍵業務流程圖：

業務流程理順了，正當我準備從資料部門提供的資料平臺尋找分析來源資料的時候，不幸的收到了一封郵件，大意是資料遷徙到了新的平臺，原有平臺不再提供 服務。 然後我登陸新的平臺，發現我要分析的商務專案的資料全部沒有了。 我就問資料部的負責人，負責人說遷徙的資料都是根據相關業務同事日常點擊排行靠前的 規則遷移的，鑒於你負責的業務模組的資料已經好久都沒有被查看過，所以就沒有遷徙，接下來他還訓斥了我一噸：這麼重要的業務你以前為啥不看資料呢!我暈 ， 我剛接手這個業務呀，不過人家說的對，為啥沒看資料呢。 我說：以後我會看的，能否遷徙下?然後資料部的產品經理說：原平臺的這個專案報表是按照當時的業務 口徑跑的，目前因為新增加了wap\app\微信端等移動端的流量管道和平臺，建議基於現有業務重新整理報表需求。 我一想也是，正好借此自我定義一些指 標。 但是憑空又多出來一項任務：業務資料包表需求整理。

領導可不管這些，催著我寫業務運營方案，這時候我想到了網站資料監測工具。 原來是用GA監測的(我太喜歡GA了，尤其是與google tag manager工具的配合使用)，但是因為GA訪問不穩定的原因，領導近期改用了百度統計。 不是十分強大，我心想，只有自己多費點心了。

三，確定關鍵優化指標一：關鍵流程轉化率

我決定先從轉化率下手分析。 我最喜歡的流程轉化率，經過研究，我發現業務流程分三塊：註冊流程、簡歷創建流程、投遞流程。 我決定先搞投遞流程的數 據，這個最核心。 打開百度，沒有做轉化路徑配置，於是配置上，但是領導急著要方案，等令人信服的資料產生的時候會耽誤方案進度。 於是我從受訪頁面下手，下 載到本地，來個excel笨方法梳理(這個真心累，先得把各url分組歸類)，忙活了一個晚上，終於弄出了第一個報表：

我這麼一看，不禁心裡一樂，因為問題一下就明晰了，好似領導故意送了一個便宜一樣：漏水的地方太多了，不對，是太狠了。 各節點流失的比例「高不可 攀」。 於是我趕緊將分析指導意義附在圖下，鑒於業務秘密，就不放射出來了。 其實一看就明白，只不過是措辭問題，寫的婉轉點而已。 像「狠、太」等描述性字眼 就慎用，要不產品會生氣滴。

接下來，我決定再佐證一下，這時候體驗資料方法派上用場了，我想，是不是競爭對手的投遞流程也是這麼複雜呢，我決定從使用者任務負荷上來佐證比較，結果如下：

烏卡卡，三大流程，使用者完成任務用時和動作次數明顯高於競爭對手，這可不是一個好現象，也側面印證了上文說的流失率高的原因。 招聘平臺本就很多。 使用者為了投遞一份簡歷而費時費力，轉移平臺的意願就會很高。 除非你的職位是獨家發佈。

然後我就按照第三個步驟一個指標一個指標的分析，最終完成了一份圖文並茂的網站運營優化方案。 當然，因為百度統計的功能有限，接下來我又撰寫了網站 資料需求方案，一共整理了12份報表。 我發現，通過這12份報表完全可以理解優化網站關鍵業務，他們分別是：全域概覽資料(給領導看的)、流量來源管道監 測報表(監測BD業務水準和流量品質的)、關鍵流程監測漏斗報表4份(一個全域漏斗、3個關鍵業務流程報表)、 使用者任務負荷報表(監測使用者體驗和交互設 計)、關鍵入口頁面業務表現監測報表(頁面文案、交互功能和視覺表現)、週邊內容運營效率監測報表(導流內容組對關鍵業務的引導作用)、使用者價值監測報表 (找到核心活躍使用者， 並做為運營化推廣手段的節點)、流失使用者監測報表(找到並預警流失使用者，提前做運營部署)、職位當日保有量報表(基礎資訊業務必須保 持恒定或提高)。

以上關於全域驅動因素、局部驅動因素、體驗資料等都各舉了一例。 大家是否理解呢!本文寫到這裡打算告一段落，剛一朋友電話來了，說7夕已過，房已退。 我想，是時候做我該做的事了...