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

一、誰會提數據需求？

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

二、有哪些數據需求？

• 產品數據：PV、UV、頁面跳出率、DAU、留存率、事件轉化率、用戶屬性等等。
• 業務數據：注冊數、下載數、訂單數、取消數、注冊轉化率、訂單轉化率等等。

三、如何提數據需求？

舉個栗子：國慶節會上線一個新業務的推廣活動頁，到時候領導需要看到這個新業務上線后的效果情況如何？

時間規劃

雖然是國慶節上線，但是作為數據需求提出方，需要有時間規劃的意識。不要等到活動頁上線之后，再去和產品、數據小組提相關的數據需求，而是要學會把需求前置。特別是活動頁的PV、UV等用戶行為數據，因為如果在上線前沒有提出需求，開發一般不會主動埋點統計的，所以等上線后發現沒有埋點，已經為時已晚了。另外業務數據雖然可以從數據庫中提取，但是由于提出需求時間在上線后，留給數據小組的處理時間不多，往往會造成領導時時催你要數據，你時時催數據小組幫忙提取基礎數據。

分析維度

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

假設場景：

運營：我需要國慶期間所有的訂單數據…

數據員：要訂單的哪些數據？訂單號、用戶ID、下單時間、預約取貨時間、預約還貨時間、訂單狀態？？

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

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

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

數據員：所有訂單都要嗎？還是只要預約成功的訂單？

運營：只要預約成功的訂單。

…….

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

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

數據員排查半天。。。

數據員：沒有啊，這個就是訂單金額。

運營思考半天。。。

數據員：你是不是沒有排除優惠金額啊，訂單金額要排除使用的優惠金額的。

數據員心里一萬個。。。

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

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

表達目的

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

表達目的主要有三個優點：

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

四、總結

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

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

#專欄作家#

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

本文原創發布于人人都是產品經理。未經許可，禁止轉載。