我们可以回想一下，自己平时都是怎么去做决策的。最直接的决策方式就是凭感觉、拍脑袋，这是很常见的。但是，实际结果如何是不能确定的。如果在实际在工作中，单靠这种方式来做决策其实是不够理想的。 后来，我们就强调因果驱动，就是去想清楚原因，然后再去讲逻辑。当然，这种方式比起拍脑袋决策肯定要科学很多。但是，它有一个很大的问题，就是效率比较低。很多事情等你想清楚原因再做决策，可能最佳时机都已经错过了。 那么，有没有更好的方式呢？更好的方式就是我们今天聊的数据驱动。很多事情我们可能还没弄清楚原因，但我们知道在什么样的情况下效果最好，那我们就可以直接把最好的效果用起来。至于原因是什么，我们可以慢慢去想。比如一个网站页面，是绿色背景好，还是蓝色背景好，你可能很难去做决定。但是，我们可以去做A/B测试，分析哪边的点击率高。如果绿色背景的点击率高，那我们就选择他，至于为什么会这样，我们可以慢慢去想，但是先要让大家使用点击率高的方式查看。

最近一段时间，我在听评书楚汉争霸，楚怀王曾经和刘邦、项羽约定，先入咸阳者为关内王。结果刘邦率先进入了咸阳，但并没有把咸阳洗劫一空，他的手下萧何则将一些典籍、税收之类的记录都给拿回去做研究，做数据分析。后来，项羽到了咸阳以后，开始分封各路诸侯，将刘邦分到了巴蜀之地。萧何就向刘邦提议，应该和项羽商量一下，看能不能将汉中这块地方分给他。为什么他想要汉中这块地方呢？因为萧何通过大量的数据分析发现，汉中这个地方虽然不起眼，但税收在秦国占据很大的比例。这件事情项羽并不知道，项羽只是一介武夫，去咸阳之后只知道烧杀，也不知道各地的情况，于是项羽就同意了。结果，刘邦凭借汉中之地，几个月之后就打到三秦，也就是之前秦国关中这一带。几年之后，刘邦就把项羽给打败了。从这件事情可以看出，数据分析不管在什么时代都是很重要的。

我们可以回想一下，自己平时都是怎么去做决策的。最直接的决策方式就是凭感觉、拍脑袋，这是很常见的。但是，实际结果如何是不能确定的。如果在实际在工作中，单靠这种方式来做决策其实是不够理想的。

后来，我们就强调因果驱动，就是去想清楚原因，然后再去讲逻辑。当然，这种方式比起拍脑袋决策肯定要科学很多。但是，它有一个很大的问题，就是效率比较低。很多事情等你想清楚原因再做决策，可能最佳时机都已经错过了。

那么，有没有更好的方式呢？更好的方式就是我们今天聊的数据驱动。很多事情我们可能还没弄清楚原因，但我们知道在什么样的情况下效果最好，那我们就可以直接把最好的效果用起来。至于原因是什么，我们可以慢慢去想。比如一个网站页面，是绿色背景好，还是蓝色背景好，你可能很难去做决定。但是，我们可以去做A/B测试，分析哪边的点击率高。如果绿色背景的点击率高，那我们就选择他，至于为什么会这样，我们可以慢慢去想，但是先要让大家使用点击率高的方式查看。

如何去实现数据驱动决策呢？其实挑战还是很大的，至少到现在为止还做不到很理想。比如一个创业公司最开始决定要做一个什么样的产品，这时候其实没办法拿到很多的数据，还是需要凭直觉做决策。但是，这个阶段尽量让它缩短，让它更可控一些，通过更少的代价去达到一个验证的效果。

如果一家公司的产品已经开始被用户使用，整个公司已经正常运作了，这个时候通过拍脑袋决策而不是看数据，这种方式就不够理想了。

现实中VS理想中的数据驱动

创业公司在数据驱动这件事情上会遇到三个常见的问题：

第一、排队等待某个工程师跑数据。不管是产品、市场、运营等等，大家会有各种各样的数据需求。对于公司来说，不可能安排很多工程师去满足数据需求，那怎么办？一般就是排队，一个一个需求去响应。一般这个流程是：数据工程师先跟需求提出者沟通，弄清楚需求是什么；然后再看数据源里面有没有，如果没有，再去升级系统，然后再响应这个需求。这样一来一回，可能需要几天甚至一两周时间，效率是非常低的。

第二、只有仪表盘可以看。通过仪表盘可以看到整体的宏观数据，比如销售额、用户数等，这些数据对于老板做商业决策还是非常有用的。但是，对于具体干活的人来说，只有宏观的数据是不够的。比如我们发现昨天的用户量或者活跃用户数跌了20%，这种情况下，你肯定是要去做数据分析的，只有宏观的数据是远远不够的。我们一般可以按照渠道、地域等维度对数据进行分解，然后再去看是不是有某个渠道或者某个地域有大的波动，这时我们就能更快地去解决问题。

第三、存在多个数据孤岛。对于相对比较大的公司，特别是偏传统一点的公司来说，会有很多部门，每个部门都会有一部分数据。如果你去做数据分析，就要跟不同的部门去打交道，获得审批权限。等审批下来，可能都需要花一段时间。到最后真正审批下来，把这些数据统计到一起去，又是很难搞定的事。

那么，理想状态应该是什么样？我认为应该是实现自助式的数据分析，让业务人员真正掌握数据。就像下图中，我们前面讲的问题就是左边这张图，我把它归结为需求驱动。每次来一个需求，数据工程师从杂乱的数据里面去满足这个需求，整体效率是比较低的，这是一个串行的事情，每一个需求可能需要几天甚至一两周时间。理想状态是右侧这张图，就是反着来。首先把数据源建好，然后提供更强大的数据分析工具，让业务需求者自助式的去满足自己的需求。从一件串行的事情变成一件并行的事情，从一件几天或者几周时间的事情变成一件几分钟甚至几秒钟的事情。那么，我们如何去达到这一点呢？其实这里的挑战还是非常大的。

数据金字塔的三层：采集、建模、分析

我们把数据分析平台的建设简化一下，可以分为三层：

第一层：数据采集。
第二层：数据建模，就是把数据进行再组织。
第三层：数据分析，也就是真正去使用数据。
对于非技术人员来说，往往只会关注到第三层。我们去做数据分析，并不清楚数据是怎么来的，数据本身是不是有什么问题，这些都关注不到，甚至一些非技术出身的老板也是这样，只知道要一些数据，但是发现这些数据拿过来以后，自己会很痛苦。其实，归根结底还是底子没打好。我们一定要把数据采集跟数据建模做好，然后数据分析这件事情就顺理成章了。

数据采集
数据采集的两个原则：

数据这件事情要做好，最重要的就是数据源。什么叫做好的数据源呢？

第一点是全，我们要把客户端、服务端、数据库等等各种各样的数据都采集下来；

第二点是细，细就是强调多维度，比如用户行为发生的时候，Who？When？Where？How？What？这些维度信息都给它记录下来，以后就可以根据这些维度进行灵活的组合分析。如果数据采集本身没有做好，那就是“巧妇难为无米之炊”，后面你用再复杂的算法也解决不好。

数据采集的三种方法：

第一种是可视化埋点

就是在一些客户端，不管是APP还是网页，在里面嵌入SDK，然后通过后台界面配置点选这种操作，去选择我们要采集的按钮点击情况。这种方式比较轻便，不需要工程师帮助去做埋点操作，就可以拿到PV、UV、点击量这些数据。不足的地方在于：第一、只能用于前端数据的采集，后端服务器数据的采集是做不了的；第二、前端数据的采集只能采集到宏观行为本身，比如对于提交订单的行为，我只知道提交的行为，但是一些属性信息，比如订单的运费、折扣价格、订单价格等信息可能都采集不到，后面就无法去做灵活的多维度分析。

第二种是代码埋点

代码埋点要比可视化埋点更灵活一些，当然代价也会更大一些，因为要在代码里面嵌入逻辑。做代码埋点，我们可以将更细的维度数据记录下来，以便于后面进行多维分析。另外，代码埋点不仅仅局限于前端的代码埋点，还有后端的服务模块也可以进行，能把数据更全更细的采集下来。这种方式对于一些公司来说会存在一个问题，代码本身在业务复杂的时候，不知道怎么埋，会出现埋漏、埋错等各种各样的问题。这件事情如果要做好，首先工具本身要支持的比较好，比如要有埋点的管理；另外，还需要有专门的数据埋点负责人，他要对数据采集这件事情负责，每次做数据采集都是经过整体确认评估过的，而不是让工程师顺带着去做。

第三种是导入辅助工具

比如有一些线下的数据，还有一些数据库的数据，你想将数据放到数据分析平台去做分析该怎么办呢？那么，就需要工具将数据实时或者批量地导入到数据分析系统里面。

2、数据建模

有了数据以后，接下来就要对数据进行建模组织。为什么需要建模呢？我们看下图：

大家不用管表格的内容，这是一个数据库的表设计。对于正常的业务来说，其实很多创业公司做的数据分析都是基于业务数据库来进行的。这个业务数据库一般会有若干张表，这些表之间会有复杂的关系。比如表里面会有订单表、用户表、进销存的信息等等一系列的表，基于这些表，我们可以做一些数据分析。

如果你将表直接用于数据分析，主要会有两个问题：

第一个，难理解。整个表格会牵扯到很多张表，表之间会有复杂的依赖关系，对于业务人员来说，很难理解清楚这到底是干嘛的。如果硬着头皮非要看懂，可能过了一段时间，因为性能不行，做了一些调整，那么业务人员就奔溃了。

第二个，性能问题。业务数据库在设计的时候，是为了正常的高并发、小批量查询服务的，它并不是用于做数据分析的。做数据分析的时候，将表之间连接起来进行分析，性能就比较差了。

更理想的方法就是对数据进行再组织，重新建模，方便后面去做数据分析。比如拿用户行为来说，我们可以把用户行为整理成一系列的事件，就是Event模型。对于任何一个互联网产品，用户能干的事情都可以抽象成一系列事件，比如电商产品，浏览首页、浏览商品、提交订单等等都是一些事件，每一个事件都会有一个实体，就是User ID，它决定了谁在进行操作。事件还会有一些属性信息，属性包括设备属性、时间、浏览的商品名称、价格等等，这些属性都可以用一张表表达出来。有了Event表以后，做数据分析就会变得非常简单了。例如：我们在表里面可以看到有多少来自江苏省的用户进行了浏览。这里面最重要的一个概念就是多维数据分析。

我们看下面这个立方体，有两个关键概念：

一个是维度，像城市就是一个维度，北京、上海、深圳等就是这个维度的取值；操作系统也是一个维度，IOS、安卓等就是取值。

另一个是指标，指标实际上就是一个数字，比如销售额、成交量、注册用户数等。那么，我们可以通过维度组合来看一些指标的情况，例如：我们可以看来自天津的，使用IOS系统的用户，他的销售额是多少。如果我们将数据组织好多维数据模型进行这样的分析，其实是非常容易的。

实际上，从我接触的创业公司来看，因为本身的数据底层模型没有建好，所以每来一个需求，都要单独为了满足这个需求去跑一些程序，就像打补丁一样，效率是非常低的，做起来也容易出问题。

3、数据分析

数据模型建好以后，接下来就是真正去用这些数据，也就是进行数据分析。数据分析有各种各样的方法，因为时间有限，我就不详细去讲每一种了。在这里，选择漏斗分析方法，结合神策数据的一个案例来向大家讲述一下。

去年9月25日，我们的产品正式对外发布，当时其实很简单，就是在36氪上发了一篇报道文章。另外，我们自己人也在朋友圈发了官网链接，让一些亲朋好友帮助转发一下。我们自己是做数据分析的，所以会想看一下谁带来的用户更多一些。大家在朋友圈分享的时候，我们在链接里面加了一个参数，用来跟踪用户是从哪里过来的，可以看成是一个渠道类型。

比如我自己发了一个链接，就在URL的参数里面加了“ch=sangwf”，这样我发出去的链接，如果被人点击了，就可以跟踪到。

上图是当天晚上带到访问首页的各个渠道数据，这里我只抽取了几个关键的渠道。可以看到，36氪只带来了0.9%的用户，比我预期的要少很多。后来我分析了下原因：一方面，36氪本身的访问量并没有想象中的那么大，毕竟主要是科技圈的人在看；另一方面，在文章里面加一个链接，其实点击的人还是比较少的。图表的右侧，一个是caojiang，他是我们的CTO，带来了28.7%的用户；我自己带来了27.9%的用户。

当然，只是访问首页肯定是远远不够的，我们期望的是用户真正去试用或者体验我们的产品。用户进行体验就会经过4步流程：第一步、访问首页；第二步、点击申请试用按钮；第三步、提交申请试用表单；第四步、用我们发布的账号再去体验产品。每一步的转化都会有流失，特别是从点击“提交表单”到真正去试用产品，这个比例只有19.21%。

这里面有两个问题，一个问题是当时我们没有预料到有那么多人申请试用，所以一开始是人工的方式给大家发账号，后来才熬夜写了一个脚本，去自动发账号。另外一个问题，我们是在9月25日发布的，接下来正好是中秋节，过来体验的人是比较少的。到现在，我们的比例有百分之八十几了，比之前要高很多。

我们可以看整个漏斗，从访问首页这几个渠道带来的用户，到最终真正去试用只有0.98%，这个比例还是比较低的。好的一点是，访问首页里面有28.9%的人都会点击申请试用，在这个点击上，我专门做了一些属性设置。

我们再来看一下这几个渠道的详细数据特别是caojiang和我自己的数据。从访问首页来看，caojiang带来了1316个用户，我带来了1286个用户，caojiang比我是要多的。但是我们看漏斗的整个转换，到真正成功提交表单这一步，caojiang带来了51个用户，我带来了87个用户，这个比例就比他多了50%。如果再去看真正去试用的用户，caojiang有7个，我有22个，多了两倍。所以，看深度的有效数据，我比caojiang带来的用户要多很多。这就是漏斗分析的价值，我们能够一步一步的去看用户的转化情况是怎样的。

创业公司如何构建指标体系

对于创业公司指标体系的构建，我推荐两种方法：

第一关键指标法（One Metric）——来自《精益数据分析》一书
海盗指标法（AARRR）——来自500 startups 创始合伙人 Dave McClure

1、第一关键指标法

对于互联网产品，尤其的是早期的创业公司的产品，一个阶段应该只有一个关键的指标，而不是有很多指标。有了这个指标后，可以扩展出一些指标，用来支撑关键指标。当然并不是说永远只考察这一个指标，而是在任意一个时间点，只有一个最关键的指标，但随着业务的发展关注重点会有变化。比如对于一个成熟的电商产品，它最关心的可能是销售额，但销售额我们又可以衍生出访问量、转化率、客单价等指标，我们通过优化这些衍生指标来实现关键指标的增长。

对公司来说，基于关键指标制定目标有两点好处：一是确定了现阶段最重要的问题，二是可以基于关键指标的当前状态制定清晰的目标。否则你可能问题既没找对，努力达到的数字也是没有意义的。对于一个创业公司，不同的阶段需要关注的重点是不同的。我把创业公司分成三个阶段：

①MVP 阶段：

MVP（最小可用产品） 是《精益创业》一书中提出的理念。指的是在创业的最早期，你的关注点是要确定用户需求，并做出一个最小可用的产品来验证需求的真实性。在这一阶段，你需要的是定性分析，客户本身可能就是你的亲朋好友，直接找他们聊就可以了，并不需要在数据分析方面投入大量工作。

②增长阶段：

这个时候你的产品已经出来了，并且有用户在用，是时候需要做数据分析了。

第一个留存阶段，看留存分析，首先保证留存率比较高，用户真的对产品满意，愿意用他。
另一个引荐阶段，看病毒传播系数、病毒传播周期等等。
如果没有病毒传播的因素，我们就看NPS（净推荐值），看有多少老客户愿意把产品推荐给新用户。
③变现阶段：

这个阶段产品已经相对比较成熟，我们考虑的重点就变成了如何赚更多的钱，以及如何规模化。我们关注的重点成了LTV（客户终生价值）、CAC（获客成本）、渠道分成比例、渠道用户盈利周期、成本等。

当然，这里只是列举了不同阶段的典型关键指标，结合你的项目本身，还是要具体来看。

2、海盗指标法

我们把创业公司关心的指标分为三类：

1、拉新

首先是触达用户（Acquisition），让用户知道你，然后才可能选择你，看展现量等等。
之后是激活（Activation），一个用户到达你的首页，并不表示他就是你的真正用户了，还要看有没有操作核心流程。
然后是引荐（Referral），一个好的产品，应该是自传播的，通过口碑，有越来越多的人使用。或者是通过一些激励措施，让老用户拉新用户。
2、留存

在做好留存之前，最好不要花太多的功夫拉新。如果你的产品不能解决用户的问题，或者用户体验不好，那么拉的人越多，流失的越多。留存就是要提升核心用户的重复频率，比如电商产品的复购，比如考察用户的次日留存率。

3、营收

创业公司的最终目的都是为了赚钱，促进商业化，怎么在产品上进行改进。比如Paypal，一开始是免费的转钱，后来发现主要用户是Ebay上的卖家，就制定了一个标准，每半年信用卡支付接受额超过500美元的账号就需要收费，从交易过程中收取佣金。

当我们再去做一个产品，想要确定到底该关注哪些指标的时候，就可以按照这个框架，来看我们能不能促进这些指标的提升，这样就能将指标体系建立起来。当然，我讲的只是一个宏观的方法论，具体到你自己的产品，还需要单独去量身定做。

Q&A

1、如何判断公司是否需要使用神策数据或者处于什么阶段使用？

神策数据主要是针对互联网创业公司做用户行为分析这一块。我觉得如果一个产品还处于MVP阶段，也就是还没有确定要做什么样的产品时，就不需要使用数据分析这种工具，还是以人工调研为主。之后，你的产品已经真正做出来并且已经有用户在使用了。这时候，特别是跟交易相关的产品，你本身需要考虑渠道的用户转化，漏斗转化，以及用户留存情况，或者在进行用户运营分析的时候，需要针对不同的群体，采用不同的方式。这个时候，使用神策数据就比较好了。目前我们的客户公司主要有两类，一类是互联网创业公司，像秒拍、爱鲜蜂、融360、keep等；另外一类是“互联网+“企业，就是传统企业转线上的，这一类也比较多。

2、创业公司是否需要自行完成数据采集和数据建模后，再使用神策数据分析产品？

创业公司并不需要自己再去做数据建模的工作，因为这也是我们神策分析的卖点，神策分析本身就提供了比较全的数据采集的方法，不管是可视化埋点、代码埋点还是工具导入，都提供了工具方便客户进行数据采集。另外，我们有分析师团队，他们会配合客户梳理事件维度这些信息，保证客户在数据采集上比较轻松的进行。我们的系统本身会自动进行建模的工作，所以这一块根本不需要创业公司自己去做。

3、请问神策有BI商业智能这个方向的产品线或者这方面的开发计划吗？

神策分析按照大的范畴来说，其实也属于BI这一块，都是在做商业智能，只是我们现在仅针对互联网公司做深度的用户行为分析。第一、我们有数据分析可视化的工具，支持运营、分析、产品、效果评估这样的事情。第二、很关键的一点是神策分析是一个PaaS平台，帮助客户将数据底子、数据仓库的基础建好，客户可以在这个基础上进行二次开发，去做个性化推荐或者精准广告等等，去深度利用数据；第三、在结构简单的情况下，我们要采用列存储这种方式，让那些参与计算的维度数据被读取出来，没有参与的就不会进行，这个时候效率就高了。

4、试用过神策的产品，可以支持任意事件任意维度组合查询秒级响应，从技术上是怎么做到的？如果达到大数据量的时候是否还是一样的效果？

这确实是我们产品的一个亮点，你去做这种多维事件的分析还是比较灵活的，事件本身自定义，维度又是自定义，指标也是自定义，我们又可以做到秒级的响应。其实不只是秒级的响应，我们还支持数据实时地进，实时地查，也就是秒级地进，秒级地出，并且每天10亿条记录都没有什么问题。

如何去做到这一点呢？这里关键的一点还是要做底层架构的支持，像我们在底层使用了大数据处理的框架。但是，纯粹使用开源的东西肯定是做不到这点的，我们之前在百度就是做这种数据分析以及多维查询平台，所以积累了很多经验。我们在开源的基础上，又去封装了许多查询上的算法，做了许多优化，提高性能。这是从架构上来做的事情。从数据组织上来说，主要是使用了框表，让整个数据结构变简单了。

如果达到大数据量的时候是否还是一样的效果？这个需要看数据量多大了，我们其实给客户保证的是在这种常规的查询里面，尽量保证90%以上的情况秒级响应。为了满足这一点，其实就要看数据的规模，比如客户数据规模比较大的时候，就采用集群，使用多台机器。现在对于我们大的客户，会使用10台机器这样的规模，支撑的数据规模是很大的。

5、创业公司采购神策的私有化部署单机版数据分析产品后，产品的程序代码是否移交给创业公司？公司可否自行开展二次开发？

采购了神策分析私有化部署以后，代码肯定是不会给客户的，因为这是我们的核心。但是，我们本身会有一部分代码开源给客户，比如SDK，这些我们都是放在github上，客户能直接看到。我们产品的一大特点是PaaS平台，可以很方便的让客户进行二次开发，我们本身的数据、查询接口都是给客户开放出来的，就差把核心的源代码给客户了，用户有非常高的灵活性。