看到這篇文章——《如何通過統計分析工具做好APP的數據分析和運營》，感覺并沒有深入的講解針對一款App，如何收集數據，如何分析數據。而是從表面，只是見到數據而描述數據罷了。本次為系列文章《App數據分析之旅》，共兩篇：第一篇講解《App數據分析之旅，如何收集數據》；第二篇講解《App數據分析之旅，如何分析數據》。那么，我們就開始App數據分析之旅吧。

為什么要針對App收集數據，想必大家能夠舉出很多理由。大家可以想一下，盡量不要設計到數據后期的分析，不要涉及產品優化，不要設計用戶體驗，更不要設計運營優化，等等。因為，這些都不是理由，而是結果，根據數據分析做出的響應調整。

收集產品數據最基本的，是為了觀察產品各個功能之間，以及產品功能中各個節點的運行狀態。

產品人員除了提出產品相關的MRD（市場需求文檔）、PRD（產品需求文檔）之外，還應該有針對性的提出DRD，即數據需求文檔（Data Requirement Document）。DRD與PRD之間的關系最為密切，因為DRD是隨著產品業務邏輯展開的。

當然，中大型公司會有獨立的數據分析部門，可以由他們來負責提出相應產品的DRD。如果是中小型企業，提出DRD的工作，由產品人員來承擔，也是大有可能的。

那么，我們要怎么收集App的相關數據呢？不要著急，我慢慢給大家分析。

1、了解產品業務邏輯。主要是App的用戶操作流程，主要有：功能之間的邏輯關系，單一功能上的邏輯先后關系。以我的實際工作為例，App登錄（當然，這不是主要的業務邏輯，只是拿來舉例子的）。業務邏輯，梳理的形式和工具很多，有些人喜歡用圖，可以PS；有些人也喜歡用圖，但用的是PPT和連線；有些人喜歡用word，有的會用思維圖。

2、將業務邏輯節點化。App功能之間、單一功能重要節點的梳理，將節點列出優先級，因為有些節點是不重要的，沒有必要對其統計?；蛘吣壳暗臉I務中，有些統計不需要。經過梳理和討論，就得到了第3步中，需要統計的節點、事件以及參數。

3、將節點化的業務代碼化。這一步驟，主要是將列出的重要節點（需要統計的節點）添加統計事件和統計參數。例如：

4、交付開發調整DRD。如果你沒有開發經驗，也不懂開發，那需要多向開發了解請教，那樣你提交的DRD，會相對合理。如果你是開發出身的產品人員，而且又做過這部分工作，和開發溝通起來會很順暢的。（當然，這里還是建議大多非開發出身的產品人員，學一些基本的開發知識，也可以多和產品聊聊開發，也是為了工作嘛）

5、后期數據庫中有了相應節點的統計情況，之后就可以拿來分析了。這一部分，我會在第二篇中具體來講的。

這一年移動相關的工作經驗，顛覆自己之前在PC方面數據分析的認知。原來，數據分析可以是這樣的，而不只是單純一味的描述數據。也希望，這篇文章，能夠對大家有啟發。如果能夠讓大家也有上面和我一樣的感受，真的是很榮幸。

最后，謝謝大家的瀏覽，后續會更新第二篇《App數據分析之旅，如何分析數據》，敬請期待！