UV、DAU、DLU、ARPU……對于産品經理而言，做産品時，五花八門的數據指标信手拈來，似乎可以分分鐘搞定“數據化運營”

如果你真的這樣想，那一定是對“數據化運營”有誤解。下面這5個問題，可檢驗你對數據的理解程度。

一、産品中的“用戶”是如何定義的？

“用戶”是産品的基礎資源，那麼，關于用戶，你需要清楚地知道哪些内容呢？

• 你的産品中有哪些類型的用戶？(分類方式你可以自己指定，如按照付費用戶、免費用戶、遊客來分類)
• 上述各類用戶在使用你的産品時，是否必須登錄？
• “用戶數”是按什麼信息統計得到的？(按帳号、綁定手機号、設備ID？未登錄的用戶又是怎樣統計的？)
• 産品中的“用戶數”是否存在“水分”？(如一個人注冊多個帳号的情況)
• 你的産品中又有多少自然人？

現在，你有沒有感覺到，“用戶”實際上并不是産品中的一個簡單的概念？

對于“用戶”在現實世界中的定義非常明确——通過電腦、手機等設備使用産品的活生生的人(或稱自然人)。而在數據中，“用戶”的定義就成了一個既重要又嚴肅的問題。

在大多數場景中，用戶通常是通過某個數據維度來标識的，例如：

• 産品帳号：适用于大多數需要注冊登錄的産品(如微信、支付寶)，用戶在産品上完成注冊會生成一個帳号，以一個帳号代表一個用戶。
• 第三方認證帳号：也稱快捷登錄帳号。與産品帳号類似，隻不過帳号不由我們自己的産品維護，而是由可信的第三方平台提供。如産品允許用戶使用自己的微信、QQ、微博、支付寶等進行登錄，登錄時會指引用戶轉向微信等平台授權。以每個第三方平台反饋的标識代表一個用戶。
• 手機号：對于隻能通過手機号注冊或者必須綁定手機号的産品可以手機号定義用戶，即一個手機号代表一個用戶。
• 設備号：用于手機App，用可以标識手機設備唯一性的編号(如IMEI)定義用戶，一個設備号代表一個用戶。
• IP地址：即聯網的電腦或移動設備的網絡協議地址，多用于不需要注冊和登錄的網站對獨立用戶的判定(這時也稱用戶為獨立IP)，用一個IP地址代表一個用戶。
• 身份證号：對于收集用戶身份證号合理合法的産品可以用身份證号定義用戶，但這隻針對中國居民的用戶群體，一個身份證号代表一個用戶。

你的産品是怎樣定義用戶的呢？

實際上，以上對用戶的定義方式各有其局限性，且精确度各不相同。然而，它們處理起來相對容易且高效，因此在産品中被普遍用作用戶的數據定義。

當然，正如每個人可能會有多個手機号一樣，一個用戶也可能會在同一款産品中注冊多個帳号。如果我們需要了解産品用戶究竟覆蓋了多少自然人，應當怎樣做呢？

這裡留給你來思考。

二、DAU中的“活躍”究竟是什麼含義？

從上一個問題推進一步，我們再來看看DAU中的“活躍”又是什麼含義。

在你的産品中，用戶要在一天内完成哪些操作，才能算作“活躍”呢？莫非，隻要一天當中登錄一次，就算活躍？

實際上，除非你的産品交互非常簡單，否則将活躍等同于登錄是很有水分的——它可以被用來做宣傳，但産品經理絕不應如此認知，否則無異于自我欺騙。況且，将日活躍定義為日登錄，還會面臨一個陷阱：如果一個用戶連續多天從未下線(也意味着她/他在這些天内從未有過“登錄”的操作)，那這個用戶還算不算活躍用戶呢？

不同的産品，用戶“活躍”的含義也往往是不同的，比如：

• 像微信、QQ這樣的社交産品，要求用戶在一天内要有一定數量的主動交互行為才算作活躍用戶，主動交互如發消息、發朋友圈、點贊、支付、建群等；
• 而對于一款在線音樂或在線視頻産品而言，活躍用戶至少應被認為是主動打開并播放了音樂或視頻的用戶；
• 如果是功能綜合性較高的産品(如支付寶)，則用戶活躍的途徑會更加多元化；
• 當然，正如我們剛剛提到的，如果一款産品的交互非常單一(比如隻提供查詢天氣預報、股市行情等信息的工具産品)，把“活躍用戶”等同于“登錄用戶”或“打開用戶”，也無可非議。

那麼，你的産品是怎樣定義用戶“活躍”的呢？

三、數據産品經理就是數據分析師 産品經理嗎？

也許你遇到過這樣的場景，當有人向你提“數據産品經理”這個概念時，你會問“你是指的數據分析師嗎？”或者“這個是不是産品運營裡的一個角色？”。

而你的團隊中可能也确實存在數據分析師、數據挖掘工程師這樣的專職角色。

簡單地理解：

一方面，數據産品經理(DPM)之于數據分析師(DA)，相當于基礎産品經理之于開發工程師；另一方面，如果DPM是數據産品的締造者，那麼DA很可能是這款數據産品的用戶群體之一。

對于國内幾家知名互聯網企業而言，DPM屬于産品類崗位，而DA屬于研發類崗位。由于DPM需要一定的專業技能，所以DA轉為DPM的情況也很常見。

DPM與DA有一部分重合技能，但前者注重于對數據方案和産品整體的把握，而後者注重于數據的挖掘、分析、提煉的專業探究。

在互聯網大大小小企業紛紛進行大數據戰略布局的當下，數據也被以産品化的形态運作，這就有了DPM以及專注于數據的其他各種角色。

下表在定位和職責上對比了DPM與DA：

所以說，數據産品經理≠數據分析師 産品經理，但是數據分析師和基礎産品經理在進行一定的修煉後，可以承擔數據産品經理的工作。

讨論到這裡，我們還可以引出一個問題：既然數據産品經理可以由基礎産品經理或數據分析師轉過來，那直接讓團隊中原有的成員兼任數據産品經理不就可以了嗎？——這種思想其實無益于産品的發展壯大。

關于數據産品經理的必要性，我在《DPM認知修煉4：為什麼需要數據産品經理》一文中總結了4點：

1. 以數據驅動産品的專職角色
2. 打造和經營專業的數據産品
3. 産品團隊與數據團隊的紐帶
4. 填補數據工作的職責盲區

四、數據庫 vs 數據倉庫

從字面上看，數據倉庫(Data Warehouse，簡稱DW)和數據庫(Database，簡稱DB)都是用來集中存放數據的場所，而DW似乎又能比DB容納更多的數據。

——這樣顧名思義并沒有問題，隻不過無法幫助我們進一步理解二者的異同。

實際上，二者在數據應用中的作用差異非常大，不能相互代替：

面向的業務場景不同：DW面向數據分析處理，而DB則面向事務處理。例如一款社交App，它會使用DB來存取用戶的帳号信息、設置參數、關系鍊等信息，為服務器提供用戶身份驗證、設置解析、好友互動等業務邏輯的數據事務處理；而用戶在App中表現的各種行為數據，則會通過數據産品存儲到DW中，以支撐日後對用戶行為數據分析的需求。

優化的操作不同：由于面向業務場景的不同，DW需要集中系統資源優化數據的獲取，以應對大量數據被頻繁調取、分析和處理的需要；DB則需要為數據的訪問、存儲、删除、更新進行全方位優化，以滿足頻繁的數據更新和事務處理對速度和效率的要求。

數據的組織方式不同：DW中通常以時間的分區來組織數據，如按小時分區、按天分區、按周分區；而DB通常以數據的索引和實體的關系組織數據。這主要也是為了契合不同的業務場景——數據分析通常要以一個時間粒度為單位進行統計和分析，而事務處理則需要遵循ACID原則(不明白？看下文)并維護DB中各數據實體的關系。

數據冗餘性不同：如果你學習過DB相關的知識，那麼一定對關系數據模型的範式(如第一範式、第二範式、第三範式、BC範式)不陌生，範式的作用就是在保證數據關系的前提下盡量減少數據的冗餘，這也是DB實踐中對數據的低冗餘要求。

而DW不但沒有強調數據的關系性，反而接受高冗餘的數據，以豐富數據的維度，從而提升數據分析的效率。

此外，數據冗餘性的差異也約束了DB往往隻保留最新、最有效的數據，而DW則要保留曆史上所有的數據。

例如:用戶資料中的職業和收入水平會随時間的推移改變，當用戶更改自己的職業和收入水平後，DB隻需保留更改後的信息、抛棄更改前的信息；而DW則要完整保留用戶每一次變更前後的信息，并記錄變更的時間點。

對于數據産品而言，數據接入層和數據處理層會更頻繁地與DW打交道，并且DW通常也是數據接入層和數據處理層的數據通訊渠道；而處于數據應用層的産品與用戶産品相似，通常使用DB來維持産品的數據存取和事務處理。

注：ACID原則即DB管理系統中的事務所要遵循的四個特性：原子性(Atomicity)、一緻性(Consistency)、隔離性(Isolation)、持久性(Durability)。原子性是指一個事務是不可再分的，必須作為一個整體完整執行。

一緻性是指無論事務執行結果如何，執行前後的數據約束規則應保持一緻，不能被打破。隔離性是指兩個及以上的事務并發執行時不能相互影響。持久性是指事務一旦執行完成，其對數據的影響就要在DB中生效，不能撤銷。

五、數據規模不夠大，無法用來叠代産品？

如果你在運營産品的過程中經常接觸AARRR模型、用戶畫像、A/B Test等“大數據”的概念，或許會認為：

“我們看到的數據整合自全體用戶，統計和分析的是産品的宏觀現象”

“隻有形成規模的數據，才有利用的價值；隻有大多數用戶表現出來的特征，才能通過數據觀察到”

——實際上，這是對數據的一種誤解

通讀《産品經理數據修煉30問》一書，我們知道，數據其實是用戶行為的客觀産物，不僅能夠支撐産品運營中對宏觀問題的解決，同樣可以用來捕捉用戶的情感，感知細小的用戶需求。

——這就是所謂的“小數據”思路。

通過這種思路将産品中的細節做到位，用戶就會感到“用着爽”。

——這往往會成為産品在衆多競品中鶴立雞群的法寶。

請看下文的案例：

相信你對下面這種注冊/登錄交互不陌生：

圖1 手機号快捷登錄交互(優化前)

用戶隻需要填入手機号接收驗證碼、填入驗證碼這樣兩步即可完成登錄。

另一方面，如果填入的手機号是首次登錄，這個過程還會幫用戶完成注冊——這樣一來，無論是新用戶還是老用戶，在産品登錄上的體驗是一緻的。

然而，看似流行且方便的交互，我們依然要懷疑一下：用戶真的沒有困擾嗎？用戶真的能夠順利地完成注冊和登錄嗎？

于是我們提取了登錄模塊的數據，并按新用戶與老用戶分别統計，得到下表：

表1 登錄模塊相關數據(優化前)

注：

1. 若最終登錄的手機号為首次登錄，則認定為新用戶，否則認定為老用戶；
2. 登錄注銷是指登錄成功後，在同一會話超時前又主動注銷了登錄，表現為更換帳号的傾向

上表的數據能給我們什麼啟發呢？

首先，新用戶在第一步頁面的平均停留時長比老用戶多90.7%，也許是新用戶操作不熟練的緣故，但是從第二步頁面的平均停留時長看，操作不熟練似乎并沒有使新用戶比老用戶多花費多少時間。

因此，懷疑第一步的頁面存在困擾新用戶的因素。

其次，新用戶的登錄注銷率是老用戶的近三倍！這個似乎有些誇張——是什麼原因讓新用戶登錄後不久又主動注銷了登錄？是要更換登錄帳号嗎？

針對第一個問題，招募新用戶開展可用性測試後，鎖定了主要原因：第一步頁面引導用戶使用手機号登錄，沒有任何注冊說明，而新用戶習慣性認為登錄前要先注冊。于是他們試圖在頁面中尋找注冊入口，直到找遍整個頁面無果後，才抱着試試看的心态在登錄引導中填寫了手機号，這才發現原來産品不需要額外注冊。

注：實際上，在尋找注冊入口無果後，選擇試試看的用戶約隻占受挫新用戶的一半，還有一半會選擇放棄使用産品，這會為産品拉新帶來不小的損失。

至于第二個問題，我們将新用戶登錄注銷的數據提取出來進一步分析，看看這些新用戶在注銷登錄後又做了什麼，得到下圖所示的結果：

圖2 局部數據再分解：新用戶登錄注銷後的操作

注意到：注銷登錄的“新用戶”轉而用舊帳号再次登錄的比例明顯高于其他情形，說明這部分用戶實際上應當是老用戶，隻是登錄時驗證了新的手機号，導緻被認作新用戶。他們為什麼要這樣做呢？

通過用戶回訪了解到：這些用戶擁有至少兩個常用手機号(得益于雙卡雙待手機)，他們使用其中一個手機号完成首次注冊；經過較長時間後重新登錄，由于忘記之前登錄的是哪個手機号，于是概率性地嘗試用另外一個手機号登錄；登錄後才發現不是他們原本的帳号，這就有了注銷登錄、再次以老用戶身份登錄的操作。

結合上述研究，登錄與注冊頁面調整如下：

圖3 手機号快捷登錄交互(優化後)

在第一步中對新用戶注冊進行引導；在第二步中明示用戶當前驗證的手機是否首次登錄，若不是用戶想要登錄的帳号，可返回第一步頁面重新填寫手機号。

調整後的版本發布一段時間後，再次提取相關數據，可以看到情況發生了明顯改善。

表2 登錄模塊相關數據(優化後)

在上述案例中，我們多次通過數據對用戶個體行為進行捕捉和分析，這是小數據思維的一種體現。

對于産品經理而言，小數據思維與大數據思維同等重要，甚至在用戶需求和痛點挖掘上，運用小數據洞察會更具優勢。

小結

怎麼樣？這5個問題你還回答得順利嗎？

實際上，這些都是做産品所必備的基礎素養。

也許你會問，“數據那麼深奧，我又不是專業的數據分析師，應當對數據了解到什麼程度、掌握哪些技能、花費多長時間，才可以成為一名有着出色數據敏感力的産品經理呢？”

——要我說，其實隻要圍繞産品數據、數據産品、數據運營、數據技能修煉30個問題，每日1問，即可在一個月左右的時間裡輕松掌握那些深奧的“數據事”，甚至還可向數據産品經理進階。這30個問題我已在《産品經理數據修煉30問》一書中為你進行了全面彙編。

今天，人人都是産品經理聯合出版社給大家帶來《産品經理數據修煉30問》的5折專屬優惠，僅限今日，限量100本：

購買鍊接：http://996.pm/YypDL

本書作者：R.D（孫瑞達），前騰訊數據産品經理，人人都是産品經理專欄作家，《産品經理數據修煉30問》作者。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部