為什么進行網(wǎng)絡營銷中提出產(chǎn)品數(shù)據(jù)需求
產(chǎn)品指標體系的建立不是一蹴而就的，運營人員需要根據(jù)產(chǎn)品所處的發(fā)展階段，有所側重地進行數(shù)據(jù)需求的提煉。為方便產(chǎn)品和數(shù)據(jù)上報開發(fā)、數(shù)據(jù)平臺等部門同事之間溝通，大多數(shù)公司都會有產(chǎn)品需求文檔模板，以輔助進行數(shù)據(jù)建設。目前，大多數(shù)創(chuàng)業(yè)型中小企業(yè)，產(chǎn)品數(shù)據(jù)的需求提煉到上報或許就是1~2人的事情，但同樣建議做好數(shù)據(jù)文檔的建設，如數(shù)據(jù)指標的定義、數(shù)據(jù)計算邏輯等。
IJYY語音為例，表7-5所列是YY語音的客戶端團隊建立的基礎產(chǎn)品組需求實現(xiàn)流程。
上報數(shù)據(jù)
這個步驟是根據(jù)產(chǎn)品經(jīng)理提出的數(shù)據(jù)需求，按照上報規(guī)范，將數(shù)據(jù)上報到務器的過程。上報數(shù)據(jù)的關鍵是數(shù)據(jù)上報通道的建設，只要上報通道足夠通暢這個環(huán)節(jié)的工作就非常簡單，因為數(shù)據(jù)平臺可以代勞很多細節(jié)性的工作，運營員只需要按照規(guī)定的步驟，使用統(tǒng)一的數(shù)據(jù)SDK進行數(shù)據(jù)上報就可以了。
然而，如果是在一家初創(chuàng)公司，或者不太完善的公司，則需要從上報通道設開始做起。其中一個很關鍵的環(huán)節(jié)就是數(shù)據(jù)上報測試，該環(huán)節(jié)做不到位，會成不必要的麻煩。
如果公司沒有足夠的技術和資金來搭建自己的數(shù)據(jù)平臺，也可以借助第三：數(shù)據(jù)平臺。常用的有網(wǎng)頁產(chǎn)品類，如百度指數(shù)、360大數(shù)據(jù)平臺、艾瑞指數(shù)、鞫指數(shù)；電商平臺類，如阿里指數(shù)、淘寶指數(shù)；移動端產(chǎn)品類，如友盟、微信指轂、Talking Data等。
數(shù)據(jù)采集
j 數(shù)據(jù)上報完，并得以確認之后，接下來就是一個偏技術化環(huán)節(jié)，即數(shù)據(jù)采集。由于專業(yè)性較強，這一步通常由數(shù)據(jù)分析師等專業(yè)人士完成。
數(shù)據(jù)采集是獲取高質量數(shù)據(jù)的主要方式，是數(shù)據(jù)分析的基礎，直接決定數(shù)據(jù)分析的結果。那么，如何做好數(shù)據(jù)采集工作呢？我們不妨先看一張圖，即產(chǎn)品數(shù)據(jù)體系中最常見的數(shù)據(jù)采集流程， 數(shù)據(jù)采集通常分為兩步。
第一步，從業(yè)務系統(tǒng)上報到服務器，這部分主要是通過巡航導航指示器或者后臺服務器，通過統(tǒng)一記錄API調用之后，匯總在日志服務器中進行原始流水數(shù)據(jù)的存儲。當這部分數(shù)據(jù)積累到一定量之后，需要考慮用分布式的文件存儲來做，外部常用的分布式文件存儲主要是HDFS。
HDFS是一個高度容錯性的系統(tǒng)，它放寬(relax)了POSIX的要求(requirements)，這樣可以實現(xiàn)流的形式訪問( streaming access)文件系統(tǒng)中的數(shù)據(jù)。HDFS有著高容錯性( fault-tolerant)的特點，并且設計用來部署在低廉(low-cost)的硬件上。它提供高吞吐量（high throughput）來訪問應用程序的數(shù)據(jù)，適合那些有著超大數(shù)據(jù)集( large data set)的應用程序。
第二步即進人數(shù)據(jù)的抽取和轉換環(huán)節(jié)。ETL是英文Extract-Transform-縮寫，用來描述將數(shù)據(jù)從來源端經(jīng)過抽取、轉換、加載至目的端的過程。
詞較常用在數(shù)據(jù)倉庫，但其對象并不限于數(shù)據(jù)倉庫。
ETL是構建數(shù)據(jù)倉庫的重要一環(huán)，用戶從數(shù)據(jù)源抽取出所需的數(shù)據(jù)，據(jù)分析，最終按照預先定義好的數(shù)據(jù)倉庫模型，將數(shù)據(jù)加載到數(shù)據(jù)倉庫畸
數(shù)據(jù)存儲
對數(shù)據(jù)進行采集之后就需要將其存儲起來，以便后期使用時集中整理析。數(shù)據(jù)大多存儲在專門的數(shù)據(jù)倉庫中，存儲的數(shù)據(jù)越多、越完善，標志著司對大數(shù)據(jù)運用得越好、越徹底。
成熟的互聯(lián)網(wǎng)企業(yè)大多都有自己的數(shù)據(jù)倉庫，這也是衡量其是否實現(xiàn)數(shù)運營，或對大數(shù)據(jù)運營能力大小的重要標志。
(1)接入層
數(shù)據(jù)接入層會將收集到的各種數(shù)據(jù)統(tǒng)一成一種內(nèi)部的數(shù)據(jù)協(xié)議，方便后續(xù)數(shù)據(jù)處理系統(tǒng)使用。接人層支持各種格式的業(yè)務數(shù)據(jù)和數(shù)據(jù)源，包括不同的DB、文件格式、消息數(shù)據(jù)等。
(2)處理層
處理層，是指用插件化的形式來支持多種形式的數(shù)據(jù)預處理的一個過程。對于離線系統(tǒng)來說，一個重要的功能是需要按照某些維度（比如某個key值+時間等維度），將實時采集到的數(shù)據(jù)進行分類存儲。同時，存儲文件的粒度（大小／時間）也是需要定制的，使離線系統(tǒng)能以指定的粒度來進行離線計算。
(3)存儲層
處理后的數(shù)據(jù)使用HDFS作為離線文件的存儲載體。保證數(shù)據(jù)存儲整體上是可靠的，然后最終把這部分處理后的數(shù)據(jù)，入庫到騰訊內(nèi)部的分布式數(shù)據(jù)倉庫( TDW)。
數(shù)據(jù)接入
大量數(shù)據(jù)為什么要接入，主要基于兩個原因。第一是由大數(shù)據(jù)的多樣性造成的。大數(shù)據(jù)的多樣性使得原有的單一通道不適用，這就需要針對數(shù)據(jù)的類型如結構化數(shù)據(jù)、半結構化數(shù)據(jù)、非結構數(shù)據(jù)，以及數(shù)據(jù)源的存儲形式如關系數(shù)據(jù)庫、分布式數(shù)據(jù)庫兩方面特性進行綜合考慮，形成一個二維接人方式表。大數(shù)據(jù)的多樣性表明，我們在接人數(shù)據(jù)的時候必然會采用多樣化的接人手段。第二是由大數(shù)據(jù)的高速性造成的，這一特性使數(shù)據(jù)通道更為擁堵。
針對大數(shù)據(jù)的這些特點，流處理的技術發(fā)揮了重要作用。當然實際情況要更加復雜，在這里我們只是提出其中的一種解決問題的思路。
對此，可以依靠消息隊列集群加流處理技術進行解決。例如，現(xiàn)在廣泛采用的kafka+spark streaming的解決方案。數(shù)據(jù)通過消息的不同通道和訂閱發(fā)布機制，建立不同的數(shù)據(jù)傳輸通道，并且通過分布式機制和緩存機制解決大量數(shù)據(jù)接人的性能問題。一些軟件或APP中提供的采集助手就是要讓不懂技術的人員也能接人各種類型的數(shù)據(jù)。
從實際應用來看，產(chǎn)品在考慮數(shù)據(jù)接人的時候，主要關心3個問如下。
【1)多個數(shù)據(jù)源的統(tǒng)一
一般實際的應用過程中，都存在不同的數(shù)據(jù)格式來源，這個時候，采冀入這部分，需要把這些數(shù)據(jù)源進行統(tǒng)一的轉化。
（2J注意時效性
要注意采集的實時高效，由于大部分系統(tǒng)都是在線系統(tǒng)，對于數(shù)據(jù) 效性要求會比較高。
(3)對無效數(shù)據(jù)進行處理
對于一些會影響整個分析統(tǒng)計的無效數(shù)據(jù)，需要在接入層的時候進行邏輯蔽，避免后面統(tǒng)計分析和應用的時候，因這部分數(shù)據(jù)導致很多不可預知的問題。
