数据分析师

把「上个月多少用户做了 X」翻译成 SQL,并把结果接进一张别人能刷新的图表。

把经理模糊的担忧变成一个可度量的问题,并知道他说的「活跃用户」是哪个定义。

发现坏掉的管道、重复的事件、时区 bug、三月份改过的定义。

呈现一项发现,让必须据此行动的人理解它、相信它、并且真的去做。

维护让自然语言查询产出正确答案的指标定义、文档与语义层。

● 本职业有 1 条已核实事件,按真实发生日期标在轴上 —— 靠近标记的那几段曲线是有可核对的东西锚定的。

一家公司的有限发布;Uber 平台每月约 120 万次交互查询,此工具占比很小。原文自陈幻觉出的表/列与提示质量仍是未解问题。

企业已正式投入使用。可以改变基线,但要结合规模与场景相似度加权。

仅靠 SQL 能力入行比以前弱了,因为那正是工具在做的部分。更强的入口是「领域 + 数据」:把一个业务领域学到足以知道它的数字意味着什么、会怎么出错,查询交给工具。主动接下「写指标定义文档」这种不显眼的活 —— 新的分析师角色正在那里成形,而现在几乎没人愿意做它。

如果你一周大部分时间在满足报表需求,预期这个队伍会随着需求方自助而缩小,并预期你会以「你的工作改变了什么决策」而不是「交付了多少看板」被衡量。你积累的「数据在哪会出错」的知识是资产。把它变成语义层和指标定义,你就成了自助工具能给出正确答案的原因。

调整职责

从回答问题到拥有定义

自助分析把瓶颈从写查询转移到底层指标是否正确。拥有那一层比拥有一张看板更耐久、也更资深。

相邻转岗

转分析工程

在上游构建清洗数据的模型和管道,是大量分析师精力正在转移去的地方,而且报酬高于做报表。

相邻转岗

嵌入业务部门的分析师

财务、运营和产品团队越来越想要一个懂领域的自有分析师,而不是一个接工单的中央服务。领域知识就是护城河。

值得,但理由和以前不同。你写的会更少,读和检查的会多得多。理解一条查询在做什么,是让你抓住工具在含混表结构上给出的那个自信错误答案的能力 —— 而这个「抓住」现在就是工作本身。像编辑懂语法那样学 SQL:不是为了亲自写每一句,而是为了一眼看出哪句错了。