登录
首页精彩阅读观点 | 构建数据产品:那些年我们走过的弯路
观点 | 构建数据产品:那些年我们走过的弯路
2016-05-20
收藏
导读:

“从一开始,你就得考虑怎么保持数据整洁,否则你就麻烦了。我敢保证。”

提供的数据太多,用户就会不知所措,一片茫然。

很多数据产品的成熟都需要时间,催生出进一步改善所需的信息也需要时间

构建数据产品的正确切入点只有一个:弄清楚你该如何评估其表现,以及如何构建评估工具。

你必须投入大量的时间和精力去监控数据质量。你需要像监控网站的服务级别协议(SLA)一样。

原文翻译:

“我们说些什么,才能帮大家避免系统故障和数据损坏带来的痛苦、烦恼和熬夜工作?”

在最近召开的首轮资本(First Round)CTO峰会上,DJ帕蒂尔(DJ Patil)以此作为开场白。帕蒂尔是前RelateIQ产品副总裁,现任美国首席数据科学家,他说,若要把他走过的所有弯路和从中升华出来的所有教训总结起来,20分钟是远远不够的。和他同台的还有现任Salesforce工程副总裁鲁斯兰·贝尔金(Ruslan Belkin,随原RelatedIQ一道加入Salesforce)。他说,他们此次演讲的目标是挑最重要、最关键的误区和教训,与大家分享数据产品的构建与发布问题。

第一个常见误区,就是以为“数据产品”仅指Twitter或LinkedIn这样的应用,以为社交图谱就是一切。其实,它所囊括的产品越来越多,包括硬件、可穿戴设备等任何收集数据、帮用户理解数据的东西。对此,贝尔金和帕蒂尔给出了他们的建议,而且这些建议也适用于整个初创企业生态系统。

“一旦扩大数据产品涵盖的范围,你就会意识到,即便是内部控制面板都至关重要。你的视野瞬间开阔起来,你可以规模化地理解、制造并销售东西。”帕蒂尔说。那么对构建有用的数据产品这件事,为什么很少有公司会去讨论或强调呢?为回答这个问题,帕蒂尔引用了著名经济学教授丹·艾瑞里(DanAriely)的话:


“大数据就好比青少年性行为:所有人都把它挂在嘴边,没有人真的知道究竟,大家以为所有人都在做,于是所有人都宣称自己在做……”

说到底,规模化地构建数据产品着实不易。贝尔金和帕蒂尔分享了很多从摸爬滚打中得到的经验,很多独到的战术,便于大家创建大胆的新产品,以改变我们观察世界并与世界建立联系的方式。

数据产品的构建方式与众不同

如果只是把东西组合起来做成原型,这个过程并没有什么难度,数据产品也不例外。但规模化会带来一大堆独特的难题。你心里得有一个进度规划。这些产品从来不是一次性的或孤立的。所以你不能按以往的流程来走,它不是简单地构建、测试、发布就可以了的。

首先你要有一个基本观念:数据是极度凌乱的,数据清理永远要占去你80%的工作量。换言之,数据才是问题所在。

“比如在早年的LinkedIn,人们光是描述自己在IBM的工作经历,就有几千种不同的说法——IBM、IBM研究,软件工程师,各种缩写,诸如此类。”帕蒂尔说。

“从一开始,你就得考虑怎么保持数据整洁,否则你就麻烦了。我敢保证。”

“事后再要清理起来,至少要花上几个月的时间。”

要避免这种困境,你应该从建构简单产品着手——超级简单的东西,纯粹的计数,就比如协同过滤器,只有0和1两种数据。在规模化实施中,这一切都会变得复杂得多。“如果构建的是机器学习这种野心不小的东西,你注定要栽跟头。关键是把产品管道这些东西弄妥,在此基础之上,再慢慢构建产品。”

向用户反馈数据要切中要害

这方面的一个最佳例证还是来自LinkedIn。它有一个机制,显示最近有谁浏览过你的个人资料。促使人们一次又一次地返回该网站的,正是这类信息。

“这里有一个常见误区:你知道向用户回馈数好处多多,于是你想,‘再多回馈一些,越多越好!’但网页数据量的增加其实和点击量成反比。”帕蒂尔说,“你必须在受众中找到一个平衡点。”

提供的数据太多,用户就会不知所措,一片茫然。

决定把哪些数据呈现给用户的时候,你不仅仅要考虑到量的问题,还要考虑到它们透露出什么讯息。帕蒂尔和贝尔金考虑过向用户推荐职位,就比如“您应该申请这个职位,您的技能与之匹配!”但很快他们就意识到,这样做风险不小。

“一不小心,我们就可能推荐一位资深人士去申请某个实习职位,或者让某位证实为加州居民的用户搬到爱达荷州工作,这种情况极有可能发生。一旦发生,就会把用户惹毛,你的牌子很快就砸了,”帕蒂尔说,“你必须站在用户的视角来体验特定功能。这时候你就需要偷巧——在数据产品领域内,偷巧十有八九会胜过英明。”

在这种情况下,偷巧的解决方案就是换个角度来推荐职位。比方说有一位用户叫“比尔”。他们不直接向比尔推荐工作机会,而是引导他到自己的人脉网络,外加一条简短注释:推荐比尔申请该职位。算法还是原来的算法,只不过语句变了一下,硬相关可能造成的各种问题就迎刃而解了。

“如果一个朋友推荐比尔申请某份工作,比尔还是有可能会说,‘哦,是吗,你个混蛋。”但这种情况就比较少见了,而且他们永远不会怪到网站头上,”帕蒂尔说。“除此之外,我们还能收集这方面的数据,弄清楚这一功能的具体运转,并不断地加以完善。”



没时间尽善尽美,但有时间从头再来

这是贝尔金的口头禅,强调了“是骡子是马,拉出来溜溜”,掌握更多的情况,再加以迭代。

前段时间,LinkedIn构建了名为“人才自动匹配”的产品,目的是让企业在发布职位空缺之后,能看到适合职位描述的最佳推荐人选。一开始,效果相当不错,但进入规模化阶段,各种复杂问题就接踵而至。

“我们不得不在所有系统上迭代个遍,才找到了最完美的功能组合,以及合适的评估框架。不然大规模的构建就无从下手。”帕蒂尔说。

很多数据产品的成熟都需要时间,催生出进一步改善所需的信息也需要时间。

“这很难,就连苹果公司有时都会因为数据产品质量低劣,不得不向用户道歉,并推荐竞争对手的应用程序。”贝尔说。不论规模大小和技术水平高低,哪家公司都逃不过这个问题。

在LinkedIn,“猜您认识”这项功能最初是一名工程师笔记本上的一个大型python脚本。但一直到2008年,也就是该功能推出两年之后,它才开始对平台的壮大起到显著的推动作用。

Twitter搜索功能也是如此。一开始,它作为一项工具面向Twitter用户推出。但直到2013年年中,它才成为Twitter点击与参与度的主要驱动力之一。

“如果要推出一个复杂的产品数据,永远不要采用一个固定的时间表。”


DJ.帕蒂尔在旧金山的CTO峰会上发表演讲。

构建数据产品该从何处着手

很多人都从产品建模入手,有的从功能发现或功能设计入手,还有的一开始就构建基础设施,为结果的规模化呈现做准备。但对贝尔金来说,构建数据产品的正确切入点只有一个:弄清楚你该如何评估其表现,以及如何构建评估工具。

“迄今为止,我工作或接触过的每一家公司都无一例外地面临这个问题——数据质量差,尤其是跟踪数据,”他说,“不管是数据不完整,跟踪数据丢失,还是跟踪数据重复。”

为解决这个问题,你必须投入大量的时间和精力去监控数据质量。你需要像监控网站的服务级别协议(SLA)一样,仔细监控数据质量并做出响应。应当把数据质量缺陷作为重中之重。若发现数据质量问题,不要不敢叫停某个版本。但比尔金说,有一件事你绝对不能做:

“要是发现数据质量问题,千万不要草率地把产品提交给应用商店,”他说。“你要做的是确保自己工具齐备,跟踪的所有事件有一个扎实的架构,以及一个架构注册表,以整合到你的开发流程中去。”

为进一步强调这些教训,贝尔金在每次员工会议的开头,都要简短审视一下内部操作面板。这个面板他每天都要看20 次以上,但他发现,围绕它展开积极讨论,能让很多问题和潜在问题及时浮出水面。因此,它们还没有机会造成什么破坏,就被解决掉了。

产品发布前的核验清单

在面向用户推出数据产品之前,应该过一遍这样一份清单:

一、产品必须能正常运作

在职业生涯早期,贝尔金曾在网景公司(Metscape)工作,他记得当时的CEO吉姆·巴克斯代尔(Jim Barksdale,曾任职于联邦快递)曾说:“如果100天里面,每天有1%的包裹错过配送,那么因此而失望的客户群体就已经相当可观。”你需要考虑的是,用户看到坏结果的频率有多高?

把同样的道理应用到科技消费产品领域:“消息流中每三个月出现一次色情消息的话,用户能否接受?每六个月出现一次呢?每九个月呢?”贝尔金说。“你必须搞清楚哪个水平是可以接受的。”

如何应对令人尴尬的内容和推荐?这也是一个需要注意的问题。“不论你做得多好,出错总是在所难免。你会怎么处理?你会不会赶忙把软件滚回先前版本?你会不会跑到已经开始运转的生产系统中,修改数据库中的一条记录,试图纠正问题?你会不会从搜索索引中撤回一些东西?会不会去提升某个系统的排名,虽然它已经开始运转?以上做法通常都不太好。你应该提前预料到这方面的可能性,制定好随时可以部署的解决方案。”

二、产品必须对用户有意义

你必须站在用户的视角,审视你呈现给他们的所有东西。用户看到的信息,必须能与某些具体情况联系起来——可能是因为他们关注了某个用户,也可能是因为他们采取了某一行动,甚至可能是因为没有采取某一行动。

重要的是,如果某些数据或信息与用户毫无瓜葛,在用户与你的品牌或产品的互动历史中从未涉及到过,那最好不要呈现给用户。没人想看到无缘无故出现的东西。模棱两可会让你失去用户。



举个例子,你打开某人的Twitter主页,上面会显示此人的关注者中,有多少是你认识的人,这样,你关注此人的可能性就会大大增加。关注就成了水到渠成之事。

三、必须给用户以安全感

“我称之为泰迪熊原则,”贝尔说。“扪心自问,‘有没有任何方面让用户觉得你的产品鬼鬼祟祟或对他们不利?’事实情况不一定如此,但久而久之,用户对这些问题的感知会有损于你的平台。”

首先,你必须确保用户的个人身份信息无论如何都不会泄露。这可不是闹着玩的。总是会有这样的风险存在,它可能是由于产品设计或实施中某个缺陷。你可能会被黑客攻击。有些数据可能没有妥善加密或匿名。这些都事关重大。你必须尽一切力量防患于未然,并通过良好的设计和扎实的用户体验,让用户吃下定心丸。决定用户是否信任一个产品的,往往都是一些微乎其微的细节。

四、让用户感到一切尽在掌控

用户设置——特别是隐私设置——的呈现是非常重要的。不能让用户感到无从下手,要将选项明确呈现给他们,让他们感到自己能全盘掌控自己的隐私,如分享给谁、何时分享等。权衡再三,制定出最佳方案。用户会不会回头访问,往往就看这一点了。

五、本国以外的用户

很多美国企业竟然都没有意识到,他们的大部分用户都生活在美国以外。“按照我的经验,和你的公司有关的语言可能多达35种。通常,换成别的语言,数据和选项就会缩水。很多用户会说多种语言。如果不大量投入额外的努力,你就无法向所有用户提供同等质量的体验,除非你本来就不打算这么做。”贝尔金说。

即便你的初创企业还很小,没有足够的资源去考虑国际化,你也需要为这些问题的解决打下基础。你不能做一个纯英文的大型产品做了很久,然后有一天突然想拓展到35种语言以上。如果你拥有全球野心,就得趁早做好这方面的铺垫。

如何组织团队

贝尔金老是被问到这个问题:如果要构建并迭代的产品不止一个,产品与工程团队又该如何组建?怎样的人员配置才是合理的?

“这就不得不提到一个古老的争论:是走垂直方向呢,还是水平方向?”正确答案是哪个?



“这里并不存在一个普适的正确答案,要看公司所在的阶段,不同阶段有不同的正确答案,”贝尔说:“我喜欢把它想象成一个特征矩阵,就像这样:”

“评估一下你在这些层面做得怎么样?——执行速度、创新、代码质量、用户满意度有多重要?产品的构建与规模化需要怎样的团队间互动?”

一般来说,在执行速度或创新方面,垂直整合的团队更胜一筹。大家更开心,外部关系更为融洽,因为团队跟企业的目标是一致的。

平行团队的产出质量通常更高。他们更加高效,通常团队间的互动会更好。

真正的关键是保持实验和迭代,不只是针对产品,也是针对产品构建方式。你无法一口气解决工作方式的问题。不断产生的新数据可以利用起来,重新投入到流程中去。不要指望一开始就马到成功,特别要注意的是,随着受众群体和企业规模的增长,难度是会逐级上升的。

“对于构建数据产品,我们有一个很好的比喻,”贝尔说。“它就好比是爬山。你前有古人,后有来者。有一些路是还没有人走过的,但只要有信心,一步一步地来,你一定能到达峰顶。”

原文: Everything We Wish We'd Known About Building DataProducts

来源:http://firstround.com/review/everything-we-wish-wed-known-about-building-data-products/

翻译 | 车品觉

译文来源 | 品觉公众号


数据分析咨询请扫描二维码

客服在线
立即咨询