高效能数据分析的七个习惯

1．相比花哨算法，更重视分析的简单性

如果你都不能向一个5岁的小孩解释清楚，那么你将很难将你的产品卖给其他人。产品数据分析的重点不是分析，别误会，你还是需要分析，但是它的故事和基于数据的推荐真的很重要。

复杂的分析造成的混乱将导致你获得完全相反的结果。你希望能够驱动工程和投资分析行为。如果你的分析是不清晰的，工程师就不能快速通过你的分析获得知识，那么你的分析就会失去价值。

关于数据分析的影响力的最终测试是根据工程和投资行为的改变程度。应该令数据分析变得容易，方便人们使用，得以实现改变。

2．相比数据，更加重视数据源

在更广泛的时间段里看更多的数据可以给你在分析上有更多的信心。然而,遥测或日志作为单一的传递途径会被捕捉到的特性所限制。一般来说,一个单一的途径只讲述产品的一部分。

相同分析+相同原理=相同故事

你需要的是其他数据源。可以是所有被登记在某处的SQL操作记录，或者是你有工具可以从你的用户那里获得日志样本。更多的数据源也会让你确定你的故事是否一致。更多的数据不能给你更多得洞察力。但是更多的数据源可以。

3．相比最新亮眼的工具，更加重视熟悉的工具

亮眼的最新工具使用起来很有趣，有时候也很管用。但是，你还记的你的数据分析的影响力的最终测试吗？

你希望工具变的容易，能够被人们所使用并得到自己想要的改变，但是改变不是这么容易的。从文章《你的大脑在工作》即《Your Brain at Work》学到3点，希望大家能牢牢记住，它们能给与你们最大程度的帮助来促进改变。

对于你的工程师伙伴而言，令工具安全很重要，它们可以被使用和促进改变。通过使用你熟悉的工具，讲述那些快速吸引大家注意力的故事。远离最近，最酷的可视化技术除非它们在你的故事中必不可少。

深入分析核心信息

重复核心信息，不断的重复

除非你正在推荐一个新工具的使用，重点不是在工具，而是你故事的核心信息。

4．相比指标，更加重视洞察力和投资

指标是指你的关键性能指标(KPI)。它们可能以图表,坐标或表的形式表现。你的分析不能就此止步。指标只是数据驱动工程‘3I’里面的第一个‘I’，告诉别人一个围绕数据的充满洞察力的故事，然后建议他们投资。你是改变的代理人,你的分析必须充满你的见解和对投资的建议。

5．相比信任，更加重视CUSS

数据永远都是不干净的。这就是为什么我常常觉得自己像一个门卫。作为数据门卫,我很少相信里面的数据以及它们的格式是正确的。我总是从使用‘R语言的可能性和统计的介绍’中应用Kern’s CUSS，为了能够理解数据中心，数据的异常特征，数据的传播和数据的形状。

中心：数据的总体趋势所在

异常特征：有缺失的数据点?离群值?集群?

传播：数据产生哪些变化？

形状：如果你来绘制数据，数据的形状是什么？

了解数据如何生成和数据的CUSS可以让你作出更好且合理的见解和投资。

6．相比确定性，更重视方向

数据收集的成本经常是解决业务和工程问题的最终答案的一大障碍。你几乎总是能得到不完整的答案，虽然比你手中已有的答案好。

《如何测试任何事》（How To Measure Anything）的作者推荐我们可以问这个问题：

“是否存在一个测试的方法可以减少不确定性，足够来确定测试的成本？”

即使你没有相应的工具来明确的回答特定的组件是否有这个问题。你也可以消除一些组件，通过廉价的方式来减少不确定性。也许你可以凝聚几个不同来源的数据,得到一些非常粗略的结果，让事情朝着正确的方向前进。

让你或你的团队朝着正确的方向前进比得到超级准确的,确切的答案更重要。

7．相比你在“思考”软件是如何工作的，软件的实际工作更重要

产品数据分析的优点是看到实际用户使用你的软件产品的足迹。有时你会得到一个很好的的足迹。但也有可能,你得到的部分足迹让你的调查更加困难。无论如何,遥测和日志的足迹都是现实的反映。

架构知识是伟大的资产。但是，遥测和日志通过确凿的证据告诉我们实际发生了什么，结果并不是我们希望看到的。作为一名数据科学家，如果你对数据有着独特的看法。那么你看到的软件，就是软件的真实情况。

这是很强大的，因为你不仅有足够的证据显示软件是如何工作的，也可以对广泛的用户有针对性的洞察。你可以声称：“77%的用户沿着的这条编程路径是和软件设计矛盾的。”相信你的用户留下的足迹，但是要重复检查。在‘统计学习的元素’这篇文章中，有一句引言我很喜欢：“正如我相信上帝一样，我也相信他人带来的数据。”