你好,游客 登录 注册 搜索
背景:
阅读新闻

一个成功的数据分析团队:角色与职责

[日期:2015-12-18] 来源:互联网分析沙龙  作者: [字体: ]

  多年以来我和数百家企业打过交道,在这个过程中,我领悟了让数据分析项目成功的一些因素,也亲眼看着很多项目失败。

数据分析

  最常见的失败原因说出来可能会让你惊讶。并非是缺乏数据专业知识或者整合失误,而仅仅是因为企业没有让 “ 利用数据 ” 成为任何人员的职责。太多公司花费好几个月收集有趣的数据,然后让它们静静地躺在角落里积攒灰尘。这个现象驱使我来撰写本文,希望它能给你灵感,让你为下一个分析项目增加一些结构性。 对分析的应用,本应该成为你不断汲取的商业泉源。

  如果能为下列每个角色,找到至少一个乐于担当的人选,我保证你项目成功率会增加一千倍!对每个角色的具体描述和建议见下文。

  * 并未经过科学证实

  角色及其输出

角色

交付

项目领导者

项目规划,包含工作范围与时间

数据建构者

数据模型,查询语句

产品开发者

实现跟踪(埋点)

分析者

提供新的业务问题

报告制作者

为业务提供报告

  项目领导者

  有一个团队成员要负责分析工作的实施交付。你可能已经知道,一个高效的项目管理者要:

  识别项目的利益相关者,并搞清他们需要什么。这些人会问 “ 我们要回答的商业问题是什么? ”

  设定并传达工作目标、范围和时间,落实到每个相关人员。

  管理项目所依赖的资源,发现交付过程中的障碍。

  确保项目如实交付、达成目标(例如,数据确实回答了对业务至关重要的问题)。

  确保每个相关人员,从工程师到产品经理,同步工作并理解要交付什么。这个部分比较重要,因为人们通常低估或高度数据的作用。

  对项目领导者的建议:

  如果你专注于那些可以直接为产品或业务带来改变的问题,你的分析项目会得到最及时的反馈。例如:新的宣传活动带来的顾客是否转化为付费用户了(是否该继续在这个宣传渠道上继续投资)?或者,我们准备取消这个功能,你能否查看一下是否有付费用户在使用这个服务?

  保证项目的规模尽可能小。一开始,只跟踪对于业务重要的少数几个关键行为,这样就能够快速回答最紧迫的商业问题(如,使用这个此功能的用户留存度如何?)及时的,有用的分析结果会让你所在的机构着迷,他们很快会提出更多你在下一轮要回答的问题。换句话说,分析工作应该是敏捷的,随着每次迭代更加深入。如果分析项目的规模太大(如,需要花费工程师两周时间),那你可能冒着拖延其他紧急项目的风险。

  数据建构者

  这个头衔听起来很炫,但它只是意味着你的团队需要有个懂技术的人创建数据模型,并理解查询语句如何工作。数据模型可以很简单,甚至像一封电子邮件,列出你要跟踪的行为和优先级。这个模型有助于确定和传达你的项目范围。数据建构者帮助整个团队评估哪些业务问题可以被回答,哪些不能。通常这个人不必是数据科学博士,一般由一个 app 开发人员,或者懂得用电子表格建立模型的人担任。

  对数据分析者的建议:

  花点时间让曾经使用过相同工具的人看看你的数据模型。例如,如果你在使用 Keen,就跟使用过 Keen 的开发者聊聊。也可以让分析服务提供者和你一起审阅你的数据模型。不管你在使用什么工具,都会有些事情需要取舍,解决方案总有些部分不会按照预期工作。节省些时间,跟有过相同经历的人谈谈你的计划吧。

  建立数据模型时,使用客户和业务领域的习惯用语,而不是应用开发者的习惯用语。例如,不要去追踪 “ 阶段变化 ” ,客户和你公司里的其他人无法理解它。如果能保证使用的语言是业务导向的,它会帮助你的机构 / 企业理解如何去查询和使用数据。

  保证让至少一个人审阅你的数据模型,保证模型可被他人理解。你可能会发现有些对自己来说很直白的标签,对其他人来说并不清晰。比如,对于机构里的不同人员,“uuid” 意味着不同的东西。

  不要重复发明轮子(不要做无用功)。

  产品开发者

  项目一开始,就要有至少一个开发人员承担埋点的工作。他们在各处加一些代码,这样每次登录、购买、上传和其他行为的数据都能被保存。如果事件的来源有很多,比如移动应用 + 网页,这个工作可能由多个开发者完成(如,一个网站开发者和一个移动开发者)。在小一些的机构,埋点的开发者通常也扮演数据建构者。在大一些的团体中,开发者和数据建构者紧密合作,确保模型数据足够理想,以及事物被跟踪并以一致的格式标记(如 “user.id” = “23cv42343jk88” 不是 “user.id” = “fran@cooldomain.com” )。埋点是个相对直接的过程,许多分析服务有直接可用的客户库使得此过程简化,不过,你的团队依然需要决定要跟踪什么行为,如何命名。

  对产品开发者的建议:

  确保根据对你的机构有意义的数据模型进行埋点。如果你的团队没有数据建构者,那么就扮演这个角色,在开始埋点之前规划一个模型。这会帮你理清思路,也更利于与他人沟通。

  使用分开的 repository ,带有各自的 key ,针对 dev, test 和 prod ,这样就不会让生成数据和测试数据混淆。

  埋点成功后,在正式使用前找个人审阅一下存进来的数据。和产品的其他功能一样,分析的实施也需要有个 QA 过程。埋点过程中错误很常见,如,把数字发送为字符串、命名不清、不正确地使用 JSON 的格式,或者标签里有错别字。

  分析者

  你会收集很多有意思的数据,但如果没人利用,这些数据就不会有价值。团队里需要至少有一个人对数据背后隐藏的东西非常好奇。我把这些人称为分析者。分析者通常是个开发者、产品经理或产品团队 / 营销团队的某个人。这些人不仅疯狂地想了解业务问题的答案,还能时时提出新问题。分析者喜欢钻研项目第一阶段收集的数据,而且有很多点子,引出下一阶段应该收集的新东西。换句话说,团队中需要有个人享受实践分析的过程。不要着急,这样的人有很多 :) 。技术背景对这个角色有很大帮助,这使得他们能快速理解什么样的查询语句可以得到想要的答案。这个角色对于项目成功至关重要,如果没人从数据中理解、学习,就无法从中得到任何价值。

  对分析者的建议:

  分析的结果可能对你自己而言显而易见或很有意义,但别人看来可能不是这样。这是因为 03 你从一开始就知道要回答什么问题。你知道数据包含哪些不包含哪些。此外你写的查询语句最终生成了可视化结果或报告。要让他人理解最终得到的数字都意味者什么,那么你要分享很多上下文内容给他们。

  分享分析的结果时,需要写明你从数据中得到的结论,以及根据分析结果应该采取什么业务行动(如,上个版本发布后我们的转化率下降了,所以应该改回去)。其他人可能不仅没有正确解读数据所需的上下文,他们也很可能不像你那样感觉数据很迷人,且没时间去试图理解其意义。

  不要用力过猛,不过,对于这个岗位来说沟通技巧很重要。分析者大约半数的时间都用在了沟通上。解释与总结从数据中获得的结论、结果需要花点时间。如果你的分析结果不能只是静静躺在别人的收件箱里。有些你是机构里唯一意识到某个机会或问题的人,应该确保机构对机会或问题有所反应。有时你得做那个难搞的人。不要低估自己工作的价值。

  如果分析工作是你常常要做又来不及做的,试着把它加入你官方的职位描述中,每周或每月贡献固定时间在上面。不要让它干预你的其他时间。

  报告制作者

  这个角色不是必需的,但你可能会想要制作一些报告,便于整个团队和其他利益相关者获取。要想让数据的实用性会大大提升,数据应该更紧密地与业务流程相连,而不是被遗弃在数据库里等着有人翻阅。一个前端开发者要能够把 query 变成产品经理和其他业务人员阅读的报告。下面是一些可能有用的例子:

  Email 寄送周报

  内部网站的一个页面

  在面向用户的 app 中

  用 Google 表格公开发布

  推送到 slack 频道

  在某个面板上展示

  推送到 salesforce

  对报告制作者的建议:

  确保报告的使用者能理解数据才能让你的工作产生最大价值。一个办法是,不断问他们 “ 当你看到转化率 5.2% 时,这对你来说意味着什么?你会认为它是怎么计算出来的? ”

  另一种提高报告可读性的方式是写一份指南(如注释),以解释数据从何而来、如何被计算。例如,数据是否包含从网站和 app 获取的用户,或只是来自其中一种的用户?它是否包括测试用户和公司的内部用户,或者他们已经被过滤掉了?

 

  玩得开心点!整个分析项目中最棒的部分,就是看着有人因为从结果学到了新东西而双眼放光,而你,通常就是让这一切发生的人。





收藏 推荐 打印 | 录入:elainebo | 阅读:
本文评论   查看全部评论 (0)
表情: 表情 姓名: 字数
点评:
       
评论声明
  • 尊重网上道德,遵守中华人民共和国的各项有关法律法规
  • 承担一切因您的行为而直接或间接导致的民事或刑事法律责任
  • 本站管理人员有权保留或删除其管辖留言中的任意内容
  • 本站有权在网站内转载或引用您的评论
  • 参与本评论即表明您已经阅读并接受上述条款