孵化菌：上周果壳空间邀请了SnsorsData（神策数据）的CEO桑文锋，为果壳空间的创业者们全方位解析了大数据的相关知识。内容包括了：数据思维与数据驱动、处理过程、分析方式和具体的案例分析四个方面，可谓诚意满满、干货十足。在这个信息爆炸的年代，恐怕真的要掌握一套方法论，才能以不变应万变。
一大数据思维与数据驱动
大数据出现在-年，其特点可总结为“大、全、细、时”四字。包括两层含义，一是实际数据规模或数据理解深度达到一定程度，解决方案与以往会有不同。其二，也是更大差异，在思维理念上，即我们需要用一种新的数据思维来思考。
输入法的演变就是个很好的例子，年时普遍使用的主要是智能ABC、五笔、微软拼音之类，那时候感觉打字非常麻烦，敲一下字还要做一下选择，来回切换，效率非常低。
年出来一种新的输入法叫紫光拼音，有了输入联想功能，可是后来又发现一些新的问题，由于互联网发展很快，会不断有新的词汇冒出来，但词库更新会有很长时间的迟滞，所以流行词汇的输入也很不方便。年，搜狗输入法问世，不但打字打得快，并且词汇识别率比较高，词库更新快。这就是大数据思维的结果。其一，搜狗本身是一个搜索引擎，本身就可以搜集大家的检索关键词；其二，搜狗输入法本身就是一种云的输入法，我们平时的输入结果都会上传到搜狗服务器，他们会基于对此的统计分析，实时更新词库。这就是大数据思维带来的改变。
另一个例子就是地图。在十几年前，我们到一个陌生的大城市，一定会买一份地图，但由于一些道路或建筑的改变，这种纸质地图每年都需要再版更新，且纸质地图只能显示目的地的位置，而无法提供路况信息以选择最优的路线。后来百度地图应运而生，它抓取用户的GPS信息分析人群流向与聚集情况，并向交管所等机构购买地面路况监测数据从而对整个路况进行综合判断。
从这两个例子可以看出，两个产品的革新，在基本的处理逻辑、功能等方面都没有大差别，但是关键是用了数据分析与处理，最后的体验结果就完全不一样。这就是数据驱动的概念，也是大数据思维最本质的一点。
中国历史上大部分决策都是高官权贵们“拍脑袋”决定的，根本没有数据意识。而历史上采用了数据思维的有两个人，一个是王安石，王安石在推行变法时向农户提供政府低息借贷，不增加税收的情况下提升政府的营收。另一个就是庞涓，庞涓在追孙膑的部队时沿途分析孙膑部队留下的土灶数据，土灶的数量呈递减趋势，由此判断齐军士兵多数叛逃，便只带领少量精锐穷追不舍。然而这却是孙膑故意制造的假数据。在这两个例子里，王安石的变法失败了，庞涓也死于数据的陷阱，由此看来数据也是有一定的风险。
后来我们强调讲逻辑，逻辑其实是一种因果关系，比如天阴了我们推测可能要下雨，这就是由二者逻辑关系来推导的，根据这种逻辑关系来决定我们下一步要做什么，先想清楚为什么再做行动，这种方式比“拍脑袋”要好很多。但它有一个很大的问题就是做决策比较慢，在你研究一个流行趋势的因果逻辑时有可能会错过这个时机。
那有没有更好的方式呢？这就是我们所说的数据驱动，让数据去表现优劣，然后决定做什么，这使我们的决策变得更简单。在很多创业公司，想拿到一个数据相对容易，但是效率较低。所以数据的获得也存在时效性的问题。
理想的状态是自助式的数据分析，让业务员真正掌握数据。具体我们可以看看这张图，左边的源头是一堆杂乱的数据，获取数据需要排队等工程师跑，非常耽误时间。而理想的自助数据分析是反过来的，以前是需求驱动，根据需求去找数据，反过来先把数据进行规范，数据模型处理好。再提供强大的分析工具，让这些业务需求人员在这个平台上自助式完成自己的需求，这种方式把一个串行的事情变成并行，效率就要高出很多。
二数据处理流程
从非技术角度来看，大数据分析看作一个数据金字塔，自底向上的是三个部分：数据采集、数据建模、数据分析。
首先来看数据采集，我把常见的数据分析采集遇到的问题总结为3点：不准确、不完备和不细致。不准确是说虽然我们把数据拿到了，但是数据本身是错的，这些错的数据还不如没有数据。不完备就是说拿到了一部分数据，比如说只拿到了前端数据，数据库数据没有拿到。有些需求是做不了分析的。不细致就是说数据的维度太少了，许多维度都丢了，如果某天产品经理想知道不同的浏览器版本的用户在留存上是不是有差异，后来发现这些数据根本没有采集。
于我而言，从事数据分析这么多年，最大的心得就是，数据如果想做好最重要的就是数据源，数据源做好了后面的事往往很简单。那怎样才能说数据源采集好了呢，在我看来就两个字，一个是全，一个是细。全就是多种数据源，比如说客户端，服务端，数据库要把多个数据源都采集下来，之后才能方便分析信息。另一点就是采集的时候要是全量而不是抽样，如果只采集了部分数据那分析的时候得到的结论可能不准确，细主要是强调多维度，在事情发生的时候who,whn,whr,how,what，都记录下来。
我把采集方法归为三点：可视化埋点、代码埋点、导入辅助工具埋点。
可视化埋点就是通过界面配置的方式，不用给程序嵌一些复杂的逻辑就能进行数据采集，这种方式的好处就是可以让采集数据的逻辑跟业务逻辑分离，这样产品运营不需要等工程师排档期来采集数据，运营可以自己动手采集数据。但是这种采集方法比较细的维度信息就无法采集到，并且可视化的埋点主要在前端，比如WEB，IOS和安卓，后端的信息就无法采集到。对于快速验证或只需要看宏观PV、UV这类统计指标的情况下，我们可以通过可视化埋点这种方式解决。
第二种方式是代码埋点。代码埋点是指，在核心逻辑、关键逻辑中嵌入数据采集的代码，然后让代码去真正完成数据记录。在核心转化流程或者渠道分析时，需要将数据记录的很细，要从不同维度对获取到的数据进行深度分析，这种情况就可以使用代码埋点。
第三种方式是导入辅助工具。不管是像后端日志这种批量生成的数据，还是从数据库导出的数据，或者担心SDK嵌入依赖性太强，在这种情况下，就可以使用导入工具，将我们需要的数据灌入。
有了数据，我们就可以开始下一步——处理数据，便于进一步分析。首先明确一下数据模型的概念。举例来说，春节期间我把在文革中烧毁的家谱重新编写了一遍，用思维导图的方式把家族关系以树形图的形式记录下来，这就是一个数据模型。就是说，我们把现实中的人物关系用树形结构的形式表达出来，解决了家谱记录或者说人物关系记录的需求。也就是说，数据模型是为了满足某些需求而服务的。就像Excl里的表格，它可以将人物的性别、年龄、人物关系等信息记录下来，也是在建立数据模型。所以说，不同的数据模型其实是为了方便人们解决不同的问题，并不是一个特别复杂的概念。
同样，如果我们把业务数据库直接用于上层的数据分析，问题就来了。在我们设计的时候，是以如何能让数据模块之间的交互性能、扩展性能更好为目的而建立数据模型的，但是这种情况下建立的数据模型给对数据模型陌生的人看就不方便了。对于非技术人员来说，看到几十张甚至上百张表单，而且表单之间还有复杂的依赖关系等因素，是非常难理解的。因此，更好的方式就是对原始的业务数据进行重新建模，让分析人员更方便的使用数据。
比如，针对用户行为来说。我们把用户行为操作相关的维度信息整体用一张大表来表达。就像Excl中有很多列，每一列都表示一个事件发生时的某一个维度，比如用户使用的操作系统、手机型号、浏览的商品、商品的类别和价格等信息。我们可以将这个表格的范围设计的非常宽、非常细致，那么这张表格就会更容易理解。常见的一些运营分析，是把一些维度进行交叉组合，就能够满足我们对数据的需求了。这就是一个新的概念——OLAP（OnlinAnalyticalProcssing）。也就是在线分析处理，常称作：多维数据分析。这里有两个关键的概念：一个是维度，一个是指标。
三数据分析方法
数据分析方法我主要讲六种：多维事件分析、漏斗分析、留存分析、回访分析、行为序列分析和用户分群。
多维事件分析就是把前面所讲的多维数据分析模型应用到事件上面去，达到一个效果。有了多维事件分析，我们再定位问题时效率要高很多。
第二种漏斗分析，漏斗分析对电商产品来说是必不可少。通过广告等方式把用户引过来，我们不仅关心客户他到了产品页面，我们还会关心客户是否会注册、是否会发生购买行为，这是就是一种漏斗转化，我们会关心每一步到下一步的转化率如何。我们可能还要按着某些维度进行拆看，看不同取值上有什么差异。针对图上显示的漏斗来看，我们把召回途径进行拆解，分析邮件和电话这两种方式那个更好。实际过程当中，我们可能会分析广告渠道，比如我们在优酷、百度、爱奇艺都投放了广告，我们分析不同的广告带来的转化效果如何。
第三种是留存分析。对于互联网产品来说，有两个指标是最关键的，即拉新和留存。拉新，我们通过漏斗分析不同渠道转化的效果。留存，我们就会关心用户来了之后接下来的行为是什么样的。比如通过地推活动引来一批注册用户并给了优惠劵，我们就会关心用户当天是否真的进行购买操作以及接下来每一天的行为，如果只有当天活跃而接下来都不活跃，那么这些用户仅仅是薅羊毛，对我们来说并不是高质量的用户。
第四种是回访分析，我们会分析关键行为的重复情况，比如复购。看一周之内的有多少天及多少次的购买情况，这就是复购，复购其实是留存的一种特殊情况。
第五种就是用户行为序列分析，我们针对一些抽样或发生某些关键行为的人，人工观看并分析，他具体在我们的产品中进行了哪些操作，看看和我们的预期是否相符，看看用户竟然进行了哪些我们没有意识到的操作。
四实践经验
以UGC产品分析为例。UGC即用户生成内容的产品，如贴吧知道豆瓣知乎等产品，这些产品相较于门户网站，不仅要关心访问量用户量，还会关心实际的发帖量等这些关键行为。以百度知道为例分析，在我07年刚加入百度知道的时候，每天都会收到很多几十封报表邮件，像访问量检索量等很多数据报表，很多也很乱，当时感觉似乎每个数值都很重要。但其实这是大家可能会遇到的一个实际情况，你会发现要监控的指标非常多，这时就一定要保持清醒，一定要关心哪个指标是最核心最关键的。
我当时就在考虑这个问题，渐渐的我发现，像检索相关的信息并不重要，因为百度知道本身依附于百度搜索，所以如果把百度知道的结果往前排，那检索就可能上升了，在这方面外部影响可能会更大一些。后来，我认为像提问量、回答量这些数据是比较关键的，那这两个到底哪个是相对更关键的一方面呢？我咨询了当时百度最资深的一个产品经理，他回答说：“提问量其实不是一个问题，像百度搜索里面很多人搜索的信息答案是不明确的，如果我们进行一个百度知道的跳转引导，那提问量可能瞬间就上去了。”这个回答一下子就打消了我的疑惑。所以，提问量可能确实不是最关键的，最关键的还是回答量，我们应该关心的是怎么样提高回答量，让用户的问题得到有效的回答。
接下来的问题就是如何提升回答量，后来我们做了一个事情叫问题推荐。问题推荐的逻辑是这样的，我们抽出了三十五万核心用户，即在最近三个月或最近半年回答过问题超过五次或六次的用户，然后根据历史记录抽出这些用户感兴趣的问题，且对他们进行模型训练。最终效果是这样的：在核心用户个人中心页面加了一个操作，猜你喜欢的模块，里面列了一些根据你的兴趣模型，推荐了一些待解决问题，比如我回答了数据分析相关内容，系统就会给我推荐相关的内容。
然后我们开始
转载请注明：http://www.dbmow.com/jbby/11460.html
