产品经理与 SQL 那些事儿

产品经理与 SQL 那些事儿

时间:2020-4-5 作者:抖音代运营

无论B端还是C端,向数据要增长练业务内功,正成为业界共识,数据产品经理也越来越热,但我们看数据产品经理JD,懂SQL是基本条件,SQL作为数据库操作语言,重要性也在提高,本篇就探讨下,产品经理与SQL那些事儿。

懂SQL价值

随着各种业务增长逐步达到瓶颈后,采用各种手段都不好使了,通过数据分析精细化运营而非既往粗放式增长模式,正在成为新的救命稻草。SQL 和数据分析正在被提到前所未有的高度。

当年刚入行产品时,乐视还是风口上的公司,曾去乐视几个办公区面试,其中有个岗位招聘的主要要求便是产品经理需要懂SQL,在那个移动客户端占主导的产品经理时代,对于新人还是很难理解,为什么需要会SQL会成为应聘产品经理的硬性条件。

后入行做产品经理后,发觉不同职位和不同部门之间,很难用逻辑或感觉当成共同语言,拿数据说话才是更为通用的语言。当初有个数据组,为运营、市场、渠道、老板、产品等部门提供数据服务,新功能上线,都会找数据组要数据,证明产品价值。但数据组人力有限,下游方却比较多,尤其遇到数据问题时,排查问题更是占据大量时间,导致产品提的数据需求,并不能即时得到满足,甚至需要排期到一周甚至更久。

做B端产品业务后,发现以上这种数据组服务瓶颈的问题,在各家公司中普遍存在。于是对于学习能力比较强的产品经理来讲,学SQL自行取数和分析,显然是能够更加高效进行产品迭代和验证的方式。因此懂SQL更像是对数据组服务能力的,无声抗议。

数据产品价值

当产品经理聚焦于业务时,显然不会太关注一群产品、运营或市场人员,熟练使用SQL是不是个问题,但SQL作为数据库操作语言,确实对于很多没有编程经验的工作人员来讲,不够友好。

于是市面上有些公司或自研或采购数据分析工具,这些数据分析工具将SQL取数界面化和可视化分析做无缝结合,大大降低查询和分析的门槛,是一种对于各个业务方更为友好的工具。

但市面上越强大的数据分析工具,便会面临灵活度高,但上手成本也高的问题。能使用好数据分析工具至少需要满足三点:懂业务、懂数据、懂SQL。这样才能在既定分析目标下,将对应的数据正确的取出来,即虽然省去了写SQL的成本,但仍需要懂将分析目标与SQL取数原理进行结合。

经过几年的产品从业经验,有了更多的业务经验和认知,此时提数据需求和分析需求更为熟练,大量的业务经验积累,导致即便没有刻意学习SQL,也清楚了应该取哪些数据做何种分析。

SQL基本原理

数据被采集并存储到数据库后,对于业务人员来讲通常需要做的是基于已有的数据做查询和分析。

在SQL中使用最多的便是查询操作,即解决从哪张表按什么条件查询哪些行和字段的需求,通常采用select…from…where…order by…类似的语句将符合条件的数据行取出来作为结果。

但对于业务量大的情况,并不需要将每一行一一打印出来,也没有太多意义,业务视角更多关注的是统计学上的意义。例如互联网产品通常关注的指标日活(DAU)、月活(MAU);内容类关注的平均内容点击数,电商行业关注的交易额。就需要对某些数做汇总计算或四则运算,SQL中的聚集函数和构造计算字段可以分别解决以上问题。

通常情况下,并不会使用一张数据表解决所有信息存储问题,例如用户行为数据中,并不需要将一个用户的全部属性存储上,既不安全,如果用户属性有变,大量更新存量数据也不利于维护。因此通常会构造不同的数据表,不同表之间通过主键关联,解决数据唯一性和关联查询的问题。从数据分析角度来讲,实现关联表的关联后,也便于做多维度分析,便于分析下钻找到问题的关键点。

昨天与朋友去通州,其表示做数据分析的工具没有核心竞争力,显然其对于数据分析了解不是很多,在复杂分析场景下,数据分析工具的查询性能显然是核心竞争力。在推荐系统中,为了保证推荐结果下发的性能,提前做好查询「索引」,能够有效提升查询效率。当然查询性能还有事务表和维度表等种种优化方式,很多竞争力都在水下,而非见到的界面功能,因此分析业界才会有B端少有的,将产品demo都挂官网上,而不担心被抄袭。

做数据产品,并非需要天天手写SQL,但至少需要将SQL使用、业务需求、分析方法有机结合,如果有兴趣,推荐读读《SQL必知必会》,在心里,建立起SQL的使用模型。

028-84360888 13608068886(推销勿扰) 发送短信