一、数据在产品各个阶段中起到怎样的作用？
在此之前我们得先搞清楚产品的生命周期是什么？
大家耳熟能详的开发 → 引入 → 成长 → 成熟 → 衰退
整个历程的生命周期就像人从出生到死亡经历了整个历程，是一个非常宏观的概述，我们这里讲的是更加微观粒度具象化的
举一个栗子：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%，就实现了我们的整个策略的温水煮青蛙式上线，非常的稳定，这又称灰度放量，阶段性放量。