如何从一开始就设计好数据分析的基本框架

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

关于数据分析，避免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）。

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

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

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

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

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

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

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

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

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

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

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

举例

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