发帖
雷达卡
摘要：多年以来我和数百家企业打过交道，在这个过程中，我领悟了让数据分析项目成功的一些因素，也亲眼看着很多项目失败。
多年以来我和数百家企业打过交道，在这个过程中，我领悟了让数据分析项目成功的一些因素，也亲眼看着很多项目失败。
最常见的失败原因说出来可能会让你惊讶。并非是缺乏数据专业知识或者整合失误，而仅仅是因为企业没有让“利用数据”成为任何人员的职责。太多公司花费好几个月收集有趣的数据，然后让它们静静地躺在角落里积攒灰尘。这个现象驱使我来撰写本文，希望它能给你灵感，让你为下一个分析项目增加一些结构性。 对分析的应用，本应该成为你不断汲取的商业泉源。
如果能为下列每个角色，找到至少一个乐于担当的人选，我保证你项目成功率会增加一千倍!对每个角色的具体描述和建议见下文。
*并未经过科学证实
角色及其输出
项目领导者
有一个团队成员要负责分析工作的实施交付。你可能已经知道，一个高效的项目管理者要：
- 识别项目的利益相关者，并搞清他们需要什么。这些人会问“我们要回答的商业问题是什么?”
- 设定并传达工作目标、范围和时间，落实到每个相关人员。
- 管理项目所依赖的资源，发现交付过程中的障碍。
- 确保项目如实交付、达成目标(例如，数据确实回答了对业务至关重要的问题)。
- 确保每个相关人员，从工程师到产品经理，同步工作并理解要交付什么。这个部分比较重要，因为人们通常低估或高度数据的作用。
对项目领导者的建议：
- 如果你专注于那些可以直接为产品或业务带来改变的问题，你的分析项目会得到最及时的反馈。例如：新的宣传活动带来的顾客是否转化为付费用户了(是否该继续在这个宣传渠道上继续投资)?或者，我们准备取消这个功能，你能否查看一下是否有付费用户在使用这个服务?
- 保证项目的规模尽可能小。一开始，只跟踪对于业务重要的少数几个关键行为，这样就能够快速回答最紧迫的商业问题(如，使用这个此功能的用户留存度如何?)及时的，有用的分析结果会让你所在的机构着迷，他们很快会提出更多你在下一轮要回答的问题。换句话说，分析工作应该是敏捷的，随着每次迭代更加深入。如果分析项目的规模太大(如，需要花费工程师两周时间)，那你可能冒着拖延其他紧急项目的风险。
数据建构者
这个头衔听起来很炫，但它只是意味着你的团队需要有个懂技术的人创建数据模型，并理解查询语句如何工作。数据模型可以很简单，甚至像一封电子邮件，列出你要跟踪的行为和优先级。这个模型有助于确定和传达你的项目范围。数据建构者帮助整个团队评估哪些业务问题可以被回答，哪些不能。通常这个人不必是数据科学博士，一般由一个app开发人员，或者懂得用电子表格建立模型的人担任。
对数据分析者的建议：
- 花点时间让曾经使用过相同工具的人看看你的数据模型。例如，如果你在使用Keen，就跟使用过Keen的开发者聊聊。也可以让分析服务提供者和你一起审阅你的数据模型。不管你在使用什么工具，都会有些事情需要取舍，解决方案总有些部分不会按照预期工作。节省些时间，跟有过相同经历的人谈谈你的计划吧。
- 建立数据模型时，使用客户和业务领域的习惯用语，而不是应用开发者的习惯用语。例如，不要去追踪“阶段变化”，客户和你公司里的其他人无法理解它。如果能保证使用的语言是业务导向的，它会帮助你的机构/企业理解如何去查询和使用数据。
- 保证让至少一个人审阅你的数据模型，保证模型可被他人理解。你可能会发现有些对自己来说很直白的标签，对其他人来说并不清晰。比如，对于机构里的不同人员，“uuid”意味着不同的东西。
- 不要重复发明轮子(不要做无用功)。
产品开发者
项目一开始，就要有至少一个开发人员承担埋点的工作。他们在各处加一些代码，这样每次登录、购买、上传和其他行为的数据都能被保存。如果事件的来源有很多，比如移动应用+网页，这个工作可能由多个开发者完成(如，一个网站开发者和一个移动开发者)。在小一些的机构，埋点的开发者通常也扮演数据建构者。在大一些的团体中，开发者和数据建构者紧密合作，确保模型数据足够理想，以及事物被跟踪并以一致的格式标记(如“user.id” = “23cv42343jk88” 不是 “user.id” = “https://keen.io/blog/133424159331/roles-responsibilities-of-a-successful-analytics
提升卡
置顶卡
沉默卡
变色卡
抢沙发
千斤顶
显身卡
京公网安备 11010802022788号
