回顾上一年工作中，为了满足公司对于某业务数据信息统计分析的需求，由于我在数据分析方面的经验尚浅，因此主要是通过阅读相关书籍来迅速补充自己的知识体系，弥补经验上的不足。
本文仅作为自己学习数据产品设计时的总结记录，同时更是为了在工作时踩到的坑中汲取教训，作为学习的沉淀。如有存在描述表达不当之处，还请各位大佬多多指教，期待共同学习、进步~
拿到业务需求后，进行需求挖掘与澄清分析是至关重要的步骤，在刚开始做产品需求时，之前工作中因为没确认好需求，踩了一个大坑，原始需求和验收时需求发生了变化，但开发已经完成，和BOOS核对确认验收产品时发现需求变更，导致只能延期重新规划，所以这一步骤直接关系到后续产品设计的准确性和开发效率。
重点1：首先，明确我们所面向的对象和内容->who？谁需要信息？需要解决什么问题？想了解什么样的信息？
重点2：其次，明确用户场景和故事->what？/when？我在什么时间、地点、场合接收信息？接收习惯是什么？
难点：最后，梳理问题点提出解决方案->how？如何通透理解使用需求？该如何解决并转化为产品设计方案？
需要注意的点：
反复确认需求：这一步在前期工作中挺重要的，需要反复与需求来源方进行沟通需求，获取核心需求点，通过需求挖掘、需求澄清的方式将需求提炼转化为产品需求；
防止被误导：你为什么要这个功能？你想用这个功能来做什么？这个功能有帮助到你解决什么业务上的困难吗？有没有更好的方式或方法满足你的需求？
明确主次：需要明确有哪些功能是必备型、期望型、激励性、无差异型等。
用户需求调研后，就是对用户进行需求的梳理，主要的产出物包含以下3种图类型：
1. 业务流程图（便于自己梳理产品架构，加深对业务的理解）
先梳理战略后梳理流程（也就是说，先明确产品的定位，这样才知道哪些是重要的哪些是次要的，进而优化业务流程）
先主干后枝叶流程（按照不同的颗粒度划分详细度不同的流程）
例：之前在做智慧社区报事报修功能需求时梳理的物业人员与业主、平台三者之间的业务流程与架构梳理图示
2. 数据流程图（这也是咱们研发同事更关注的点）
3. 实体关系图（1:1/1:N/N:N）
各图之间的联系和区别：
1）流程图主要是帮助我们理解业务的过程，搞清楚业务全链路的流转路径；
2）站在开发者的角度，细化流程与业务逻辑，从数据流转和各个对象逻辑关系角度去描述事情的过程，因此需要用到实体关系图（逻辑关系角度）与数据流转图（数据关系角度）；
3）数据流程图是从数据角度来梳理业务流程，明确数据的流入和流出过程；
4）实体关系图主要是关注某个数据流转环节中实体之间的逻辑关系；
既然要做数据类型的产品设计，那么我们也需要了解数据的来源以及数据库相关的基础认知：
数据来源：可以简单分为外部渠道数据获取和内部渠道数据获取。
数据接口接入
爬虫接入：通过网页的链接地址来寻找网页并爬取数据。
1. 前端数据
在做产品设计的过程中，由于业务需求的拓展，需要深入了解用户行为，来丰富产品功能生态，这时候，主要采用最多的方法就是通过前端代码数据埋点来进行获取的；
数据埋点一般采用第三方技术，通过嵌入APP SDK 或JS SDK来采集用户数据；
大致埋点过程：通过第三方公司（如友盟、Growing IO）的SDK在APP或者网页中嵌入一段SDK代码，并设定触发条件，记录日志将发送到公司服务器上进行解析及可视化呈现。
数据埋点的好处：可以简单便捷的获取用户行为数据。
2. 后端数据
一般在业务数据库中通过简单埋点和自定义埋点的方式进行获取数据信息；
了解完基础的数据信息来源后就需要针对业务对需要收集的数据指标信息进行设计：
常见的数据指标体系主要有以下两种：
①关联指标法：次序性（梳理数据指标的重要性排序）、业务阶段性重心、指标可操作性、层次性
②AARRR指标法：拉新（用户转化率）、激活（用户活跃度）、留存（用户留存率）、自传播（低成本获客）、创收；
而这些获取的数据指标最终目标是为了提高业务营收指标（GMV）。
本文由 @iamtys 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。