序言
0、产品驱动就必然要求有专门的产品经理，而产品经理真实的素养应当是：
· 对垂直行业有深刻的理解，并清楚如何与互联网元素建立有效连接（而不仅是浏览 行业资讯加体验尽可能多的竞品）；
· 对产品架构的建设与把控，始终保持对产品的整体化认知，合理升级产品来应对市 场、需求和场景的变化（而不是开会，写需求文档，画原型图）；
· 对产品生态的构建和优化，有效整合用户体验、商业模式、市场行情等各维度资源 （而不是单纯地把改进视觉与交互当作用户体验的优化）。
因此，产品经理一定要具备某个垂直领域的专业技能，且具备跨界的知识储备
数据30问 ：
第一单元 刚接手一款产品，如何快速了 解它
1、 产品从0-1的重新定义
从数据的角度对产品进行了宏观、中观、微观的全面扫描之后，了解 产品所属的互联网领域的现状、生态环境，产 品全局的核心数据指标及其口径和意义，产品的KPI、用户特征，竞品的相关情况， 产品各功能的数据、逻辑、用户流量分布、用户特征。 <br /> ** 描述举例：**<br /> ××（产品名称）是一款××（领域）互联网产品，它在领域中处于××××的位置 （产品的领域地位、发展程度）。<br /> 目前，产品的核心数据规模如下：<br /> · 日登录用户数：××万<br /> · 日活跃用户数：××万<br /> ·××（其他指标）：××万 <br />这些数据具有××××、××××等特征（主要指数据周期特征）。 <br />产品的主要功能有：<br /> · 扫一扫 <br />· 搜索 ·×××（其他功能）<br /> ·…… <br />各功能的日活跃用户情况如下：<br /> ·××功能，日活跃用户数占全局的××%<br /> ·××功能，日活跃用户数占全局的××%<br /> ·…… <br />其中×××（功能名称）功能比较受欢迎，而××××（功能名称）功能可能存在用户 痛点。<br />产品的活跃用户特征如下（活跃用户的数据特征）。 <br />· 性别分布：男性用户××万，女性用户××万 <br />· 年龄分布：××××× <br />· 主要集中城市：×××××
2、 怎样理解产品中那些酷炫的数据指标 ？
解读一个数据指标，可将它分解为时间粒度和口径两个要素。
· 时间粒度表示一个指标所纳入统计数据的时间范围，例如一天、一周、一个月，或 者自产品发布以来的所有时间。时间粒度可以认为是数据指标在时间上的限定。
· 口径表示一个指标所纳入统计数据的来源和计算规则，是对指标在空间上的限定 
、
3、 产品中有那么多功能，怎样摸清它们的脉络？
3.1 画一张属于自己的产品地图
3.2 在功能方框和箭头连线上标注关键数据
3.3 在功能方框上记录每个功能对应的数据资源 
一幅完整的产品地图除有功能关系和数据标注外，还应关注同一功能的不同状态， 这些功能会在不同设定下有着差异化的体验。 如： 已登录or未登录 ， 好友or陌生人， 流量or Wi-Fi联网
4、 了解产品用户，用户画像还是用户特征？
4.1 用户画像和用户特征区别
用户画像： 用户画像是我们根据对目标用户的主观认知刻画的一个虚拟人物角色，多出现于产 品或功能的策划阶段。 。我们可以站在这个角色的立场思考用户需求、策划产品，以 保持对产品目标用户的清楚认知，避免产品设计偏离用户需求。
用户特征 ：从已上线的产品中选取真实的用户，利用已有数据对她/他进行的各种客观描述 就是用户特征。通过用户特征，我们能够清楚地了解产品中用户的情况，收集用户 反馈、挖掘用户需求，帮助我们迭代产品，开展差异化运营。 我们更关注这些用户的群体特征，以及各种基础特征的分布 。
在产品上线运营一段时间后，把 用户特征与策划阶段的用户画像做对比，看看是否存在差异。如果差异不大，则说 明产品的实际用户定位与预想的基本一致；否则就要思考并寻找是什么因素导致了 差异，以决定是让产品接受实际的用户定位，还是调整产品策略以使产品向预想的 用户靠拢。
4.2 大多数不发声”的陷阱
产品在初期规划时已经做足了用户调研，不仅使用各种定性研究的手段与典型目标 用户做了面对面的深入采访，还利用调查问卷定量研究了更广的人群，过程和方法 也非常严谨、科学。可为什么产品上线后用数据分析得到的用户特征与初期用户调 研的用户特征相去甚远呢？
这多半说明你掉进了“大多数不发声”的陷阱，也就是 产品中超过50%甚至更多的实际用户并不属于初期调研的典型用户人群。 当我们通过电话或实地调研了解用户的情况，实际得到的反馈很有可能只是小群体 的想法。因此，一旦产品上线并积累了足够的数据时，一定要尽快用数据验证用户 的情况，并配合再一次的用户研究，以免让我们的产品运营南辕北辙。
5、 产品与数据，值得注意的概念？
5.1 注意用词的区别：
- 维度vs指标
- 百分数vs百分点
同比vs环比 ： 同比的意义在于可以排除周期效应对数据的影响，观察数据长期的增减变化，评估 长期策略的影响；环比的意义在于观察数据近期的增减变化，评估短期策略的影 响。
5.2 保持名称的一致性
保持名称的一致性主要体现在以下三个方面。功能名称的一致。 例如对于产品中的会员用户，可以命名为VIP、会员、高级用 户、贵宾等，产品团队一旦决定使用某个名称，比如 VIP，那么在产品任何相关的 文案中都应当叫 VIP，数据平台中关于此的统计也应当以VIP为关键词。
- 数据名称的一致。 同一个指标，在数据平 台、报表、报告等的表述中都应统一名称。
- 产品名称的一致。 对于自己负责的产品的名称，应在产品内、官方宣传渠 道、品牌推广等场景中保持一致，尤其是含有英文或特殊符号的名称，大小写和符 号的用法也需要关注。
第二单元 数据支撑体系是如何运作的？
6、 人力：数据团队中有哪些幕后英雄？
、
7、物力：数据产品是怎么来的？
由于数据产品需求的产生比用户产品需求的产生更加频繁且琐碎，以及数据具有很 强的时效性，不可能每个需求都以独立的数据产品功能来实现。这就需要采取泛化 的思路进行需求分析和设计数据产品。
需求实现首先要思考“终极问题”：
一般而言，通过需求分析去掉那些不具有实现价值的需求后，就可以着手需求地实 现了。在数据产品中，这些事情同样要做，不过往往不必着急去做，需要先考虑清 楚以下三个问题。
· 问题一，需要哪些数据？实现需求往往需要不止一个数据。
· 问题二，这些数据是从哪里来的？弄清楚每一个数据的来源，并确保这些数据已经 到位，尤其是需要从合作部门或其他公司那里获取的数据。
· 问题三，这些数据要到哪里去？即思考需求的实现方式和数据的呈现形式，例如， 做成报表还是做成订阅邮件？数据是按日更新还是按月更新？对其他数据指标及数 据产品是否会产生影响
使用Excel写需求文档的优势：
- 使用多张工作表快速切换文档章节。一个Excel文件即一个工作簿（Workbook），其中可以添加多张工作表（Worksheet），通过Excel底端的标签卡可以很快速地在多个工作表之间切换。这样，我们就可以把同一个需求文档中的不同章节分别放在不同的工作表中， 在查阅文档时可以直接切换到相应的章节，这要比使用Word的目录定位方便得多
- 增删局部内容，不影响整体版式。需求文档中的每一句话都独自占用Excel电子表格的一行，这样进行后续补充或删减内容时，只需要在相应的位置新增一行或删除一行即可，不必像在Word中那样，担心增加或删除内容会导致文档中其他内容发生版式错乱，如图片跑偏、表格跨页、文本断行等
- 对表格内容灵活地筛选和统计。数据产品的需求文档自然是少不了带数据的表格的，在表格中进行一些计算也自然是少不了的。使用Excel的函数，不仅可以轻松地实现表格中的数据计算，还能够在数据发生变动时自动更新计算结果。
另外，在写需求文档时可以用一张工作表做需求清单——列明所有的需求点及相关信息（如图1）。如果要查看某个模块中已经实现的需求，只需要通过Excel的筛选功能，按照模块和状态进行条件筛选即可。另外，还可以通过编辑公式（或Excel的数据透视表功能），得到图2的统计表格，随时了解需求的整体情况
8、 除了报表平台，数据产品还包括什么？
数据产品体系的层次模型，该模型按照数据生命周期将数据产 品划分成四个层次：数据采集层、数据接入层、数据处理层、数据应用层 <br />
9、 数据上报前需要做哪些准备工作？
9.1 准备一：允许上报什么样的数据 ？
· 行为数据多于内容数据
· 结构化数据而不是非结构化数据
· 简单数据类型而非复合数据类型
9.2 准备二：定义数据协议和数据Topic
9.3 准备三：统一文本编码
10、 埋点就是数据采集吗？
数据采集是一系列的动作，它包括三个标准动作：埋点、采集、上报
除了少部分数据需要实时上报，大部分数据对时效并没有非常高的要求，这样便可 以将多个数据做一定积累后统一进行一次上报，既能够保证用户产品的性能，又可 以减轻数据产品的服务器和网络负担。这就是对上报节奏的控制。
常见的上报节奏 有四种。
· 实时上报。数据采集后立刻进行上报。优点是可以确保数据的高时效性，但过于频 繁无疑会影响产品性能。
· 轮询上报（也称定时上报）。数据采集后先暂存，每隔固定的时间对暂存的数据进 行一次集中上报。优点是便于数据在时间维度上的处理；缺点则是每一次上报的数 据量都不可控，如果在一个时间间隔内暂存的数据过多，同样会影响性能。
· 定量上报。数据采集后先暂存，暂存数据每达到一定量才进行一次集中上报。这种 上报节奏可以消除暂存数据积累过多产生的隐患，但数据上报时间不可控，如果暂 存数据迟迟积累不到一定的数量，则可能会使数据丧失时效。
· 定时定量上报。将轮询上报与定量上报的特点相结合，在实践中，这也是非实时上 报采用的首选节奏。
11、 数据上报到哪里去了？
11.1 数据仓库vs数据库
· 面向的业务场景不同。数据仓库面向数据分析处理，而数据库则面向事务处理。例 如一款社交 App，它会使用数据库来存取用户的账号信息、参数设置、关系链等信 息，为产品提供用户身份验证、设置解析、好友互动等业务逻辑的数据事务处理； 而用户在App中表现的各种行为数据，则会通过数据产品存储到数据仓库中，以支撑 日后对用户行为数据分析的需求。
· 优化的操作不同。由于面向的业务场景不同，数据仓库需要集中系统资源优化数据 的获取，以应对大量数据被频繁调取、分析和处理的需要；数据库则需要对数据的 访问、存储、删除、更新进行全方位优化，以满足频繁的数据更新和事务处理对速 度和效率的要求。
· 数据的组织方式不同。数据仓库中通常以时间的分区来组织数据，如按小时分区、 按日分区、按月分区；而数据库通常以数据的索引和实体的关系组织数据。这主要 也是为了契合不同的业务场景——数据分析通常要以一个时间粒度为单位进行统计 和分析（如统计一天的活跃用户数），而事务处理则需要保持数据库中各数据实体 的关系（如一个用户的账号和密码必须与该用户紧密关联）。
· 数据冗余性不同。冗余即被重复存储的数据。如果你学习过数据库相关的知识，那 么一定对关系数据模型的范式（如第三范式、BC范式）不陌生，范式的作用就是在 保证数据关系的前提下尽量减少数据的冗余，这也是数据库实践中对数据的低冗余 要求。而数据仓库不但没有强调数据间关系，反而接受高冗余的数据以丰富数据的 维度，从而提升数据分析的效率。
对于数据产品而言，数据接入层和数据处理层会更频繁地与数据仓库打交道，并且 数据仓库通常也是数据接入层和数据处理层的数据通信渠道；而处于数据应用层的 产品与用户产品相似，通常使用数据库来实现产品的数据存取和事务处理。
11.2 用可视化方式达成约定
数据Topic申请管理平台是数据接入层的一款数据产品，它通常 被设计为一个网站，运行在公司内网中。我们可随时访问这个网站申请数据Topic， 以接入产品中要上报的数据，而数据团队只要安排专人对申请进行审核即可。数据 Topic申请通过后将自动生效，并在数据产品体系的各层次发挥相应的作用。 
12、我们可以直接使用上报的数据吗？
上报的数据要在数据接入层做充分的汇集，数据处理层将在此基础上针对 形形色色的应用场景做各式各样的处理。
12.1 数据处理的基本操作：归并和计算
12.2 任务调度平台，自动化处理引擎 
· 脚本管理，提供脚本上传、共享、下载和删除的功能，供使用者维护用于数据处理 的脚本代码。
· 任务管理，在此配置任务，告知任务调度平台以怎样的节奏和方式执行数据脚本， 以实现我们期待的周期性自动处理。稍后我们讨论任务配置相关的内容。
· 任务依赖管理，对于要严格按照先后顺序执行的多个任务，要在这个模块中设置它 们的依赖关系。
13、 数据处理好了，我可以享用哪些服务？
· 报表平台是数据的综合性展示平台，以报表和图表为主要的交互形式，所有值得观 察和分析的结果数据都可以在此呈现。 <br />· Dashboard 将多组相关的核心数据指标以各种图表的形式展示在同一个页面中， 便于站在全局视角快速且直观地观察数据。 · 用户分析类产品，包括用户画像产品、用户特征分析平台、用户提取平台、用户数 据包处理工具等。这类数据产品提供有关用户特征分析和应用的各种平台和工具。<br /> · 数据订阅类产品，包括报表订阅、推送订阅、异常告警等。这类数据产品以邮件、 短信、微信或App等方式向订阅者推送订阅内容，便于他们在第一时间了解数据的情 况。 <br />· 即席查询类产品，包括数据仓库IDE、命令行工具、数据提取API等。这类数据产 品面向高级需求，为数据的专业应用提供灵活支持。 <br />数据门户中大多数产品会以Web为技术形态，可以在电脑上通过浏览器方便地登录与 使用，而不需要安装额外的软件。随着移动办公的普及和数据决策实时性的提升， 移动化的数据门户产品也成为主流需求，形态如微信公众号、微信小程序、App。
14、 体验优良的数据产品有哪些表现？
1、产品通过交互建立起与用户互动的通道，通过客观逻辑建立用户的主观认知。用简 单的语言概括一下，无论是用户产品还是数据产品，“良好的体验就是要让用户用 着爽”。
2、 使用文档与文档检索 ， 反馈与人工服务
3、 严格对待权限与安全 ： 权限管理是保障数据安全的基础手段，也是数据产品的基础模块之一 ， 数据产品的安全问题就要格外关注 。
第三单元 立足当下，如何轻松实践数据
15、 怎样快速树立数据化运营思维？
数据化运营通常是指运用数据为产品制定并实施运营决策的过程。 如今，以数据驱动运营已经成为产品运营的主流方法。 <br />** 15.1 认清运营的焦点：用户 **<br />
- 用户运营——关键词“拉新”和“拉活”。建立用户分层运营体系，直接或间接与 用户建立交互，同时可以开展用户研究。也会根据需要开展针对活跃用户、特定群 体用户、流失用户等的专项运营。
- 内容运营——关键词“蹭热点”。撰写文稿或挖掘用户产生的内容，整理成一篇篇 的热文，通过官方媒体（如资讯平台、微信公众号、微博等）推出，吸引用户自发 传播，在激发用户活跃度的同时将一定数量的潜在用户引入产品。
- 社区运营——关键词“氛围”和“粉丝”。在论坛、聊天群组、贴吧、知识问答等 以非熟人关系构建的用户互动平台中引导用户进行内容互动，不断产生有助于塑造 产品口碑的内容，营造活跃和谐的社区气氛。常见的手段有建立以标杆用户为中心 的粉丝群体，设立并引导热点话题、制定社区规则及荣誉体系等。
- 活动运营——关键词“好玩”。通过策划有趣的活动吸引新老用户积极参与、分 享，拉动产品增长。参与运营活动的用户通常能够获得特别的奖励，如额外的积 分、优惠券、免费的增值服务以及实物奖品。活动运营也常伴随着商务合作。
- 渠道运营——关键词“多多益善”。渠道主要是指用户获取产品的渠道，如应用商 店、手机厂商的内置。渠道运营一方面是渠道的拓展，让产品有更多的机会与不同 用户接触；另一方面是提升产品在每个渠道中的曝光度，如竞争应用商店的排行榜 头位以提高产品知名度。
15.2 理解用户数据的六步循环
经历这样一轮循环，数据转化为产品的优化策略或运营方案，对产品产生了实质性 影响。这些影响是正面的还是负面的，对产品的提升是否符合预期，有没有新的问 题浮现，是否还存在进一步提升的可能性等问题就需要投入下一轮的循环过程来求 证和解决
15.3 明确数据化运营与数据产品体系的关系
前者为用户产品提供了一种运营规范，而后 者则主导了数据产品的构建、实施和运作 
16、数据啊，数据，我的产品怎样才能成功？
16.1 感性地提出一个问题
首先是提出目标问题，也就是我们想知道的，或者希望通过运营实现的最终效果和 要解决的问题。
16.2 将问题分解为能够量化的指标
16.3 理性地回答问题 
17、 怎样制定合适的数据上报策略
然而，产品上线前，可供参考的信息 十分有限，这时要怎样制定合适的数据上报策略呢？
17.1 大声说出你想了解的内容
从产品经理的角度看，制定数据上报策略可理解为规划各种数据 Topic及数据定义 的过程。产品产生的数据将依照数据Topic定义的规则接入数据产品体系，进而展开 后续步骤。 数据Topic比较抽象，以至于常让我们感到无从下手，此时，不妨利用我 们的老办法——从提问开始，大声说出你想了解的内容。
17.2 数据化各实体，寻找定义要素
从提问到数据化 ，用各种数据特征来表述一个数据实体即为数据化，我们能够借助这个过程，寻找定义数据Topic的要素 
17.3 用语义表达法试验上报策略
数据语义表达法常用来模拟还原数据Topic中的一条记录事件，也可以通过这种表达 法帮助我们梳理数据Topic应当包含的字段。根据上文，关于用户登录，其语义可表 达为“谁，在什么时间、在哪座城市、用什么样的设备、以怎样的方式，尝试登录 了一次哪个版本的App，登录结果如何”，由此推演出相应的数据Topic定义（暂命 名为Topic A），如表17-2所示。 
第18问 哪些用户数据值得收集？
18.1 对用户行为的三步思考
首先，想象一位用户对App的一次常规使用经历： 这个常规的使用过程涉及用户登录、操作行 为、功能设置这几种关键数据。
其次，清点产品中那些重大功能和模块。这些功能和模块或有着相对独立的用户体 验（如社交App中的聊天、支付、语音通话功能），可以构成用户的一次完整的产品 使用过程；或有着独立于产品整体的KPI（如承担商业收入、跨部门或跨公司合作的 功能），备受管理层和决策者的关注。用户在这些重大功能和模块中的行为数据值 得独立细化，以备日后做专项分析和深度挖掘。
最后，不局限于产品运营，让我们将视野扩至产品的全局运作环节，看看开发、运 维、质量等团队会关注产品的哪些方面。将来自产品其他团队的关注点从数据视角 展开，通常会涵盖我们在第2.3节讨论的质量数据和技术数据，这些数据中的诸如产 品功能的运行日志、用户故障报告、性能评估等在产品运营中同样受用。
总结上述三步的思考，我们可以较全面地找出各种值得收集的用户数据。
表18-1 产品中值得收集的用户数据及数据Topic规划参考（以社交App为例） 
第19问 怎样为数据赋予运营的意义？
口径和时间粒度是定义指标的要素，自然也影响着数据处理的逻辑。
第20问 怎样对待未登录用户和小号用户？
20.1 匿名访客，你的需求同样重要
我们称未登录而使用产品的用户为匿名访客，常见于以下三种情境。
· 完全不需要登录的产品。类似记事本应用程序、计算器应用程序、词典应用程序这种功能简单的工具性产品，任何用户都是匿名访客，都可以“随用随走”，甚至产品根本不提供登录机制。
· 即使不登录，也能满足核心需求的产品。以腾讯视频、QQ音乐、百度地图为例，匿名访客可以使用这些产品中的全部核心功能，而注册登录的主要目的是向用户提供增值和个性化服务。
· 不登录可以使用有限功能的产品。这样的产品涵盖购物、金融服务、在线社区、教育等众多领域，数量也是最多的——我们日常接触的大多数产品都符合这种情境。
在这些情境下，强制用户登录就会显得不合理，甚至会冒犯用户。从数据的角度看，匿名访客由于缺少账号标识，小则影响用户数量的统计，大则难以通过关联分析深入了解这部分用户。由于用户没有主动“告诉”产品“我是谁”，因此我们需要用一些数据策略来标识匿名访客，以判断多次来访的匿名访客是否为同一人。
在实践中标识匿名访客常采用如下的复合策略。
1、首先，分配规则匿名访客首次通过当前设备或浏览器使用产品时，为该用户分配一个匿名访客标识，记作IDA。匿名访客标识生成依据：
· Android设备可依据其硬件编号（如IMEI、无线网卡MAC地址、处理器序列号等）生成其匿名访客标识；
· 由于iOS限制App获取部分硬件信息，故可依据IDFA或IDFV生成其匿名访客标识；
· 通过浏览器访问的网页产品，可以考虑由服务器生成一个不重复的标识下发给浏览器作为匿名访客标识，并借助浏览器的Cookie进行较长时间的存储。
2、其次，认领规则建立匿名访客标识与登录用户的联系，由登录用户“认领”匿名访客标识。产品在当前设备或浏览器中由匿名访客状态转为登录态时，查看该登录的用户是否已关联匿名访客标识：若未关联，则将上一步分配的IDA与该登录用户关联；若已关联，则取出已关联的匿名访客标识，记作IDB，一旦用户注销登录再次转为匿名访客，以 IDB替代IDA来标识产品在当前设备或浏览器中的匿名访客。这样一来，匿名访客标识与首次建立登录态的用户关联，并会随这个登录用户传播到其他设备或浏览器上，实现的效果是，将同一个登录用户使用过的设备或浏览器上的匿名访客识别为同一名用户。
3、最后，过期规则 过期规则包括两个方面的“过期”：一是设备或浏览器上现行的匿名访客标识会过 期，二是登录用户所认领的匿名访客标识会过期。前者过期后，设备或浏览器上的 匿名访客标识将按规则被重新分配，新分配的标识记作IDA’，替代原有的IDA或者IDB；后者过期后，登录用户与原匿名访客标识解除关联，可再次按照认领规则重新 认领未被其他登录用户认领的匿名访客标识。
第21问 为什么要进行用户建模和用户分层？
21.1 用户建模，基于已知探索未知
建模的应用场景: 用户属性挖掘,，个性化推荐，用户画像拓展，反作弊
21.2 用户分层，让群体特征更明显
区间等分法：将某个指标最小值与最大值构成的区间等分对用户分层
规模分位法：如果我们希望屏蔽极端个例的影响且每个分层中拥有数量大致相同的用户，就需要换用规模分位法，仍以日均发送消息水平为例，步骤如下。
· 首先，与区间等分法一样，选取一段时间的数据，处理得到每个用户的日均发送消息数。
· 然后，排除日均发消息数小于1的用户，并以日均发送消息数的升序排列剩余用户，记录参与排序的用户数，例如为150万人。
· 最后，将这些用户按排列顺序依次等量划分为n组，由低到高标记每个分组的水平。
第22问 怎样精确控制A/B测试？
第23问 数据是怎样推动产品灰度发布的？
实践中，围绕一个新版本，通常要循序渐进地安排多轮灰度发布，这样做有两方面的好处：一方面，灰度版本的运营工作得以与产品研发的收尾工作同步开展，让灰度版本同时接受用户与技术的双重测试，从而缩短产品迭代周期；另一方面，每一轮灰度发布面向不同规模和特征的志愿者用户群体，这样就可以依次收集侧重于不同维度和深度的数据与反馈。
图23-2所示的是用户量在千万以上的社交App的版本周期，每个周期的灰度发布计划包含三轮，每一轮都有所侧重，灰度发布计划各轮对比如表23-1所示。
将每一轮拥有参与资格的用户列入该轮灰度版本的白名单中，仅允许白名单用户登录灰度版本，禁止其他用户登录。如果没有白名单机制，万一安装包被泄露，不稳定且不完备的产品就会曝光给大量无参与资格的用户，影响产品口碑。
对参与用户的数据跟踪：
与正式版本相同，灰度版本的日常运营指标同样需要被统计和展示。对于灰度发布重点测试的新功能和模块，还应建立专门的展示和监控机制，如新功能的用户渗透率[3]、人均使用时长、操作中断的情况，按日评估这些功能和模块的健康程度，以寻找可能存在的缺陷，以及在体验上使用户受挫的节点。
灰度发布的注意事项：
其一，除了产品全局性运营指标（如日登录用户数、日活跃用户数），灰度版本的数据在处理和展示时通常要与正式版本分开，特别是质量数据，以避免干扰我们对数据的判断。
其二，应确保一个灰度版本的白名单在下一轮发布后的一定时间内失效，届时任何用户都无法登录这一灰度版本，避免有用户会一直停留在不稳定的灰度版本中，给用户带来糟糕的体验。
其三，参与灰度版本的用户是知情的，这点与A/B测试不同。一方面，为了用户的利益，我们在发布灰度版本时，必须明确告知志愿者用户这是供测试用的版本，并需要向他们说明使用灰度版本意味着什么；另一方面，为了促成灰度发布的目的，还应引导用户在使用过程中提出体验意见，倾听用户对灰度版本的抱怨。
第24问-30问
主要介绍数据统计的工具，excel、R语言，sql，人工智能等
若有收获，就点个赞吧
0 人点赞
