【版权声明】本文系Adobe Omniture资深分析总监Brent Dykes所作，原文名为：
Reporting vs. Analysis: What’s the Difference?
中文译文系Sidney Song（宋星）翻译。Adobe及作者拥有版权，译文版权归译者及CWA?hina Web Analytics, www.chinawebanalytics.cn）所有。
【译者前言】我们常常做报告，我们也常常进行网站分析。但是很多时候，报告和分析似乎并不容易严格的区分开来。而且，分析最终也还是以一个报告来呈现的。不过，这篇文章想要告诉我们的是，分析和报告虽然有联系，但的确有很多的不同。他们如同孪生兄弟（就像我之前说Bounce Rate和Exit Rate是孪生兄弟一样），但其实长得并不一样。本文的作者也是美国网站分析的领军人物之一。
【译文正文】
尽管在英语中“报告”和“分析”很多时候似乎都是可以互换的，很多人也认为它们哥俩是同义词，但你还是见过不同的人在不同场合只使用了它们中的某一个。尽管二者在网站分析领域采用的数据一样，但是二者的目的，任务，输出（outputs），交付（delivery）以及价值都有很大不同。如果不弄清楚二者的区别，一个组织就可能把自己置于对某一领域（典型的领域即是分析领域）缺乏足够认知的境地，也就无法享受网站分析投资带来的全部好处。对我个人而言，尽管我的工作聚焦在网站分析工具上，但是公司所采用的其他工具（例如广告，邮件营销，搜索，社交媒体等方面的工具）也适用于同样的道理。
大多数公司的分析解决方案都已经到位，且为他们的组织贡献了更大的价值（译者注：这是美国的情况，中国应该改为“少部分公司”, CWA, China Web Analytics, www.chinawebanalytics.cn）。换句话说，报告和分析的终极目标都是为了增加销售和削减成本（即增加盈利）。报告和分析也都扮演了影响和鞭策企业采取促进盈利的行动的角色。
这篇博客里，我并不想深挖报告和分析阶段前后会发生些什么，但我的确意识到两个领域都属于全局数据驱动下的决策制定流程中的至关重要且颇具挑战性的步骤。因此，记住报告和分析只有在它们引发了企业真正的行动才具有价值。
目的
在描述报告和分析的不同作用之前，让我们先给这两个网站分析中的关键领域做一个高度抽象的定义。
报告：将数据组织为信息集合的过程，目的是监控不同业务领域的绩效表现。（Reporting: The process of organizing data into informational summaries in order to monitor how different areas of a business are performing.）
分析：为了获取具有意义的深度见解（meaningful insight），对数据和报告进行的探索和挖掘的过程，这个过程被用来更好地理解并提高业务绩效。（Analysis: The process of exploring data and reports in order to extract meaningful insights, which can be used to better understand and improve business performance.）
报告把原始数据（raw data）翻译为信息。分析则将数据和信息转化为洞见（insight）。
报告帮助公司监控他们的在线业务，并在数据超出异常变化的时候发出警告。好的报告应该能够为终端用户找出关于业务情况的问题在哪。而分析的目的则是通过更深层次的解读数据，以及通过提供可行性的建议来回答这些问题。通过实际的分析，你可能会提出额外的问题，但其目的是为了找到答案，或至少是找到可能的潜在答案，并确保最终答案是可以进行测试获得的。综上，报告告诉你正在发生的情况，而分析则聚焦于解释为什么它会发生，以及你能因此采取何种应对行动。
任务
企业有时候被“分析体系（analytics）”和“分析（analysis）”弄得晕头转向。例如，一个公司可能聚焦于一些全局性领域的分析体系（战略的，实施的，汇报的，等等），但并没有聚焦于某些具体的分析上。很可能一些组织在最初建立起相关的体系之后就开始慢慢懈怠，而不再将这些体系进一步地推进到具体的分析阶段。再加上有时候报告和分析的界限可能有些模糊，因此这就使分析变得真的像某种其他风格的报告。 一个辨别你的组织更强调报告还是更强调分析的方法是，辨识主要的分析任务是否是由你的分析部门担任。如果这个部门大多数时候都花费时间在建立，配置，聚合（数据），组织，修整格式以及总结上，那么这就是报告任务而已，不是分析。分析聚焦于不同的任务上，例如提问，考察，解读，比较以及核实（我没有将测试列入此处是因为我认为对优化进行的努力应该归为具体的行动领域，而不是分析）。尽管报告和分析可以相互渗透，但是你的分析团队应该更多地评估在二者中的哪一领域应该花费更主要的时间。大多数情况下，我见过的分析团队都将他们的主要时间花费在报告任务上，而不是分析任务上。
输出
报告和分析的最终交付形式表面看起来很像――很多的图表、图形、趋势线、表格、状态等。然而，其中还是有些细微的差别。报告和分析之间主要的一个差别是整体的方法不同。报告采用的是推送（Push）的方法，即将报告发送给那些需要获取深入见解的用户，以辅助他们自己采取恰当的行动。我这里有三种重要类型的报告形式：打包报告?anned Report），仪表板（或称精要简报，Dashboard），以及警报（Alerts）。
打包报告：这类报告是“开箱即用（out-of-the-box）”的报告或自定义报告。你可以直接通过网站分析工具直接配置而来，或者也可以以某个时间周期发给一组终端用户。打包报告通常具有较为固定的形式，且具有固定的度量和维度。总体上看，一些打包报告的价值可能高于其他报告，且一个打包报告的价值取决于它与具体职责的相关程度（例如，SEO专员 vs. 网站制作人员）。仪表板：这些定制的报告集合了不同的KPI和细部报表（英文：reportlet，是一种不可再拆分的细小报表，译者注。CWA, China Web Analytics, www.chinawebanalytics.cn）。这种报告提供了一个全面的，高屋建瓴的视图，以为特定受众展现业务绩效。仪表板可以包括从不同数据源引用的数据，而且此类报告也通常是相当静态的。警报：这种报告是条件类型的报告，在数据超出预计的范围或是满足了其他一些预定条件的时候，这类报告才被激发。一旦人们被通知有事发生，他们就能在需要的时候采取适当的行动。与报告相对，分析采用的是“拉动（pull）”的方法。分析师会把相关的数据抽取出来以回答一些具体的业务问题。基本上，当某个人需要花费精力在报告的评估上，并且需要作出决定是否采取某种行动的时候，他就可能去做一些的确给力的分析。在这种情况下，分析的输出包含两种主要形态：具体需求的分析响应（Ad hoc responses）以及分析演讲（analysis presentation）。
1. 具体需求的分析响应：分析师接到不同的商业问题而对寻求这些问题的答案而进行分析，这些问题很可能就是由阅读报告引发的。通常，这些问题比较紧急，需要一个快速的回复。分析团队可能不得不同时处理多重问题。因此，分析不太可能按照分析师的意志对研究对象挖掘的很深很广，而只是输出一个相对短小精悍的报告，其中可能包含也可能不报告具体的建议。
2. 分析展示（Analysis presentation）：一些商业问题本质上比较复杂，从而需要更多的时间去进行一个全面深入的分析。这些分析项目的结果会以一个更加正式的方式输出，主要包括两个关键部分：主要分析发现（Key findings）和建议（Recommendations）。主要分析发现部分对分析产生的最有意义和可行性的见解进行强调。建议部分则基于分析发现提出应该采取何种行动的指导方案。
当你比较报告和分析的最终交付形态时，不同的目的（信息 vs. 洞见）揭示了二者输出结果的成色。报告把信息推送给组织，分析则从报告中把洞见抽取出来。当然，也可能存在其他某种综合报告和分析的输出形式，例如加有注释的仪表板（annoted dashboard），其中包含阅读仪表板时激发出的分析观点，这种报告跨越了两个领域。对于一个最终输出结果到底是报告还是分析，你可以通过它的目的（是信息还是见解）和它的方法（是推送还是拉动）来辨识。
报告和分析的另一个关键分野在于是否联系上下文（context，所谓上下文，是指与数据相关联的一些前后数据或者信息，例如与visit数量相关的网站广告投放金额，或是visit背后网站的流量购买的策略等，译者注。CWA, China Web Analytics, www.chinawebanalytics.cn）。报告不提供或者只提供非常有限的数据的背景上下文。有些情况下，终端用户可能可能已经拥有了所需要的上下文，这样就不会对阅读报告产生什么障碍，然而更多情况是报告用户可能并没有相关的背景知识，这就造成了很多困扰。对于分析而言，上下文信息则是至关重要的。为了让数据给力地讲故事，上下文是故事发展脉络中不可或缺的组成部分。
尽管报告和分析都会在输出报告中利用数据可视化的方法，分析还是跟报告有所不同。这是因为，分析强调通过数据得出观点，这些观点需要有意义、独特或是特别，并且能说明为什么这些观点对业务是重要的。报告有时会自动强调数据中发生的一些关键变化，但是它却不解释为什么这些变化是重要（或是不重要）的。报告不会去解答“会怎么样？”之类的问题。
如果你恰好在享受初为人父（母）的快乐，我将会把打包报告、仪表板和警报等报告比作一个六个月大的婴儿。当不舒服的时候，他会哭闹，而且常常动静很大，但是他却告诉不了你哪儿不爽了。父母则会赶紧抓狂地寻找到底哪儿不对头（是饿了？尿布脏了？想奶瓶了？牙齿不适？累了？耳朵感染？等等等等……）。同样，报告也不会告诉你如何止住婴儿的哭闹。
建议部分是一个区分报告和分析的关键之一，因为建议提供了基于数据进行分析之后应该采取何种行动的指导。一旦一个建议作出，开始执行就是分析的另一个强有力的结果，因为建议意味着作出决策（是进还是退），而决策产生行动，行动带来价值。
交付
如同刚才我提到的，报告更是一种推送的模式，人们通过某一个分析工具、Widget、Excel表单、或其他形式的邮件递送、移动设备登入、FTP等形式获取报告。因为个体或者组织对于定时（每天，每周，每月等等）报告的需求，自动化就成为一个关键的建立和交付报告的形式。换句话说，一旦报告被建立起来，就会考虑它如何被自动化以定时交付的问题。我打过交道的大多数分析师都不喜欢定期手动地建立和更新报告，这是机器人或者是电脑做的事情，而不是人们花了4-6年大学助学贷款后应该做的事情。
另一方面，分析是人们利用他们超群的逻辑思维和分析技能从数据中获取关键性的洞见的过程，这个过程也形成了对于组织具有价值的可行性建议。尽管分析可能被“提交”给决策者，但更有效的展现方式则是人对人的展示。《分析领域的竞争》?ompeting on Analytics）一书中，Thomas Davenport（托马斯・达文波特）和Jeanne Harris（珍妮・哈里斯）强调分析师和决策者之间能够相互信任（trust）且各自具有公信力（credibility）是至关重要的。决策者一般都没有时间和能力（这一点上本文作者很直接，译者注。CWA, China Web Analytics, www.chinawebanalytics.cn）去自己完成分析，而一旦“紧密的，可信的关系”到位，就能让他们正确界定需求，分析师也就能提出正确的问题，执行官也因此而更有可能将行动建立在他们信任的分析之上。
价值
当需要比较报告和分析不同的作用的时候，很重要的一点是理解报告和分析在获取价值方面的关系。我倾向于将数据驱动的决策（data-driven decision）过程（数据>报告>分析>行为>价值）比作一副多米诺骨牌。如果你移去某一个环节，就会使达到最终价值目标变得困难甚至是不可能。
在右面的“通往价值的路径”（Path to Value）这个图中，路径始于获得完整且精确的数据。如果你不能得到靠谱的数据，那么你的报告或者分析无论多么牛X都于事无补。同样，如果你去掉“报告”这张骨牌，也会带来影响。尽管有一些老练的分析师会争辩说他们根本无需报告就可以进行分析，也许对于个人而言可能如此，但是在一个组织层面上，没有报告，就无法让你的数据真正下达到所需有需要它的人手中，也就实现数据共享。
大多数公司都有足够的报告，但可能缺乏“分析”这张牌。报告很少能够靠它自己引发行动，因此需要分析来帮助弥合数据和行动之间的鸿沟。拥有分析并不保证一定带来好的决策，人们需要依赖于实际的建议才可能采取正确的行动，或者组织也才能在正确道路上执行。然而，成功的网站分析确实能够拉近与正确决策之间的距离，并且能够创造潜在价值。
结语
报告和分析常常形影不离，但是应该如何分配你的资源和人力在这二者之上呢？当我听到有客户挣扎于从网站分析投资中挖掘价值的时候，通常意味着上面“Path to Value”骨牌中的一张可能已经缺失了，而且往往缺失的就是“分析”那张牌。
我最近遇到了一个主要的媒体客户，他们发现他们确实丢掉了分析那张牌。网站分析团队整天忙乱于满足这个既庞大又复杂的组织的战略需求，监测实施，以及报告等需求中，而无从这些具体的事务之外提供真正的分析。高级管理者也越来越对分析人员和分析系统感到沮丧。幸运的是，这个网站分析团队已经得到了额外的人力和预算，并且雇佣了一个分析师专门为他们的主要产品团队进行深度分析，以获取可行性的建议。不出意料，当公司找回了那块遗失的骨牌之后，管理层的态度发生了一个180度的大转弯。
你可能会疑惑你的分析师们需要花费多长时间在分析上。粗略看，我认为至少25%的花费在分析上是合理的，当然多多益善。不过，100%肯定并无必要，毕竟网站分析团队还有其他的许多重要的责任，例如汇报，收集业务需求，培训，记录以及沟通等等。我希望你在读了这篇文章之后，能够至少认识到不花时间在分析上是不可取的。如果你的公司目前没有做很多分析，那么试着开始花费10%的时间在分析上你就能看到效果，并能以此作为进一步成功的起点。最后，我们的分析师团队会始终如一地乐于帮助你完成分析需求。祝你好运！