一、數據在產品各個階段中起到怎樣的作用？
在此之前我們得先搞清楚產品的生命週期是什麼？
大家耳熟能詳的開發 → 引入 → 成長 → 成熟 → 衰退
整個歷程的生命週期就像人從出生到死亡經歷了整個歷程，是一個非常宏觀的概述，我們這裏講的是更加微觀粒度具象化的
舉一個栗子：B站彈幕之前是會擋人臉，但經過一次優化之後，彈幕就繞道人的背後去了，不會再遮擋人臉
那這就是一個產品功能的迭代，一個優化，這份優化經歷了從發現問題到解決並優化問題的整個流程，我們將其抽象爲產品功能迭代的生命週期
產品功能迭代可以簡單的抽象爲三步：
Step1：發現問題併產出需求（主導者：PM）
通過多途徑多方式發現問題點，從思維層面給出解決方案
產物：產品PRD；需求評審，PRD可實現！
Step2：開發需求
技術同學開始介入，將思維產物物理化，即開發需求
需要注意，開發完交付之後並不是馬上就上線，而是需要觀測數據是否符合我們的指標，通過實驗判斷指標情況，進行逐步放量，同時BI QA 運營等其他崗位的同學也會進入到，產品整個的迭代體系當中來。
Step3：需求落地
瞭解了產品的生命週期，再回到數據在各個階段中的作用，可以歸納爲
| 發現問題及產出需求
舉一個栗子：高德對用戶進行了調查 發現
50%的人在駕駛車輛通過主輔路的時候，導航會產生了誤偏航的現象
30%的人在駕車通過隧道的時候，自車點發生了不移動
顯然這兩點都是我們後續要解決的問題，目前人力資源有限，對這兩個問題的技術難度又是相同的，我們顯然要對問題1進行優先的解決，因爲他的影響力更大 ，二問題可以等人力釋放之後再進行解決
和明顯 這個時候可以通過數據幫助我們發現問題、定位問題並判斷出問題的優先級
| 開發需求
要把我們敲定的思維產物物理化，在這裏數據起到兩方面的作用
1、輔助算法的生成（數據集）深度學習、神經網絡 有一定的關係，屬於數據產品的範疇
2、幫助驗證我們的程序寫的代碼是不是合理（開發代碼是一個很讓人頭禿的工作），優秀如RD小哥哥也有可能一丟丟的犯錯，所以他們通常會在開發過程中，埋幾個點，通過這些點之間數據的相互對比驗證，可以幫助判斷代碼是不是符合預期的
二、目前常用的數據獲取方式及特徵
數據的獲取方式，可以簡單的分爲兩種
| 直接面向用戶
包括大家耳熟能詳的用戶訪談，用戶調研，以及用戶的主動觸達，他們具體有很多名字 像：CPO投訴、feedback、或者客服進線，這一部分重要的問題的制定，以及對用戶回答的整理和清洗，我們要從用戶需求中提取到產品需求
這類直接面向用戶的數據獲取方式 有一定的好處：可以幫助我們直接定位到用戶目前的需求，以及用戶在使用我們產品過程中發現的badcase，可以幫助我們快速止損。
不足之處：樣本量不會太大，而且單一樣本獲取時間很長，這樣會導致我們費盡心力獲取到的東西由於樣本量的不足，所導致獲取數據可能並不是一個那麼置信的指標，數據置信程度不足，而且我們沒有辦法衡量，這個問題在用戶羣體中的佔比
| 直接面向大數據
A/B Test、埋點、灰度放量 都屬於這一範疇
上文中說到，RD小哥哥會在開發過程中，在程序裏埋幾個點，埋點我們可以簡單的把它理解成照相機，當按下快門的時候，就會拍一個照片出來
A/B Test：我們爲同一個羣體制定兩種策略 ，通過對這兩種策略的不同表現數據，來對比判斷哪個策略是更秀的
灰度放量：實際上它不是一種策略的衡量方式，而是爲了保證策略上線穩定，制定的一種階段性的放量形式
舉個栗子：抖音爲了讓大家永遠都不學習，再再再再再次優化了推薦算法
推薦算法貿然的切換肯定是不行的，這個時候把用戶羣體分成兩組 A用戶羣組、B組用戶羣
首先觀測了兩組的平均app打開時長、（用舊策略的時候平均app使用時長），之後再悄悄的把A組的推薦算法改成最新的，幾天之後再次觀測數據，通過數據指標的變化來判斷，到底新策略更好還是老策略更好
即：A/B都用老測策略時平均app使用時長 Vs A改用新策略之後平均app使用時長
那這跟灰度有什麼關係呢？在誤區就是 AB實驗好像一定就是50%的流量對應50%流量，其實不然，對於DAU很大的產品，10%的流量產出的數據就已經非常具有代表性，置信度就很高了 ，就相當於已經灰度上線了，經過我們AB實驗的數據，最終得到新策略是更好的，那我們就將10%進行逐步放量，最終變成100%，就實現了我們的整個策略的溫水煮青蛙式上線，非常的穩定，這又稱灰度放量，階段性放量。