写给数据产品经理新人的工作笔记读后感锦集

《写给数据产品经理新人的工作笔记》是一本由陈文思著作，电子工业出版社出版的平装图书，本书定价：79.00元，页数：212，特精心收集的读后感，希望对大家能有帮助。

《写给数据产品经理新人的工作笔记》读后感(一)：学会数据的最佳导师是数据产品经理

mark一下，回来是需要完成书评的，不是摘要的那种书评

很不错的入门书了。果然名字起得越花哨，内容越水，这本书正相反。 220228 细读了以后发现差距还是很大的，要补的东西太多了。 可以是数据产品经理的第一本书

三四章是精华，重点不在内容而在视角。没有看过其他数据产品经理写的书，但总体来说看这一本比追一大堆公众号更能解决入行早期问题。其他的章节虽然没有啥洞见，但胜在框架完整和资料完备，省去了很多找案例和找工具的时间。除了建认知和抄作业以外，还有一个有趣的地方在与看作者分享的坑以及书友们的批注，有了很多有上下文的场景的真实感。虽然这些容易遗忘，但也是足够好的加分项了。

数字化转型的核心有两个，一个是数据，一个是设计。

数据是基础，设计是路径。

首先先要有尊重数据的意识，否则还是陷在机械论中不可自拔。理解和信赖相关性是一切的基础。

然后再说实施过程中需要以人为本，所以要关注设计。没有流动的数据就没有价值，数据流动的过程是需要设计的，阻碍流动的核心要素就是无法跨视角去思考场景问题。数据不流动的前提下，数据采集的过程反而被过度设计，数据应用的需求反而被过度设计了，前者聚焦在各种暴力计算的身后，后者则可以对照各种各样认为数据应用就是可视化的认知持有者们。

而本书的价值是在于，贴近的了解了谁可能不相信数据，为什么？以及设计的过程中需要注意到什么。是一本真正的兼顾视角和手段的启蒙书。

《写给数据产品经理新人的工作笔记》读后感(二)：截止 2023 年市面上唯一可读的数据产品经理书籍

21 年为了给自己的号写一篇数据产品经理书籍测评文章，也为了给所有想要求职数据产品经理岗位的人一个参考，我就把市面上几乎所有数据产品的书都买来看了看。当时看这本书其实并不报多大期待，但反而比其他几本阅读体验都好不少。核心只有一个：就是这本书起码是作者有独到思考的，是对得起读者的

在我自己的公众号《古牧聊数据》上首发

我记得当时发文的时候，这本书豆瓣评分还是 7 分多一点，后来似乎我也带动了不少在职做数据产品的读者朋友纷纷阅读，给这本书一个相对公正的定位

很多尚未入门的小白看专业书，会痴迷那种高大上的 ppt 。行业里不少数据产品经理的书籍，其实也都是那种 ppt 堆积产物，就是一开始告诉你这个产品的背景、然后给你展示下这个产品的功能结构规划视图、最后放几个界面截图 or 线框图。但他们只讲背景和结果，中间的过程和背后的思考基本通通略过

试问，一本书里几乎完全没有 why 和 how，只有 what，这能算一本好书么？

结合本书来说，我觉得它特点非常鲜明，就是从偏技术的数据产品经理视角阐述数据产品该怎么做，日常该怎么思考，有哪些需要注意的问题。因为作者本身的过往经历就是从数据采集、加工开始的，比较大比重的经验也都在数据报表的假设

但是，数据产品经理的视角也还可以有产品视角，数据产品也不仅仅只有数据报表、数据中台。这个领域的产品形态是足够丰富的，只不过很多门外的新人和刚入行的朋友，运气不太好，陷入报表和中台里，没有机会看到更多的形态，也错失了很多工作中的价值感，这是数据产品领域的一大遗憾

希望有机会我能填补好这个遗憾，欢迎大家感兴趣的话多多交流，我之前也在自己的号里给数据产品做了一个更全面系统的定义，欢迎阅读指正

可在 vx 里搜索文章标题阅读

可在 vx 里搜索文章标题阅读

《写给数据产品经理新人的工作笔记》读后感(三)：写给数据产品经理新人的工作笔记

数据产品是可以发挥数据价值去辅助用户更优地做决策（甚至行动）的一种产品形式，本质是发挥数据价值的工具。数据产品经理，则是实现这一工具，用数据产品去满足特定数据使用需求的一个职业。

数据产品主要按照功能、用户群体、开发者来划分，具体介绍如下。

按照功能划分，可以分为：

·数据管理工具（元数据、埋点管理、SLA等）；

·基础工具（查询、报表、数据订阅）；

·可视化工具（多数人对数据产品的概念仅限于此）；

·策略应用工具（多版本测试等）

按照用户群体划分，可以分为企业用户和C端用户，其中企业用户分为数据角色用户和非数据角色用户。

按照开发者划分，可以分为自建数据产品、第三方私有化部署工具和纯第三方工具。

数据产品经理技能树：

角色之间的关系和他们面对的问题：

表右侧的标记说明：颜色标记的部分，是对应角色关心的数据业务范围；“√”标记的是对应角色的产出；“*”标记的是“参与”。这些标记体现的是在我的经验里相对理想的状态——并不是规则，只是一种情况。

数据产品经理可以分为可视化平台产品经理、数仓建设产品经理、数据中台产品经理、策略产品经理、AI产品经理（这个比较特殊，有时候也不算数据产品经理）等。

下图描述了一个以数据产品经理为中心的，与数据体系相关的输入/输出关系。

我把数据产品经理的目标定义为“用数据方法或产品方法解决数据相关角色的数据使用问题”

数据的方法，是通过数据分析、量化定义等方式来帮助非数据角色解决工作中遇到的问题；而产品的方法，则更倾向于提供流程和工具。

从5个维度对数据需求做出分类。

关于数据业务的沉淀路径，下图展示了其中一种可能的形态。

逻辑层面，指标体系是核心；数据技术层面，数仓上层表的沉淀是核心。

指标体系

指标体系制定的基本方法：

（1）确立描述的目标。

（2）选择描述这个目标的核心指标。

（3）除了描述“量”的指标，还要选择至少一个描述“质量”的指标。

（4）确保选择的指标具有可执行性：可追踪、可比较。

（5）指标之间具有一定的独立性：具有高相关性的指标，只选择一个即可。

指标：用于衡量目标和过程，并且可参与计算的数值。

维度：描述一个目标需要考虑的参数。从坐标系的角度考虑，就是独立坐标轴的个数。

从数据表的角度，在SQL里面使用Group By语句的部分，都是维度。

比如，“城市的GDP”：“城市”是维度，“GDP”是指标；“每天的体重”：“每天”是维度，“体重”是指标。

计算口径，通常包含两个因素：计算方法和计量单位。计算方法又包括使用的数据源、计算公式、限制条件等多个因素。

报表=数据+输出方式

数据指的是指标和维度的组合，是报表的核心；输出方式可以是数仓表、Excel表格、可视化图表等多种形式。

统一的指标定义和口径定义是一个基础，其中就包含：数据源的统一、公式的统一、限制条件的统一。

宽表：字段较多的数据库表。和某一主题业务相关的所有维度信息、相关指标等都可以放进同一张宽表。

这样做的好处是：统一数据源；提升查询效率；减少限制条件和误操作。

缺点也会存在一些，例如一些场景下不得不存在数据冗余。

宽表在指标体系和指标库的基础上搭建，可以对部分已有统一口径的内容提前做出处理，方便使用者做到使用较少的限制条件即可提取和定义一致的数据。

我们可以把宽表和报表之间的关系抽象成如图4-3-3所示，它将报表和数据源之间复杂的多对多关系简化成一对多关系。

报表主题划分原则：与业务结构一致。这里是业务结构，不是组织架构，一家公司的组织架构可以频繁调整，而业务结构，以及业务结构背后的商业模式则相对稳定。

Excel常用功能盘点

微软公司CEO纳德拉都曾公开表示过，Excel才是微软最伟大的产品。

对比其他产品，Excel在数据处理的灵活性和易用性之间找到了一个完美的平衡。

从功能上说，Excel几乎无所不能：本地数据处理、检索查询、数据分析、可视化、功能开发、写SQL语句查询数据库……

当然它也有一些局限性。

我们把它的优势和局限性用一张表格来描述，如下表所示。

Excel 2007版以后，把数据6.5万行的限制扩展到104万行，但是更大的数据量带来了更慢的处理速度。

如果你需要对海量数据进行查询、计算、预处理，就用Hive；如果你要在本地处理较大量数据，就用SPSS或者R；如果你需要建立复杂的模型，就用SAS、R、Python、MATLAB等；如果你要处理大量文本，就用Python和PHP；但是，如果你需要一个完整的、本地的微型“数据产品”，Excel再完美不过，这是其他任何一个产品都做不到的，至少做不到这么好。

基础工具设计

报表工具可以分为很多种，最简单直接的方式就是从成本的角度来区分。

1．开源工具。

例如Metabase、EasyReport、Davinci等。还有像HUE这种集无数功能于一身的工具，其也有一部分可视化功能。开源工具的优点是现成、免费，可以迅速投入使用；缺点是如果想要“好用”，或者真正适应自己的业务，则需要做大量的二次开发。

2．付费工具。

如现在非常火的Power BI，以及大家非常熟悉的Tableau，还有一些老牌外企喜欢用的QlikView、Spotfire，等等。这些工具的功能相对强大，适配性、功能可用性、扩展能力、可视化效果都比开源产品优秀，还会有很多不同的付费版本，在部署方式、存储空间、性能、功能模块、账号管理等方面加以区分。基本上是越贵越好用。

3．自己研发。

自己做适合自己的报表工具，当然优点多多，在权限管理和安全审计上也更友好，可惜成本也非常高。而且，需要产品定义、排期、开发，一轮一轮地迭代，在这个过程的起点，总要用开源工具或付费工具扛一阵子，直到自研的工具在可用性上至少能和开源工具打平。这些工具的原理是类似的。

通过接口把前端配置的内容翻译成SQL语言，或者直接在前端页面提供的SQL编辑器向数据库发出查询指令。并将返回的数据结果转换成HTML表格或者基于Javaｓｃｒｉｐｔ的可视化图表（这一过程可以抽象成下图），多数报表工具都遵从这一方式。

从使用报表方法监控数据质量的角度，还可以分为表内质量问题、表间质量问题、清洗规则和其他原因带来的质量问题。

第三方平台产品

DMP的全称是Data Management Platform（数据管理平台）。针对数据的管理是涉及整个数据生命周期的，包含数据采集方案、数据接入方案、清洗方案、存储和计算方案、接口方案、可视化方案。

以神策为代表的技术方案是“以埋点为核心”，和全埋点方案相互配合，以GrowingIO为代表的技术方案是“以无埋点方案为主”，但是也提供埋点相关的产品，相互补充。

数据平台基础架构

数据产品经理不需要关心架构的技术方案和具体实现层面的事情，需要关心的是现状的每个组件分别解决了什么问题，以及它们之间的关系。以此为基础，就可以逐步关注自身的目标：在实际应用中，如何通过产品化方案来提升这个平台面向业务的服务能力。

下图展示了一种形态相对简单的架构。

无论这些组件的排布方式是什么，数据平台需要解决的问题都是一致的。

·数据采集：日志采集和数据同步；

·数据清洗和预处理：涉及一系列的规则，本质也是ETL过程；

·数据的存储：海量的、稳定的存储；

·数据的离线计算和实时计算；

·输出方式：接口和自助查询；

·系统具备相对高的性能和稳定性；

·数据安全和权限管理。

Hadoop设计的核心有两个：HDFS和MapReduce。通常需要搭配采集框架（例如比较流行的Kafka+Flume）、Hbase数据库、部署配置工具（Ambari）等一系列组件形成一个完整的架构。

HDFS（Hadoop Distributed File System，分布式文件系统）既然是一个“系统”，就会包含一系列的功能和流程。主要由主服务器（NameNode）和负责存储数据的DataNode组成，NameNode负责管理文件系统的命名空间和客户端对文件的访问操作。

而MapReduce的本质是一种编程模型，或者说是一种计算方法。作为一个平台组件，它是用并行的方式处理大规模的计算。

Flume像个情报员，负责把情报（日志）拿到手交给负责接头的信息员Kafka运送回来，处长HDFS负责接收这些数据，指挥NameNode给它们起好名字并贴上标签，交给档案馆Hbase存起来；这些数据还可以通过情报分析站MapReduce去做复杂的深度加工，加工好的结论也可以交给Hbase存起来。而想要使用MapReduce需要通过工具Hive去实现。虽然Hbase是个超大的档案馆，MapReduce也能为这个超大的档案馆提供更多结果，但若是急需这些情报采取行动（需要实时输出这些数据），它们的效率就显得有点慢。这时Kafka可以使用应急流程，把数据直接交给独立调查员Storm做实时分析，分析好了交给临时档案馆Redis存起来，领导（前端页面）可以去找Redis查阅结果。可惜的是，Storm和Redis虽然效率很高，却没有Hbase这个档案馆那么庞大和稳定，工资（成本）又太高，至今只能打一打下手，做一些补充工作。

数据源：数据采集和数据同步

从结构上说，数据源大概分为两大类，一种是非结构化数据，一种是结构化数据。

互联网公司的数据源通常可以分成3种：C端产品（网站、App、小程序）、后台系统（业务系统、财务系统等）、外部（广告公司、外部数据报告、第三方标签库等）。

公司内部的两种情况。

·用户行为采集。采集的是用户在前端的行为日志或其他事件产生的日志。对应的技术原理涉及埋点和无埋点等概念。

·后台系统数据接入。接入的是在业务过程中后台系统产生的数据。涉及的技术方案主要是数据的接入、同步、交换。

从产品层面来说，按照“一切皆事件”的思想，虽然PC端和移动端均可按照同一方法分类，但是在实际技术实施的过程中，基于浏览器的请求（HTML）和原生App的请求，两者实现方法完全不同。

1．针对浏览器：基于Javeｓｃｒｉｐｔ的数据采集

2．针对App：基于采集SDK的数据采集

3．App内嵌H5的处理方式

4．针对小程序的采集。小程序的编码标准看似全新，其本质和前端三件套（Html、CSS、JavaScrip）的差异并不大。但是，它仍然是一套全新的文件类型。以微信小程序为例，是使用WXML（微信标记语言）、WXSS（微信样式表）、Javeｓｃｒｉｐｔ组成的，加之通常要集成微信提供的一些接口，造成它需要一套单独的采集SDK来完成数据采集。

5．无埋点和后端采集

从技术的角度，无埋点使用的是监听DOM事件的方式进行数据采集，最大的优点是节省埋点的体力，最大的缺点是无法加入自定义属性。

6．关于推广渠道追踪

7．服务器端清洗和丢包率

前端采集并无“精确”一说，但是需要“保持误差在较低水平上的相对稳定”。