關于數據日報,它的意義和設計思路都在這里了

1 評論 20351 瀏覽 43 收藏 11 分鐘

越來越覺得“數據日報”應該是每個產品必備的“衍生產品”了,每一位產品經理,都應該清楚的了解怎么設計數據日報。

第一次認識“數據日報”,是在去哪兒就職的時候,當時花了很長時間,也花了很多精力去研究,這也成為我最在意的“衍生產品”之一。

什么是數據日報呢?

電影里,總有那么一些神奇的人,每天早上都會有一段愜意的時間,喝早茶,看日報。如果這份日報里的內容全部都是數據,那些就算是一份“數據日報”了。

最初,數據日報是比較忌諱的產物,不是指定的角色,是沒有查看權限的,并且也絕對禁止外傳,因為我們很容易通過數據去觀察企業運作狀態以及規律。

這會有一個前提,日報里的數據要有意義。

數據日報的意義

我們會認為數據日報是一種過時的產物,畢竟現在有那么多更全面,更豐富的第三方數據統計平臺,我也是非常依賴第三方統計,在我認識“數據日報”之前。

與第三方統計平臺相比,數據日報會有幾個讓人著迷的好處。

他總是比統計平臺,更懂你

主動和被動,是一個持久話題。一個產品在設計的過程中,我們其實一直在平衡主動與被動的關系。

對于統計平臺而言,需要用戶產生主動查找內容的行為,數據日報則是系統主動推送內容,用戶變成了被動接受。

我應該算喜歡“懶惰”的那部分人,這也是我依賴數據日報的原因。

在我有所行動之前,特定的內容應該已經放到了我的郵箱里,就像電影里的人們,每天看看早報一樣,總是在你想要看的時候,就已經被放在郵筒里了。

認識的一位朋友告訴我,他在每個周一早上都會去數據中心看看數據,這已經成了他的習慣了,這讓我感到好奇,偶然的情況下,我體驗了他們的數據中心。

坦白說,這并不是一次很好的體驗,我能想象,每周一他是在多么排斥的情況下,不得不去數據中心查看數據。

太復雜了!

顯然,他這時需要看的是“數據日報”。作為一個分公司的實際負責人,其實只需要關注部分典型數據就可以了,更多的細節數據,只會成為干擾和負擔。

你無法通過三方平臺或者數據中心,實現多個產品線的數據查閱,不是因為功能不支持,是因為我們對信息的過濾及處理能力有限,所以我們要依賴團隊合作。

這就是數據日報存在的意義了。

1.主動將信息送達給我們,通過郵件,或者其他手段;

2.過濾后的信息,能讓這件復雜的事情變得簡單,尤其是多產品線的環境里;

3.自定義的重點突出,會讓我們知道發生了什么事情,直接影響了數據;

福利

這個是某上司公司的部分日報內容,當然信息部分已經被處理了。
截圖7

“生產”與“用戶模型”

數據日報作為產品的“衍生產物”,其本身也應該作為一款獨立的“產品”被對待。

當我向朋友提出建議時,他也說出了他的顧忌,我相信這并不是他一個人的顧忌。

  1. 現在核心數據的規則并不清晰,變動可能性會很大;
  2. 只是內部機制,不要去占用寶貴的研發資源;
  3. 他并不認為數據日報和他現在的行為有什么“區別”;

這是一種慣性思維,是我們互聯網人特有的一種思維模式:“只有研發能夠扮演生產者的角色”。

實際上,數據日報更多的是產品經理或者運營來生產的,整個日報的制作過程中,需要由研發協助完成,每日固定時間導出上一日數據的腳本,且是原始數據。

其實我更喜歡將數據日報交給產品經理完成,畢竟其本身也是一款“產品”。

換言之,我們可以在數據日報里,很好的鍛煉自己的產品能力。比如我們常提到的“用戶需求模型”。

數據日報會有兩類用戶,其一是生產者,其二是閱讀者。

這就像產品的后臺與前端一樣。

生產者是指每天來制作數據日報的角色,有很長一段時間,我們的前臺行政扮演了這個角色,每天會發一份數據日報給公司所有人,這會花費她10分鐘的時間。

數據日報作為產品被生產出來以后,必須考慮到生產者的“易用性”,如果他過于復雜,成為了團隊的負擔,這樣就很難被有效的使用了。

閱讀者是指每天查看這份數據日報的人,可能是Boss,可能是管理,也可能是我們全體成員,這就要求我們在表達層面留意“信息層級”“閱讀體驗”“可擴張性”。
截圖8

數據日報的設計思路

我們已經做了一個簡單的用戶模型,接下來就可以將他產品化了。

這個是我自己使用的一套產品結構。
截圖9

對于生產者而言,我們希望他的操作盡可能簡單,最好是讓不會用excel的同事,都能夠快速的進行操作。

我們設計了三個Excel表,并且盡量不去有任何的“修改”動作,一切依托公式,函數來自動運算完成。

原始數據:

這是我們每天從數據庫中導出的數據,如果有多張表,就會存在多張原始數據表,但他們本質是一樣的。

對于原始數據,我不建議在上面做任何的修改,包括公式和函數的運用,最好只是復制就可以了。

過渡數據:

這是我們的計算中心,大部分的公式、函數、都在這個表里進行計算。

這個表會有多張sheet ,一部分是用于粘貼指定的原始數據,一部分則是輸出運算結果。

結果數據:

這是我們的輸出數據,基本上閱讀者看到的數據是從這個表里產生的,我們可以在這個表里做一些圖形化的處理。

整個設計思路很大程度是圍繞”生產者”展開,只有足夠簡單,我們才能實現低成本的生產,也是高效的。

在這套設計思路里,“生產者”的動作只有“復制”與“粘貼”

案例:

按照這個思路,我們來計算一下昨天的日活數據。

1.導出昨日的“登錄記錄”表,作為我們的原始數據,這張表會記錄用戶昨日所有的登錄時間(會出現重復記錄,一個用戶登錄了多次),

2.將“用戶ID”復制并粘貼到過渡數據指定的列“昨日登錄用戶ID”,得到“昨日登錄的用戶數”(公式自動計算出的結果:統計某一列不重復的數據)。

3.將“昨日登錄的用戶數”復制粘貼到“結果數據表”,得到日活的折線圖(自動生成固定周期的折線圖)。

4.最后,只要將“結果數據表”里的內容,復制到郵件或者截圖到郵件里,就可以發送給所有人了。

文末

如果你目前在初創團隊任職,我建議盡早嘗試接觸數據日報,這會讓你更了解數據,對團隊而言,這也是我們所能產出的一個比較重要的貢獻。

要知道產品初創階段,對于數據非常的依賴,但往往我們只是知道數據很重要,真的要去說出需要哪些數據,往往就不得而知了。

即使你在一個成熟的團隊,我也仍然建議你去研究一下,不論是數據中心或者是三方平臺所能提供給我們的數據都是固化的,缺少靈活性以及特定性。

相信這個技能,會在未來給你很大的幫助。

#專欄作家#

枯葉,微信公眾號,枯葉咖啡館,人人都是產品經理專欄作家。擅長社交,社區,細分群體挖掘。

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

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 厲害了,受益匪淺

    來自江蘇 回復