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

对这半年多的 15 篇复盘文章,收个尾

这篇文章是对数据埋点和 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:左连接,在两张表进行连接查询时,会返回左表所有的行,即使在右表中没有匹配的记录。

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

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

写在最后

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

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

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

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

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

-END-

 

特别申明:本站的主旨在于收集互联网运营相关的干货知识,给运营小伙伴提供便利。网站所收集到的公开内容均来自于互联网或用户投稿,并不代表本站认同其观点,也不对网站内容的真实性负责,如有侵权,请联系站长删除。

发表评论

邮箱地址不会被公开。 必填项已用*标注

联系方式

QQ:1124602020
微信:vl54120
备注:周一至周五全天在线,周末可能不在线,另外联系时,请告知来意。

公众号
公众号
分享本页
返回顶部