sql中如何将视图中某一字段相同的数据合并 不同内容的字段相加_追求卓越篇—数据产品埋点全流程实践...

前言目录

1. 以始为终，澄清问题与需求；
2. 思维混乱，分解聚合很关键；
3. 输出文案，清楚明晰易看懂；
4. 埋点校验，SQL平稳教过渡；
5. 追求卓越，理论管理两不误；

理论准备

前端埋点图示

• SDK：相当于开发集成工具环境，通常在客户端部署SDK代码，当用户行为触发预定义事件后，会自动存储上报事件点；
• Kafka：分布式的基于发布/订阅模式的消息队列，用于大数据实时处理领域；（后续文章详细描述）

接下来将会对埋点全流程作详细阐述，让我们开始进阶之旅：

一、以始为终，澄清问题与需求

在埋点工作正式开始之前，需要根据实际业务情况，确定好埋点需求的出发点至关重要，不仅方便后续埋点维护，更方便日常的数据统计分析工作，抛开理论，以实际埋点为例（不懂参数设定不要紧，后面详细说明）

提示：涉及的字段囊括范围，页面停留时长计算方式等都会详细列出；

广告（Ad）埋点

其中，涉及具体业务需求的字段有：entry，source，newstype，show_type，extend等；

• entry涉及到目前现有业务所有广告入口，必须针对业务实际情况罗列；
• source涉及广告对外投放平台，必须针对业务实际情况罗列；
• newstype涉及广告在各入口，各对外投放平台的内容形式；
• show_type涉及广告在各入口，各对外投放平台的展示形式；
• extend1/2为应对产品不断变更的需求增设的预留字段，根据具体业务添加；

内容列表页加载埋点（loading）

其中，涉及具体业务需求的字段有：type，status，extend等；

• type涉及业务中所有的列表页加载方式，通常有底部点击加载、顶部下拉加载、加载按钮、回到顶部自动刷新加载、底部触发加载（内容瀑布流）等
• status涉及业务中所有设定的已知加载错误状态码，通常包含：网络中断、网络异常等等；
• extend1/2为应对实际业务新增设的预留字段，根据具体进行添加；

内容点击（display）

其中涉及具体业务需求的字段有：goodsid，category，extend2等；

• goodsid涉及业务中商品的具体形态，如视频，电商团购商品，内容，课程等等，根据具体的类目指定各自的内容点击（display）数据点字段；
• category涉及商品的分类，像传统电商有三级分类展示；
• extend1/2为预留字段，根据实际业务新增；

内容详情页（detail）

其中涉及具体业务需求的字段有：entry，goodsid，show_style，status，category，extend1/2等；

• entry涉及业务中所有能够进入到商品详情页的位置，类似自身业务广告入口来源，对比理解其实不是很难；
• goodsid涉及业务中所有的实体/虚拟商品ID，最好结合业务对该点进行拆分，不要混为一谈；
• show_style涉及商品在详情页中的展示形式，涉及具体业务可能会明显有所不同；
• status涉及业务中所有设定的已知加载错误状态码，通常包含：网络中断、网络异常等等；
• category涉及商品的分类，像传统电商有三级分类展示；
• extend1/2为预留字段，根据实际业务新增；

凌晨一点了，写的有点累，此外涉及的消息通知、用户前台活跃、用户后台活跃、评论、收藏、点赞、错误日志、启动日志数据等评论区留言，后续慢慢补充，等不急也可以在评论区留言，单独发送；

问题1：刚接手公司前任数据产品经理的埋点文档，如何迅速从需求触发，理清埋点业务框架？

• 用Xmind绘制公司产品架构图，方便从整体上宏观把握业务体系；
• 将旧文档中埋点与产品架构图作对应，找出盲点以及残缺，进行针对性标记；
• 针对旧文档文本表述，利用测试环境设备进行测试，校验数据点是否准确无误；
• 旧数据点有误或者旧文档描述与实际测试结果有差异，及时对埋点文档更新，邮件同步相关人员；

问题2：理清埋点业务框架后，发现数据点不准，该如何处理？

• 首先，根据数据统计，判断是单个或者某个业务相关数据点不准确（远低于99%），还是整体数据都不准确；
• 如果是单个/某个业务相关数据点不准确，可以寻找开发工程师抓取客户端回传数据包和服务端接收数据包比对，查看是否存在丢包问题；
• 如果是整个业务数据点都存在异常，则需要开发工程师检查埋点SDK以及服务器网络稳定性问题；
• 以上两种都排除以后，仍然问题存在，需要数据产品经理与开发工程师详细核对触发逻辑，受个人技术限制，也可以寻求稍微资深的开发工程师寻求帮助，一起检查代码问题；
• 注意：类似神策和诸葛IO等SaaS平台都设计有数据管理功能，对上传接口数据点是否入库以及数据安全性和准确性作校验，检查相关数据点是否被禁用；

问题3：接收数据埋点错误，要不要和开发开会，会不会得罪人，私底下解决可好？

数据产品经理应该对自己所负责数据流负责，出现了任何问题都得去理性，冷静面对；如果开发工程师因为排期问题得不到解决，可以寻求开发领导的协调，数据作为公司业务线的核心驱动力，其重要性可见一斑；勇于承担责任与义务，难的不是技术而是沟通；

那么在了解业务后，梳理接下来需要面对的实际需求：

• 从采集位置上划分为：前端埋点、后端埋点；
• 从功能需求上划分为：业务埋点、监测埋点；
• 从业务路径上划分为：路径埋点、独立埋点；
• 从表现形式上划分为：显性埋点、隐性埋点；
• 从组合形式上划分为：聚合埋点、单一埋点；
• ...

二、思维混乱，分解聚合很关键

在面对数据埋点是，是否点越多越好？

像第一节表格内容一样，你可能对数据点有了充分的认识，大多数情况下，数据点都不是孤立存在的，而是一个业务、功能、性能调优等集合，如何理解数据点为什么要聚合，就得介绍下数据在数据仓库中如何利用：（数仓设计以及背后的技术问题，后续文章更新）

数据仓库通常分为：ODS、DWD、DWS、ADS；

• ODS（operation data store）原始数据层：存放原始数据，通常这一层数据要做备份，防止数据丢失造成无法挽回的结果；（2020年2月25日发生的微盟数据事件足以证明ODS层的重要性）
• DWD（data warehouse detail）明细数据层：与ODS结构和粒度一致，只不过进行了数据清洗；
• DWS（data warehouse service）服务数据层：聚合到用户当日，商家当日等粒度，通常会以某一个主题为线索，组成跨主题的宽表，比如一个用户ID串联该用户的所有操作行为记录及业务数据；
• ADS（application data store）数据应用层：为统计报表提供数据，通常为DWS层数据组合；

数仓开发中涉及的业务表和事件表众多，不可能对于某一个新增需求不考虑其可复用性和扩展性需求，所以在设计时，尽可能合并相关业务点，方便数仓开发工程师利用事件表对数据仓库进行业务梳理分层设计；

关系模型

数据仓库各层包含哪些数据，以及这些数据到底如何组织，可以参阅下图。

（图片来源：尚硅谷大数据开发）

有了对数据仓库的认识，相信你对如何设计前端业务埋点有了基本的了解，那么接下来介绍如何输出文案，方便技术理解；

三、输出文案，清楚明晰易看懂

输出文案可以向第一节表格内容呈现，但是实际解决问题过程中，面临多个问题需要思考：

1. 如何设计埋点，埋点都是由哪些构成的？
2. 每次更新文档都比较烦，找不到以前是否埋过这些点？
3. 如何成有效管理埋点，产品的进度太快，很多时候研发在埋点文档中看不到哪些是新增的？
4. 前端埋点依赖发版，如果多个版本相同埋点参数不一致，怎么能够更好管理埋点？
5. 研发不清楚前端页面具体埋点位置，通过单一文档无法识别，如何能更高效输出文档？
6. 聚合的埋点在各业务场景中是否存在不同，如何能够更好的说明埋点的参数不同？
7. 不懂开发，能不能有一个好的工具方便我管理自己设计的埋点，传统excel在埋点较多时不方便寻找管理？

你是否有过这些疑问，在埋点之初这些问题会一直困扰你，特别是在业务量庞大时，需要的埋点更是难以高效管理版本迭代情况，那么对于追求卓越的数据产品经理，我们如何才能解决业务问题；

根据自己的经验，我设计了一套以Axure为原型的埋点管理系统（需要的私信），能够方便我解决以上的所有问题，因为涉及到具体业务，所以我对原版本进行了大量删除，只保留部分业务作为讲解：

Axure数据埋点管理系统设计https://www.zhihu.com/video/1219658404060704768

数据埋点管理的功能做简要介绍：

数据点增/删/改记录部分

这部分通常展示当前数据点命名规约，以及旧系统迁移打点，新系统新增、修改、删除打点项，而且Axure自带免费发布功能，能够及时的同步所有修改内容；

搜索功能

通过设置的内置搜索功能，能够方便快速定位到“数据点增/删/改”部分相应变更点；

数据点版本详细描述

通过记录数据点各版本字段保留以及详细说明，一方面方便研发开发，另一方面及时掌握数据点变更原因，变更前状态，有效溯源历史业务场景，管理更加高效便捷；

数据场景描述

针对某个组合数据点出现的业务场景，统一做罗列，很多情况下并不是所有的字段都是可缺省的，根据实际业务的组合场景更加普遍，所有有效的文档才能减少与开发沟通，提高工作效率，目前我的文档不会再和开发详细对细致内容，减少了相互之间宝贵的时间，提高产能；

四、埋点校验，SQL平稳教过渡

介绍了埋点以及埋点的管理，接下来针对用户操作行为数据验证埋点准确性提供几种方法：

1. 通常情况可以让测试人员提取客户端上传埋点日志文件和服务端接收日志文件作对比，观察两者是否存在丢包情况；
2. 通过在数据库中自查，验证埋点是否已经正确上传：

SELECT 埋点名称 FROM 事件表 WHERE time >= '2019-03-01 00:00:00' AND time <= '2019-07-07 23:59:59'

3.检查转化流程中是否存在明显数据异常（以电商为例）：

从用户行为中取，下单人数（只要下单次数>0）,支付人数（只要支付次数>0），再从日活跃数表中取活跃人数，然后对应的相除就可以了。SQL可以后台回复；

五、追求卓越，理论管理两不误；

简要的数据埋点格式可以参照以下图进行理解：

通过大数据处理、数据统计、数据分析、数据挖掘等加工处理，可以得到衡量产品状态的一些基本指标，比如活跃、留存、新增等大盘数据，从而洞察产品的状态。此外更重要的是随着数据挖掘等技术的兴起，埋点采集到的数据在以下方面的作用也越来越凸显：
驱动决策：ABtest、漏斗优化、用户增长、bug修复、精准营销、流失用户预警
驱动产品智能：智能推荐、场景化提示等
驱动安全：风险识别

五点了，睡觉往后章节会给大家详细介绍数据仓库、数据挖掘算法、SQL高级查询、Python/R与数据挖掘文章，更好的以实践为驱动力，快速成长；

可以私聊我教你PPT也是可以的，对内对外都是必备技能，放几张自己做的胶片：