本文主要是介紹業(yè)務(wù)部門（主要是運營部門）在沒有完善的數(shù)據(jù)平臺時如何更好的提出數(shù)據(jù)需求，來滿足自己某些數(shù)據(jù)分析。

一、誰會提數(shù)據(jù)需求？

一般來說的話，更多的是運營提出的數(shù)據(jù)需求會更多。不過也會存在其他業(yè)務(wù)部門，比如財務(wù)、結(jié)算、市場、技術(shù)部等其他業(yè)務(wù)部門。

二、有哪些數(shù)據(jù)需求？

• 產(chǎn)品數(shù)據(jù)：PV、UV、頁面跳出率、DAU、留存率、事件轉(zhuǎn)化率、用戶屬性等等。
• 業(yè)務(wù)數(shù)據(jù)：注冊數(shù)、下載數(shù)、訂單數(shù)、取消數(shù)、注冊轉(zhuǎn)化率、訂單轉(zhuǎn)化率等等。

三、如何提數(shù)據(jù)需求？

舉個栗子：國慶節(jié)會上線一個新業(yè)務(wù)的推廣活動頁，到時候領(lǐng)導(dǎo)需要看到這個新業(yè)務(wù)上線后的效果情況如何？

時間規(guī)劃

雖然是國慶節(jié)上線，但是作為數(shù)據(jù)需求提出方，需要有時間規(guī)劃的意識。不要等到活動頁上線之后，再去和產(chǎn)品、數(shù)據(jù)小組提相關(guān)的數(shù)據(jù)需求，而是要學(xué)會把需求前置。特別是活動頁的PV、UV等用戶行為數(shù)據(jù)，因為如果在上線前沒有提出需求，開發(fā)一般不會主動埋點統(tǒng)計的，所以等上線后發(fā)現(xiàn)沒有埋點，已經(jīng)為時已晚了。另外業(yè)務(wù)數(shù)據(jù)雖然可以從數(shù)據(jù)庫中提取，但是由于提出需求時間在上線后，留給數(shù)據(jù)小組的處理時間不多，往往會造成領(lǐng)導(dǎo)時時催你要數(shù)據(jù)，你時時催數(shù)據(jù)小組幫忙提取基礎(chǔ)數(shù)據(jù)。

分析維度

上線一個活動頁，作為運營你要知道領(lǐng)導(dǎo)想看上線后的效果，那么效果情況能從哪些數(shù)據(jù)進行呈現(xiàn)。這個過程需要哪些基礎(chǔ)數(shù)據(jù)，如何利用這些基礎(chǔ)數(shù)據(jù)來進行分析。其中最重要的就是基礎(chǔ)數(shù)據(jù)的來源。所以運營前期提數(shù)據(jù)需求時一定要明確基礎(chǔ)數(shù)據(jù)的維度是什么？避免基礎(chǔ)數(shù)據(jù)不是自己想分析的數(shù)據(jù)，以及減少與產(chǎn)品、數(shù)據(jù)小組來回溝通確認的時間成本。

假設(shè)場景：

運營：我需要國慶期間所有的訂單數(shù)據(jù)…

數(shù)據(jù)員：要訂單的哪些數(shù)據(jù)？訂單號、用戶ID、下單時間、預(yù)約取貨時間、預(yù)約還貨時間、訂單狀態(tài)？？

運營：哦哦，我要訂單號、用戶ID、下單時間、預(yù)約取貨時間、預(yù)約還貨時間、訂單金額。

數(shù)據(jù)員：是下單時間在10.1-10.7號之間的訂單數(shù)據(jù)？預(yù)約取貨時間在10.1-10.7號之間的訂單數(shù)據(jù)呢？還是實際取貨時間在10.1-10.7號之間的訂單數(shù)據(jù)？

運營：我要下單時間在10.1-10.7號之間的訂單數(shù)據(jù)。

數(shù)據(jù)員：所有訂單都要嗎？還是只要預(yù)約成功的訂單？

運營：只要預(yù)約成功的訂單。

…….

以上溝通花了半天，這時候數(shù)據(jù)員把訂單號、用戶ID、下單時間、預(yù)約取貨時間、預(yù)約還貨時間、訂單金額這些數(shù)據(jù)給運營了。運營埋頭抓緊分析了，分析的過程中發(fā)現(xiàn)訂單金額明顯偏大，超出日常訂單金額的平均值。

運營：你給我的數(shù)據(jù)，訂單金額怎么那么大？是不是你拉錯了？

數(shù)據(jù)員排查半天。。。

數(shù)據(jù)員：沒有啊，這個就是訂單金額。

運營思考半天。。。

數(shù)據(jù)員：你是不是沒有排除優(yōu)惠金額啊，訂單金額要排除使用的優(yōu)惠金額的。

數(shù)據(jù)員心里一萬個。。。

上述這個場景，可以說是數(shù)據(jù)員還是比較負責的，會去和運營確認所需數(shù)據(jù)是什么。但是耗時較長，處理效率較低。那么如何避免此類情況的出現(xiàn)？需要運營明確基礎(chǔ)數(shù)據(jù)分析維度。

就拿上面這個場景來說的話，需要明確時間維度、訂單維度、所需字段的特殊情況。最好是能夠了解訂單表常用字段，一方面是可以具體告知數(shù)據(jù)員要什么字段，提高處理效率；另一方面便于辨別數(shù)據(jù)員提供的數(shù)據(jù)是否存在異常。如果不了解表結(jié)構(gòu)也沒關(guān)系，但是需要準確告知你要什么類型的數(shù)據(jù)以及相關(guān)特殊情況。

表達目的

提數(shù)據(jù)需求的時候，運營可簡單描述此數(shù)據(jù)需求的目的。比如誰要這個數(shù)據(jù)？為什么需要這些數(shù)據(jù)？這些數(shù)據(jù)用來分析什么內(nèi)容的？

表達目的主要有三個優(yōu)點：

• 需求是否合理，產(chǎn)品、數(shù)據(jù)員作為需求接收方，可以根據(jù)此需求來評估需求是否合理，不合理的情況是可以打回需求的。
• 需求優(yōu)先級，產(chǎn)品、數(shù)據(jù)員接受到的需求很多，如何給你的需求進行排期，取決于你的需求是誰提出的？要分析什么數(shù)據(jù)？能解決什么問題？進行評估需求優(yōu)先級，之后進行排期處理的。
• 需求是否存在優(yōu)化空間，針對運營表達的目的和所需的基礎(chǔ)數(shù)據(jù)之間對比，為了能更好的滿足所表達的目的，基礎(chǔ)數(shù)據(jù)是不是可以有優(yōu)化的空間，便于提供更優(yōu)質(zhì)的基礎(chǔ)數(shù)據(jù)供運營進行分析。

四、總結(jié)

簡單的來看，運營提數(shù)據(jù)需求好比是用戶提產(chǎn)品需求。由于需求是內(nèi)部員工提出，占有一定的主動權(quán)。所以需要明確時間、維度、原因三要素，便于產(chǎn)品、數(shù)據(jù)員高效、準確的完成此數(shù)據(jù)需求。

以上是結(jié)合自己工作整理的，由于是自己公司遇到的相關(guān)問題，所以可能存在一定的局限性。歡迎大家多交流學(xué)習(xí)。

#專欄作家#

董小白，人人都是產(chǎn)品經(jīng)理專欄作家。喜歡研究各類好玩好用的APP，關(guān)注出行、電商等領(lǐng)域；擅長整理和分析APP亮點功能設(shè)計。微信公眾號：小白的產(chǎn)品之路。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。