網站分析報告101：計畫、實施策略和Dashboard

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

【前言】很多朋友都在問如何撰寫網站分析報告的問題，但這個話題是一個我下了很多次決心都沒有寫的話題。 大家看完了這篇文章就知道我為什麼這麼說了。

【正文】

在美國網站分析人才最集中的地方呆了近一個星期，曾經耳聞現在目睹了他們的工作，必須感歎他們在這個領域的領先。 一方面，是技術水準的確強大;另一方面則是專業性無可挑剔。 憑著一腔熱愛做事情、相當不錯的收入，以及業界的認可和需求地不斷壯大，讓這個產業在美國越來越欣欣向榮。 等結束了這次美國之旅，我將撰文談談澳洲和美國網站分析的見聞。

不過，這個話題不是國外，而是解決我自己同樣長期縈懷的一個問題——如何做出漂亮的網站分析報告?這個話題是一個不小的挑戰，光我一個人不夠，需要在這個文章之後，得到大家的提問、回饋、建議和經驗。 我不准備，也不可能在一個文章中把網站分析報告的所有問題都說清楚，還是開一個系列吧!

首先，我要說，如何製作網站分析報告不是一個問題，而是多個問題的集合，為什麼這麼說呢?因為網站分析報告是一系列不同報告的總稱。 我們先從這個話題入手。

由於側重點不同，閱讀報告的使用者也不同，因此網站分析報告絕對沒有一個標準。 雖然都叫報告，但是內容和格式可以大相徑庭!我所知道的網站分析報告包括下面的一些類型：監測和分析計畫報告、實施策略報告、Dashboard(精要報告)、Kick off(啟動)報告、痛點辨識報告、分析和優化報告、優化實施報告 、測試報告。 限於篇幅，今天講前三個。

監測和分析計畫報告

監測和分析計畫報告和實施策略報告的區別是，後者強調實施，而前者監測強調分析計畫。

監測和分析計畫報告，即我在以前Agency的工作中常常要做的Measurement and analytics plan，或者簡稱M&A Plan，是關於一切監測和分析行動的指導。

各位網站分析愛好者朋友，大家可能毫無關于監測和分析計畫報告的概念，也可能完全不認為它是重要的。 恩，的確，某種程度上，即使我們沒有它，老闆佈置下來的分析工作照樣還是要做的，不過有這個計畫的意義實際上很重要，因為它不僅僅是一個行動綱領也是一個契約。

下面我列出了這個報告的內容後，您就能明白我為什麼這麼說。

監測和分析計畫報告的具體內容包括：

網站分析的物件、範圍和時間

網站分析的物件當然是網站，但是，是網站的全部，還是局部(比如某個頻道，或者網站的外部流量源等)?如果是局部，範圍是多大?需要採集多長時間的資料?

網站的關鍵業務需求(KBR：Key Business Requirements)

KBR是Omniture方法論常常提及的一個詞，它代表的是網站在商業上要達到的目標及關鍵環節，是網站分析需要最終實現優化的落腳點，或者換句話說，是網站分析的意義，如果沒有KBR，也就不需要網站分析了。

還有什麼比KBR更重要的?

KBR目標設定

並不是每個網站分析都有設定KBR目標，因為KBR可能受很多因素的影響。 不過KBR目標的設定，能夠讓網站分析有一個明確的努力方向。 KBR目標設定並不複雜，因為業務目標往往都是清晰的。 例如，網站管道帶來的Revenue在半年內增長30%;或者網站平均每個月使用者提交review的數量增加5%等。 這些都是一些純業務領域的目標。

可能用到的分析方法或者模型(可選)

網站分析很多時候並不可能在事前預見到會用到何種分析方法或者模型來解決問題。 這就如同我們去釣魚之前去找蟲子當誘餌，我們面前有很多石頭，掀開一個個石頭，有的下面有一個肥美的蚯蚓，有的下面有一群四散奔逃的螞蟻，有的下面什麼也沒有。 不過我們還是可以從大處著手，考慮我們可能用到的分析方法或者模型，比如，我們要研究轉化、我們要從流量變化中發現促進流量的因素等。 這個部分，有時候只是作為參考項，可選。

圖：一個方法和策略的例子。 是由Florian Pihs先生創立的

人員和資源配置

讓馬兒跑不讓馬兒吃草可不行。 人員和資源配置當然是很重要的。 這是這個報告契約功能的另一個體現。 不多說了。

進度計畫

網站分析要按照大致什麼樣的計畫進行?例如，什麼時候完成監測實施，什麼時候分析，什麼時候提出建議，什麼時候進行測試，最後又如何進行網站的優化等。 之後，儘量按照這個計畫進行。 這樣大家心裡都有數，能夠更好地步調一致的協同工作。

圖：進度計畫的簡單例子

實施策略報告

有了網站分析計畫後，第一個重要的具體操作就是實施了。 實施策略報告是在網站分析實施之前需要進行的。 這個部分是網站分析最重要卻最容易被忽視的領域。 那些所謂添加代碼的工作，如同蓋房子的添磚加瓦。 可是添磚加瓦要在一個藍圖的指導下進行，沒見過蓋房子不畫圖紙的，同樣也沒見過網站分析加代碼不考慮監測策略的。

在我們最開始接觸網站分析的時候，我們使用的是Google Analytics，我們的實施比較很簡單粗暴，就是把GA的代碼加到每個頁面上就行了，但隨著時日的增加，監測的需求開始變得細化，例如要監測一些頁面上的event( flash或者javascript等)，以及要監測業務上的一些指標，比如訂單、購買、收入金額等，簡單粗暴就力不從心了。 監測策略是網站分析大廈的地基，沒這個地基，上面的建築物容易崩塌。

請記住，網站分析是商業分析，由於商業本身都是獨一無二(unique)的，因此網站分析的監測策略和實施也肯定是獨一無二的。

實施策略報告內容包括下面幾個方面：

KBR和網站KPI及監測物件的映射(KBR Mapping)

這個內容是我們俗話說的「翻譯」，就是把KBR翻譯成網站上的KPI指標，以及其他的監測物件。 網站分析並不是監測的越多越好，也不是獲得的資料越多越好，而在於得到我們滿足KBR所需要的資料。

囉嗦一句解釋一下我這個觀點。 理論上，網站分析當然是什麼都監測到是最好，甚至把log file的資料都統統羅列下來，但是，實際上，我非常反對這麼做，時間和精力是有限的，沒有分析能做到100%全面覆蓋。 而且，網站分析的收穫符合20-80法則，即80%的insight來自于20%的分析物件。

關於KBR的映射或翻譯的具體內容，請看這個文章：Avinash：什麼是目標、度量、KPI、維度和細分。

圖：KPI列舉。 是有Florian Pihs先生創立的

KPI及監測物件的實施策略映射(Implementation Strategy)

確定了KPI及監測物件後，就要考慮通過什麼樣的技術策略來監測它們了。 我這幾天正在學習這個領域，非常有意思，有不少收穫。 例如，我的老師常常問我們，如果要監測一個商品的SKU及對應的州、Zip號碼、shipping花費，以及收入等等時，應該應用什麼function、plugin、event和evar(見下)，我們要能夠對答如流。 這些即KPI和監測物件在監測技術策略上的映射。

1 Track multiple item orders by product SKU

2 Include State and Zip information on purchase page

3 Track shipping cost per product

4 Include cost of goods (cog) per product during purchase so that a calculated metric can be built for margins (cog amount pulled from in-house product database)

請注意，實施策略不是實際的coding，而是為最終的coding確定策略。

監測實施方法*

監測實施方法好比一個說明書，在Omniture被稱為Playbook(注意不是playboy)，詳細說明了運用哪些function、plugin、s.prop、event、evar等。 拿著這個說明書，IT工作人員(例如網站前端工程師)就能夠按圖索驥的添加代碼了。

監測實施方法被加了星號的原因是，往往它會被單獨拿出來作為一個獨立的文檔。

這個報告的內容說完了，是不是大家沒想到，連監測策略都要有一個這麼複雜的報告?不奇怪，科學需要嚴謹嘛。

圖：實施策略報告的流程

Dashboard(精要報告)

Dashboard這種報告絕對值得大書特書。 這個報告體現了網站分析的藝術之美。 不過，既然是藝術，就不要把它只當技術對待。

Dashboard不太好翻譯，儀錶盤?或者是總控台?總之，容易讓你我迷糊。 我還是覺得Dashboard被稱為精要報告比較好，或者被稱為KPI報告。 當然，叫什麼名字並沒有關係，關鍵是對這種報告的理解。

在解釋Dashboard之前，大家先設想自己在開汽車，汽車的儀表板表明了汽車行駛狀態的最關鍵的一些特徵——速度、行駛里程、油量。 網站分析的Dashboard報告跟汽車的儀表板一樣，表明了網站最關鍵的運行狀態。

除了汽車和網站分析之外，其實只要是需要瞭解運行狀態的行業都可以有dashboard，大到經濟運行景氣情況，小到您家的電錶水錶。 如果您看看這個網站Dashboardspy，就知道我為什麼說dashboard是一門藝術了。

圖：這是一個博物館的Dashboard，做的很棒!

沒錯，Dashboard是讓你在最短的時間內瞭解網站最宏觀最關鍵運行狀態的報告。 這個報告是給所有人看的，尤其是給你的老闆看的，我認為它是被最多閱讀也最常閱讀的報告。 從這個意義上講，Dashboard是網站分析最重要的報告。

Dashboard報告具有如下幾個特徵：

精要

Dashboard一般只會把KPI和關鍵監測物件的運行資料放入報告中。 無微不至、事無巨細不是Dashboard的特點。

除了在資料上體現在精要，Dashboard中其實也有精要的定性內容，這些內容即是簡短有力的結論性文字和建議性文字，而絕對不會有分析性文字。 Dashboard的文字只有一個要求——擲地有聲!

精要的目的很明確，就是要讓閱讀者快速、清晰地瞭解網站狀態，哪兒好，哪兒壞。

宏觀

Dashboard一般只體現網站(或者網站Channel)的宏觀資料，而不會涉及到某個具體頁面的情況。

動態

Dashboard是動態的，隨著時間變化能夠隨之更新。 因為Dashboard要描述狀態，如果不能更新，意義就失去了。 很多網站分析工具提供自動化的Dashboard的功能，這些Dashboard可以即時描述網站狀態。 例如，Omniture SiteCatalyst的Dashboard能夠自動按照訪問報告的時間提供即時網站狀態資料，也可以按照你自訂的時間區隔描述網站狀態，很靈活。

圖：Omniture SiteCatalyst的自訂動態Dashboard

如何做一個網站分析的Dashboard?敬請遵循下面的步驟：

確定放入Dashboard中的KPI和其他關鍵監測物件;

為這些KPI和指標確定合適的表達度量;

為各個表達度量設計合適的時間範圍和圖表;

製作圖表，或通過自動化工具將圖表和度量關聯;

填入定性文字。

我其實有一個非常高品質的文章關於如何製作Dashboard，是Avinash Kaushik先生寫的。 請大家點擊這裡：「可執行檔網站分析報告精要」——跟糟糕的簡要報告說再見吧!

最後，告訴大家一個詞，reportlet，就是Dashboard中一個個的資料社區塊。

好了，先介紹到這裡。 如果大家覺得有意義，我會繼續寫其他類型的報告。 如果有任何問題和建議，也請告訴我。 特別鳴謝Janny同學之前給我發信提出的一些問題，我之後也會寫你所建議的相關文章。 最後，老規矩，跟大家分享下我在美國的一些圖片。

圖：這就是Orem(以及挨在一起的Provo)，Omniture總部所在的城市。 在美國，這個超過10萬人的(兩個)城市已經是很大的了。 這裡地廣人稀資源多，沒有高樓，反而說明足夠富裕。 遠處是淡水的猶他湖

圖：Omniture的美國諮詢顧問，能聽說讀寫流利中文的Thayne Lewis先生，他竟然可以跟我討論inception這個詞翻譯成「開始」好，還是翻譯成「源頭」好，太強了!背景是Bingham Canyon Mine礦車的輪胎

圖：在世界最大的人造坑Bingham Canyon Mine

圖：在摩爾門教總部Temple前，手裡拿著摩爾門教的經書——摩爾門經

圖：鹽湖城的Apple店門口

[版權歸Sidney Song(宋星)所有，歡迎轉載，但請事先告知作者並注明出處]

        原文位址：HTTP://www.chinawebanalytics.cn/wa-report-101-1/