对埋点和SQL的常见问题，做个总结

这篇文章是对数据埋点和 SQL 查询概念的补充，也是对数据收集部分的总结。

很多非技术出身的产品经理包括我，刚入门时会对这些有着各种疑惑。

对此，下面列了几个常规的问题和思考，希望对大家有所启发。

PS：这还得感谢秋霞和多多两位小伙伴的指点，让我对这部分有了更多的认识。

一、数据收集的方式：埋点 VS 数据库储存

在提取分析数据之前，首先我们要了解数据是从哪来的。

埋点，就是将用户使用产品的行为记录下来的技术手段，比如页面的停留时长、按钮点击的数据记录。

而数据库储存，是指用户在使用产品后，记录下来的结果数据，比如张三在今天上午 10 点完成了某笔订单。

写 SQL，就是将你想要的数据，从数据库中提取出来的技术方式。

总结成一句话，前端埋点适合分析「用户行为」，而在数据库写 SQL 适合分析用户的「行为结果」。

二、埋点的成本，远高于数据库储存

所有数据的储存、维护，都是需要人力和财力成本的。

由于在产品开发中，数据库本身就是其中的一个重要环节，而埋点却不是。

对于很多业务，比如用户体量小的 2B 产品、买了偶尔用的 2G 产品，这些对埋点分析用户行为的诉求很低，也就不需要做埋点。

因此可以说，写 SQL 提取分析数据更为通用。

三、为什么 B 端产品更需要学 SQL ？

经过这段时间实践后的感受，我简单总结了一下：

（1）了解技术知识和代码，便于跟开发沟通

产品开发是通过技术手段实现的，产品经理需要了解实现原理，才能降低跟开发沟通的成本。

也就是为了沟通和决策判断上，我们不需要「技术开发能力」，只需要有「技术理解思维」。

（2）能提升结构化的逻辑思维

代码带有自上而下的逻辑属性，正确就通过，错误就不通过。

在产品经理学习和写的过程中，会潜移默化的训练自己的逻辑思维。

况且，区别于 C 端产品的重体验、重交互，B 端产品重点是要理得情业务和逻辑关系，因此是需要不断提升自己提高结构化思维的。

（3）拉取数据，从此不再求人

工作中，我们不仅要以最低的成本解决问题，更要自己有能主导解决问题的能力。

试想一下，如果每次数据分析都要去找开发，过程中还免不了修改，等待、沟通这些成本还是蛮大的。

因此，即使你是非技术出身，依然绕不过学习写 SQL 这个坎。

就算这家公司不需要，换家公司也还是要学的。

四、SQL 查询会把数据库搞崩

简单说，这跟数据库自身的配置、表结构的设计、查询数据量，以及语法的使用都是有关系的。

再加上我们写的语句，多表联查（带 join 的语句）的执行效率低，因此会出现这种情况。

当然，这也是我朋友遇到过的，我自己没真实搞崩过。

不过开发也确实提醒过我，尽可能用 inner join 查询，而非 left join。

inner join：内连接，在两张表进行连接查询时，只保留两张表中完全匹配的结果集。

left join：左连接，在两张表进行连接查询时，会返回左表所有的行，即使在右表中没有匹配的记录。

同时，还需要界定查询数据的时间范围，可能就是担心我把数据库搞崩掉吧。

所以大家在查询的时候，还是要留意一下的。

写在最后

话说，从今年 7 月到现在的 11 月，我决定按上图的产品流程，对工作中所接触的内容做复盘总结，到现在总共写了 15 篇文章了。

今天这篇是最后一篇，至于其他没写到的，都是因为自己工作中没接触到。

不得不说，这段时间的复盘还是蛮有意义的，让我发现了自己很多的不足，因此也决定今年再学一门网课提升自己。

人生就是这样，生命不息，奋斗不止，愿你我一起加油~

-END-