Ben Porterfield：数据就是我们的生命线

译者注：很多人坐在数据的金矿上而视若无睹，特此翻译了这篇文章，希望引起大家的重视。

Ben Porterfield：数据就是我们的生命线

Ben Porterfield 在自己的 Linkedin 主页这样形容自己：一个有经验的冲浪者。除了在 Santa Cruz 海岸冲浪以外，他还帮助一系列初创企业在变幻无穷的互联网浪潮中破浪前进。他是 Sticky, Inc.(译者注：一个成功的硅谷广告数据公司)的首席工程师，接着与小伙伴联合创立了 Rally Up (译者注：移动 APP 公司，2010年被 AOL 收购)。

他的经历，容易让人产生 “连续创业原来这么简单轻松啊” 的坑爹错觉。

Porterfield 的最新创业项目是 Looker, 一个商业数据分析解决方案提供商。Porterfield 带领着一帮工程师帮助小至初创企业大到行业巨头(比如 Etsy, Sony, Disney, and Yahoo)更好地做决策。Looker 帮助无数公司开发适合自己的算法，从而也更清晰地看到为什么会走这些弯路。

数据分析是一种经常被人视为假高大上的鸡肋工具。当你正在焦头烂额地为自己的初创公司设定市场定位的时候，你一定会把处理数据当做一种闲得蛋疼行为。但等公司走上轨道后，你需要更好地理解你的用户，而此时回头看之前积累得如同乱麻的原始数据，你会突然意识到你并没有很好地收集你想要的信息。

在本文中，Porterfield 将跟我们讲解创业者们如何可以从一开始就设计好数据分析的基本框架：将数据储存于何处用什么工具分析最好可以规避哪些常见的错误以及，今天的你如何亡羊补牢

听哥说，千万别等了

你的第一想法可能是由你团队里的工程师们胡乱拼凑点什么来储存这些数据。Porterfield 见过太多抱着这个想法而失败的公司。其实应该从一开始就投资更多的时间和金钱来寻找靠谱的数据收集分析工具。道理很简单：

每个人都需要方便地使用靠谱的数据。

把数据分析当做吃喝拉撒一样的日常基本需求，意味着让你公司的每一位成员，而不仅仅是技术人员，都可以便捷使用。每一个人，特别是直面客户的前线人员，都需要方便地获取及理解这些数据。而一个好的工具能帮助工程师以外的其他人都轻松地从这些原始数据中获得有用的信息，从而做出正确的决策。

而在建立这样的数据分析基础框架时，一定要考虑到如何让没有数理分析背景的小白使用者可以自主地设计数据跑出来的形式内容，因为这样的小白使用者往往更更理解产品业务流程，更能提出核心的问题。

Porterfield 还说到，若能把数据嵌入到各种唾手可得的日常应用中，企业能创造一种数据为导向的文化。从商业运营的角度来说，这样一个能自助生成数据的平台能释放原本专注于数据分析的工程师们，让他们更好地专注于产品设计或者是其他更高层次的问题。

企业的数据分析团队其实自身已成为许多公司发展的瓶颈。他们不应该像图书管理员似的，仅仅是按照别人的需求去读取和解读数据。Todd Lehr, Dollar Shave Club 的资深工程师分享了个类似的故事：有个叫 Juan 的开发者在公司负责生成所有数据报告。当他手头积压太多工作而卡壳时，我们也会因没有数据而无法顺利工作。我们把这种情况戏谑为 “Juan 式卡壳”。

而如果有一个良好的自助数据平台，企业则不需要聘请这样的专人负责管理数据，从而也避免了这样的 “Juan 式卡壳”。工程师们可以更好地专注于开发和优化产品。

The 6 Mistakes Smart People Make with Their Analytics

关于数据分析，聪明人常犯的 6 个错误：

帮助大量的公司梳理数据分析流程后，Porterfield 总结出 6 个企业常走的弯路。

1. 走得太快，没空回头看路。

初创公司里的人们仿佛一直在被人念着紧箍咒：“要么快要么死，要么快要么死。” 他们是如此着急于产品开发，以至于他们常常没有空想用户对产品的具体使用细节，产品在哪些场景怎么被使用，产品的哪些部分被使用，以及用户回头二次使用产品的原因主要有哪些。而这些问题如果没有数据难以回答。

2.你没有记录足够的数据。

光给你的团队看呈现总结出来的数据是没有用的。如果没有精确到日乃至小时的变化明细，你无法分析出来数据变化背后看不见的手。如果只是粗放的，断续的统计，没有人可以解读出各种细微因素对于销售或者用户使用习惯的影响。

与此同时，数据储存越来越便宜。同时做大量的分析也不是什么高风险的事情，只要买足够的空间就不会有 system breakdown 的风险。因此，记录尽可能多的数据总不会是一件坏事。

不要害怕量大。对于初创企业来说，大数据其实还是比较少见的事情。如果正处于初创期的你果真(幸运地)有这样的困扰，Porterfield 推荐使用一个叫 Hadoop 的平台。

3. 其实你的团队成员常常感觉自己在盲人摸象。

许多公司以为他们把数据扔给 Mixpanel, Kissmetrics,或者 Google Analytics 就够了，但他们常常忽略了团队的哪些成员能真正解读这些数据的内在含义。你需要经常提醒团队里面每一位成员多去理解这些数据，并更多地基于数据来做决策。要不然，你的产品团队只会盲目地开发产品，并祈祷能踩中热点，不管最终成功还是失败了都是一头雾水。

举个栗子。有天你决定采用市场上常见的病毒营销手段吸引新用户。如你所愿，用户量啪啪啪地上来了。可此时你会遇到新的迷茫：你无法衡量这个营销手段对老用户的影响。人们可能被吸引眼球，注册为新用户，然后厌倦而不再使用。你可能为吸引了一帮没有价值的用户付出了过高的代价。而你的产品团队可能还在沾沾自喜，认为这个损害产品的营销手段是成功的。

这种傻错误经常发生。而如果你的企业在一开始就建立起人人可自助使用的数据平台，来解答他们工作中最重要的疑惑，则可以避免上文所说的悲剧。

4. 把数据存放在不合适的地方。

先让我们来看一个正确示范吧。Porerfield 提到他有个客户整合了 NoSQL, Redshift, Kitnesis 以及 Looker 的资源自创了一个数据分析框架。这个框架不仅能在很高的量级上捕获及储存自己的数据，还能承受每月数以百万计的点击流量，还能让所有人查询自己想要的数据。这个系统甚至可以让不懂 SQL 语言的小白用户们真正理解数据的意义。而在数据分析的世界里，基本上如果你不会 SQL, 你就完蛋了。如果总是要等待工程师去把数据跑出来，那就是把自己陷入困境。而工程师在不理解需求的情况下建立的算法或者买的软件对于使用者来说往往是个煎熬，因为他们对数据的使用往往与前者不再同一水平线上。

你需要让你所有的数据都存放在同一个地方。这个是关键关键最关键的原则。

让我们回到前文那个假设存在的公司。他们做了一个又一个病毒营销，但是没有把用户活动数据放在同一框架内，所以他们无法分析一个活动是如何关联到另一个活动的。他们也无法进行一个横跨日常运营以及活动期间的数据分析比较。

很多公司把数据发给外包商储存，然后就当甩手掌柜了。可是常常这些数据到了外包商手里就会变成其他形式，而转化回来则需要不少工序。这些数据往往是某些宣传造势活动时期你的网站或者产品的相关数据。结合日常运营数据来看，你可以挖掘哪些活动促成了用户转化。而这样结合日常运营数据来分析用户使用历程的方式是至关重要的。但令人震惊的是，尽管任何时期的所有运营数据都至关重要，许多公司仍不屑于捕获及记录他们。约一半以上 Porterfield 所见过的公司都将日常运营数据与活动数据分开来看。这样严重妨碍了公司正确地理解与决策。

5. 目光短浅。

任何一个好的数据分析框架在设计之初都必须满足长期使用的需要。诚然，你总是可以调整你的框架。但数据积累越多，做调整的代价越大。而且常常做出调整后，你需要同时记录新旧两套系统来确保数据不会丢失。

因此，我们最好能在第一天就把框架设计好。其中一个简单粗暴有效地方法就是所有能获取的数据放在同一个可延展的平台。不需要浪费时间选择一个最优解决方法，只要确认这个平台可以装得下所有将来可能用到的数据，且跨平台也能跑起来就行了。一般来说这样的原始平台能至少支撑一到两年。

6. 过度总结

虽然说这个问题对于拥有大数据分析团队的公司来说更常见，初创公司最好也能注意避免掉。试想一下，有多少公司只是记录平均每分钟多少销售额，而不是具体每一分钟销售了多少金额在过去由于运算能力有限，我们只能把海量数据总结成几个点来看。但在当下，这些运算量根本不是问题，所有人都可以把运营数据精确到分钟来记录。而这些精确的记录可以告诉你海量的信息，比如为什么转化率在上升或者下降。

人们常常自我陶醉于做出了几张漂亮的图标或者 PPT。这些总结性的表达看上去很令人振奋，但我们不应该基于这些肤浅的总结来做决策，因为这些漂亮的总结性陈述并不能真正反映问题的实质。相反，我们更应该关注极端值(Outliers)

The 3 Easiest Ways to Avoid These Mistakes

三个简单防护措施帮你少走弯路

少犯错误远比你想的重要，因为错误一旦发生，很容易耗费大量的工程时间和资源来弥补错误。如果不小心，你的工程师们可能花费昂贵的时间来为销售团队解码数据，可能错过无数宝贵的营销机会。每当数据变得难使用或者理解时，你的团队决策速度会变慢，因此你的生意进展必将受到拖累。

好消息是，如果你从有用户伊始就采用以下三个简单的防护措施，你一定可以避免走很多弯路。

1. 任命一个商业数据首席工程师

如果你能在团队中找到一个队数据分析真正有兴趣的工程师，你可以让他负责记录管理所有数据。这将为整个团队节省海量的时间。Porterfield 分享到，在 Looker, 这样的一个商业数据首席工程师负责写能记录所有数据的脚本，从而方便大家总是能在同一个数据库内获取需要的信息。事实证明，这是个简单有效的方法，极大地提高了团队的工作效率。

2. 把数据放在开放的平台上

Porterfield 强力推荐大家使用类似于 Snowplow 的开源平台，以能实时记录所有与产品相关的活动事件数据。它使用方便，有好的技术支援，可以放量使用。而最棒的一点，它能与你其余的数据框架很好的兼容。

3. 尽快将你的数据迁移到 AWS Redshift 或者其它大规模并行处理数据库(MPP)上

对于还处于早期的公司来说，类似于 Redshift 这种基于云端的 MPP 经常就是最好的选择。因为他们价格便宜，便于部署和管理，并且扩展性强。在理想状况下，你会希望从公司有记录之初就将你的事件与操作的数据写入亚马逊 Redshift 之中。“使用 Redshift 的好处在于这个平台便宜，迅速，可访问性高，” Porterfield 说。并且，对于那些已经使用 AWS 服务的人来说，它(使用 redshift)可以无缝接入你已有的架构中。你可以很容易的建设一个数据通道把数据直接传入这个系统中进行分析处理。“Redshift 能让你灵活的写入巨量的颗粒状的数据而并不根据事件触发量的多少这样难以估计的参数来收费，” 他说。“其它的服务会根据你储存事件的多少来收费，所以当越来越多的人使用你的产品时，越来越多的操作数据会被记录下来，这会导致最终的收费像火箭一样越升越高。”

如何用数据分析占领市场先机

数据分析的价值取决于它能如何帮助你占领市场先机。作为初创公司，所有的数据应该被用于你对公司不同阶段设立的目标上。

举个栗子。一个快递公司通常会检测平均送达每件货物的时间。这看上去是很关键的数据，但如果没有充分的上下文(毕竟收货人可能在一个街区外，也可能在几百公里外)，这也是没有意义的。另一个角度上，平均送货时间也没有收货人的整体满意度重要。因此，你必须确保你的分析囊括了正确的数据。

请列举量化你需要的结果：你希望你的客户体验是怎么样的一些常见的成功数据分析会基于销售或用户转化率(即如果客户做了叉叉事情以后会购买或者成为用户)，转化需要的时间，以及让客户产生负面体验的比例。你会希望第一个比例很高，而后两者降低。

通常来说，媒体网站会全然以网页浏览量论英雄。但现在他们也开始注意一个叫做 “注意力停留时长” 的指标：人们在某个页面专注多长时间，是否注意到某些字句，是否在上下拖动页面，是否有看视频，等等。他们不仅仅实在看用户在某个页面停留了多少时间，他们更需要知道用户被页面中的哪些部分吸引，且积极专注地浏览了多少时间。这样可以帮助媒体网站设计新的标题，页面设计和内容选择，以延长这样的注意力停留时长。这样，他们可以革新网站设计的方式，来更好地打动他们的受众。

另一个重点是监测留存用户。成功的数据分析可以同时涵盖日常运营数据以及活动数据，并横向分析。如果你仅仅看日常运营数据，你能指导那些人会回访你的网站，哪些人可以达成复购。但你还需了解哪些回访网站却没有复购的人群: 为什么他们不愿意再次购买这样的问题可以通过介乎运营与活动数据分析来找到答案。活动数据会告诉你哪些没有购买行为的客户按照何种顺序浏览网站，注意到了什么，点击了什么，在离开网站前做了什么。当你跟踪这个线路，你可以了解如何修改这种行为，来增加他们下次访问时购买的可能性。

为了设计最适合你的数据篮子，你可以参考以下三个建议：

寻找一类合适的用户行为
测算多少比例的受众会有这一类的用户行为
测试这一类用户行为是不是包含了重要的信息

有时候，发明一个新的数据记录篮子可以促成对公司很大的改变。

拿 Venmo (翻译君注：一个纽约的小额支付平台) 举个栗子吧。有段时间，公司的支付 APP 团队听说很多本想向朋友索取款项的用户不慎把钱反而支付给了朋友，因为 “索取款项” 和 “支付款项” 的按钮放在一块很容易按错。然而公司并不知道这个问题有多普遍，是否值得公司重新设计用户界面。为了更好地做决策，他们设计了一个新的数据系统来检测这个索取 / 支付失误有多常见。他们把 “A 向 B 付款后不久 B 双倍将款项付给了 A” 这种奇怪的支付行为全都找了出来。结果显示，这个情况经常发生。所以在下次的产品更新中，他们修复了这个问题。

让你的数据可分享。

阻碍团队轻松分享数据的罪魁祸首常常是数据的定义。因此，从一开始你最好充分完整地定义你的数据。可以考虑建立一个中央词汇表 wiki page, 来让每个成员更容易理解。Porterfield 指出，人们喜欢用奇怪的词语给数据明明。比如 “Ratio” 这个词就常备滥用，因为他们命名时常没有把分子分母讲清楚。

数据是大部分成功公司的生命线。好的数据分享不仅能增加公司的透明度，还能加强不同部门之间的协作。比如在很多公司里，不同部门常常会各自找工程师生成不同数据来回答同一问题。而如果有一个好的分享数据平台这样的浪费时间精力可以被避免。

另外，让数据形象化也是一个好平台能轻易做到的。把颗粒数据形象化为图表可以让团队的每一个成员更好地解读这些数据。对于大部分人来说，理解图表比理解表格容易得多，因此把数据形象化可以帮助交流更加顺畅。

不好的数据分析框架只会打击人们的自信心。它会无形地把公司分为两个派别：懂数据的大神以及不懂数据的白痴。这是个很常见的危险错误。你必须让公司最小白的数据用户都能轻松地生成自己需要的图表并理解它。这是选择数据平台的一个基本原则。

Poterfield 总结道：好的数据分析能让人们更有准备地去开会，帮销售团队问出更到位的问题，免去了无谓的猜测。人们不用再猜测他们的用户在寻找什么，或者为什么他们达成销售，或者为什么他们不再回头。人们也不用再猜测其他团队的同事知道或者不知道什么。而这一切都要归功于从一开始就把数据框架设计好。