随着移动互联网时代的兴起和数据量的大规模爆发，越来越多的互联网企业开始重视数据的质量。在我创业的这一年里，接触了 200 多家创业型公司，发现如今的企业对数据的需求已经不仅仅局限于简单的 PV、UV，而是更加重视用户使用行为数据的相关分析。
文/桑文锋（神策数据创始人兼 CEO，前百度大数据部技术经理）
来源：神策分析（微信号：SensorsDataCrop）
做数据的同学都知道，在数据分析的道路上，数据采集是重中之重。数据采集的质量直接决定了你的分析是否准确。而随着企业对数据的要求越来越高，埋点技术也被推到了“风口浪尖”。所谓，埋的好是高手，埋不好反倒伤了自己。而在数据采集的道路上大家经常会遇到各种各样的问题，今天我们就来分析一下埋点是否需要。
首先我把数据采集的问题归结为三类：
1、不知道怎么采，包括采集什么数据以及用什么技术手段采集；
2、埋点混乱，出现埋错、漏埋这样的问题；
3、数据团队和业务工程团队配合困难，往往产品升级的优先级大于数据采集的优先级。
上面这三类问题让数据团队相当痛苦，进而幻想弃用数据采集，而尝试新方案后，进而迎来的是更大的失望。这里我对这三类问题的现状及应对之策做一下分析。
► 不知道怎么采
一般创业公司的数据采集，分为三种方式：
第一种直接使用友盟、百度统计这样的第三方统计工具，通过嵌入 App SDK 或 JS SDK，来直接查看统计数据。这种方式的好处是简单、免费，因此使用非常普及。对于看一些网站访问量、活跃用户量这样的宏观数据需求，基本能够满足。
但是，对于现在一些涉及订单交易类型的产品，仅仅宏观的简单统计数据已经不能满足用户的需求了，他们更加关注一些深度的关键指标分析，例如：用户渠道转化、新增、留存、多维度交叉分析等。这个时候才发现第三方统计工具很难满足对数据的需求，而出现这样的问题并不是因为工具的分析能力薄弱，而是因为这类工具对于数据采集的不完整。 通过这种方式 SDK 只能够采集到一些基本的用户行为数据，比如设备的基本信息，用户执行的基本操作等。但是服务端和数据库中的数据并没有采集，一些提交操作，比如提交订单对应的成本价格、折扣情况等信息也没有采集，这就导致后续的分析成了“巧妇难为无米之炊”。
通过客户端 SDK 采集数据还有一个问题就是经常觉得统计不准，和自己的业务数据库数据对不上，出现丢数据的情况。这是前端数据采集的先天缺陷，因为网络异常，或者统计口径不一致，都会导致数据对不上。
第二种是直接使用业务数据库做统计分析。一般的互联网产品，后端都有自己的业务数据库，里面存储了订单、用户注册信息等数据，基于这些数据，一些常用的统计分析都能够搞定。这种方式天然的就能分析业务数据，并且是实时、准确的。
但不足之处有两点：一是业务数据库在设计之初就是为了满足正常的业务运转，给机器读写访问的。为了提升性能，会进行一些分表等操作。一个正常的业务都要有几十张甚至上百张数据表，这些表之间有复杂的依赖关系。这就导致业务分析人员很难理解表含义。即使硬着头皮花了两三个月时间搞懂了，隔天工程师又告诉你因为性能问题拆表了，你就崩溃了。另一个不足之处是业务数据表的设计是针对高并发低延迟的小操作，而数据分析常常是针对大数据进行批量操作的，这样就导致性能很差。
第三种是通过 Web 日志进行统计分析。这种方式相较于第二种，完成了数据的解耦，使业务数据和统计分析数据相互分离。然而，这种方式的问题是“目的不纯”。Web 日志往往是工程师为了方便 Debug 顺便搞搞，这样的日志对于业务层面的分析，常常“缺斤少两”。并且从打印日志到处理日志再到输出结果，整个过程很容易出错，我在百度就花了几年的时间解决这一问题。
所以，以上三种方式虽然都多多少少解决了一部分数据采集的问题，但又都解决的不彻底。
► 埋点混乱
聊完采集方法，再来说说关于埋点的管理。我曾经接触了一家做了七八年的老牌互联网公司，他们的数据采集有 400 多个点。每次数据产品经理提出数据采集的需求后，工程师就会按照要求增加埋点，然后交给数据产品经理去验证。数据产品经理在试用的时候也感觉不到异常，可等产品上线之后，才发现埋的不对，再进行升级发版操作，整个过程效率极低。我们发现，一个公司发展到了一定程度，没有专人去负责埋点管理工作，数据采集就完全没有准确性可据采集就完全没有准确性可言。甚至有时产品上线之后，才发现数据采集的工作没有做，也就是漏埋了。
于是数据团队又开始幻想，既然埋点这么容易出问题，有没有可能不埋点？这就像寻找可以祈求风调雨顺的神灵。
在 2010 年，我的团队曾经做了一个叫 ClickMonkey 的产品，只要页面上嵌入 SDK，就可以采集页面上所有的点击行为，然后就可以绘制出用户点击的热力图，这种方式对于一些探索式的调研还是比较有用的。到了2013 年，国外有家数据分析公司 Heap Analytics，把这种方式更近一步，将 App 的操作尽量多的采集下来，然后通过界面配置的方式对关键行为进行定义，这样便完成了所谓的“无埋点”数据采集。使用这种方案，必须在产品中嵌入 SDK，等于做了一个统一的埋点，所以“无埋点”的叫法实际上是“全埋点”的代名词。
另外，这种方式同样也只能采集前端数据，后端服务器和数据库中的数据，依旧是无可奈何的。并且，即便进行前端数据采集，也无法深入到更细粒度。比如提交订单操作，订单运费、成本价格之类的维度信息，都丢失掉了，只剩下“提交”这一个行为类型。
对于非技术人员，容易被这种方式的名称和直接优势所吸引，但很快又会发现许多深度数据分析需求无法直接满足，进而有种被忽悠的感觉，会感到失望。其实不止是非技术人员，即使是技术人员，也都会让我解释一下“可视化埋点”的原理，说明“无埋点”真是个有迷惑性又不甚清晰的概念，难以细究。
这里说一下关键点：一是事先在产品上埋一个 SDK，二是通过可视化的方式，生成配置信息，也就是事件名称之类的定义，三是将采集的数据按照配置重命名，进而就能做分析了。
► 数据团队和业务工程团队的配合问题
最后，我们再聊一聊数据采集中遇到的非技术性问题。一般来说，公司到了 A 轮以后，都会有专门的数据团队或者兼职数据人员，对公司的一些业务指标负责。即使为了拿到这些基本的业务指标，一般也要工程团队去配合做一些数据采集工作。这个时候雷军的“快”理念就起到作用了，天下武功唯快不破。于是所有事情都要给产品迭代升级让路，快的都没有时间做数据采集了。殊不知没有数据指标的支撑，又怎么衡量这个功能升级是不是合理的呢？互联网产品并不是功能越多就越好，产品是否经得起用户考验，还是要基于数据说话的，然后学习新知识，用于下一轮的迭代。
数据团队和业务工程团队是平级的团队，而数据团队看起来总是给业务工程团队增加麻烦事儿，似乎也不能直接提升工程团队的 KPI，所以就导致需求不被重视，总是被更高优先级的事情挤掉，数据的事情难有进展。
解决之道
前面给大家抛出了数据采集中常见的三类问题，下面我们来看一下应对之道。
对于不知道数据怎么采的问题，首先从意识上要重视数据采集工作。数据的事情归结起来就两点：数据采集和数据分析。可不能只看到数据分析而忽略了数据采集。事实上我个人在百度做数据的几年里，最大的心得就是数据这个事情要做好，最重要的是数据源，数据源收集得好，就成功了一大半。数据采集的基本原则是全和细。全就是把多种数据源都进行采集，而不只是客户端的用户数据。细就是强调多维度，把事件发生的一系列维度信息，比如订单运费、成本价格等，尽量多的记录下来，方便后续交叉分析。
其次，要有一个数据架构师，对数据采集工作负责，每次数据采集点的增加或变更，都要经过系统化的审核管理，不能顺便搞搞。最后，我这里要推荐 Event 数据模型，针对用户行为数据，简化成一张宽表，将用户的操作归结为一系列的事件。
对于埋点混乱的问题，前面提到的数据架构师的角色，要对这块的管理负责。如果前面完成对 Event 的梳理，这里的埋点就会清晰很多。另外还要推荐尽量从后端进行埋点，这样便无需多客户端埋点了。当然，如果有行为只在客户端发生，还是要在客户端进行埋点的。对于业务复杂的情况，只有负责人还不够。目前我们神策分析针对这个问题，推出了埋点管理功能，对于每个采集点的数据收集情况，都能够做到全盘监控，并且可以针对一些无效采集点进行禁用。总之是希望把这个问题尽量好的解决掉。
对于数据团队和工程团队的配合问题，我这里是想说给创业公司的创始人听的。两个平行部门间的推动，是很难的。数据的事情一定要自上而下的推动，也就是创始人一定要重视数据，把数据需求的优先级提升，这样在项目排期时，能够把数据的需求同时做了。我们知道两军对战，情报收集工作的重要性。做产品也是一样，数据收集工作的重要性不言而喻。
最后，期望越来越多的创始人，从拍脑袋决策逐步向数据驱动决策做出转变。
·氧分子网（http://www.yangfenzi.com）延伸阅读：
➤ 电子科技大学互联网科学中心主任周涛：你也可以成为数据魔法师
所有的产品和决策都必须要有数据支撑，要不然纯属瞎胡闹！已经进入大数据时代关键是有的数据都没法埋点呵呵我经常技术性欺骗这些匿名搞数据采集的，增加他们的痛苦Netflix最厉害的就是数据分析能力，还有就是云计算的算法。连亚马逊和Google都自愧不如。
来公司俩月了，数据产品的PRD早都写完了，然而团队的开发资源都被运营和产品抢走了，完全看不到开土动工的迹象，公司就我一个数据产品，哎，悲哀。目前的大部分公司还是经验为主，数据为辅的运营模式。数据结论的实时性和可信度是决策参考的重点。还是得靠一个经验丰富的人拍板。“数据的事情一定要自上而下的推动，也就是创始人一定要重视数据，把数据的优先级提升”。赞一个，深有感触。
现在有很多采集软件可以采集到互联网的公开数据，感觉最好用的是gooseeker集搜客网页抓取软件，互联网上公开能看到的数据都能采集到，而且，还可以文字和图片一起弄下来，最重要的还是免费的，我用过很多抓取工具，使用高级功能都是要收费，而这款免费版的功能就比得上火车头的企业版了,通过概述性文献了解行业大致情况，然后细分需求，针对自己制定的数据分类表进行分类查询，但是都是以公开数据为主，商业数据和企业自建的数据库就要自己想办法了。。形式上简单说就是抄的heapanalytics.
功能上heap比growingio强一万倍。
原理上，用户点击页面时，把css选择器保存到server。统计用户点了哪些元素。用户可以把这个css选择器定义为无埋点元素来查看点击次数。
本质上，无埋点只是常规埋点的一个特别小的子集，因为无埋点只能选择页面上点击到的一个元素，或者加个选项比如这个元素的所有同类的元素。这就好比你每天只能吃蛋炒饭一样，但是实际上吃饭可以千变万化。
好处是，对于不会做饭的人来说，可以每天吃饭蛋炒饭。不需要厨子了。
但是你如果想统计当前页面鉴于后来gi张溪梦ceo的回答，我感觉到我之前说直接说抄的heap有点过了，只能说类似。也不能完全说是靠css选择器，只能说类似。当然heap的功能确实比gi强，这个毋庸置疑。而且无埋点只是埋点的一个子集，也是毫无疑问的。无埋点只是对于非技术人员的噱头，功能实在太受限制。如果到处宣称无埋点比埋点好，我觉得实在不能同意。
这就好像你说我花五毛钱买个烧饼，和花了50买个披萨。你说无埋点就想5毛钱的烧饼一样，我没有什么投入，但是我也能吃饱，满足需求。买个披萨，我还需要开发人员投入，但是你能得到你想要的所有数据，而且数据比无埋点精确可靠。
这也看用户的选择了，如果只是简单的填报肚子的需求，那用无埋点就ok了，简单省事，比如个人博客，个人小网站等不需要数据太精确的需求。如果需要精确的采集你要的数据，这必须要靠开发人员来埋点选择你想要的数据，比如电商网站，o2o站点等企业级需求。
“无埋点只是对于非技术人员的噱头，功能实在太受限制。如果到处宣称无埋点比埋点好，我觉得实在不能同意。” +1 对于真正想要“烹饪一桌好菜”的人来说，还是在有需要的操作上加更详细的监测代码，更便于理解和分析业务需求。对于数据团队和工程团队的配合问题，我这里是想说给创业公司的创始人听的。两个平行部门间的推动，是很难的。数据的事情一定要自上而下的推动，也就是创始人一定要重视数据，把数据需求的优先级提升，这样在项目排期时，能够把数据的需求同时做了。我们知道两军对战，情报收集工作的重要性。做产品也是一样，数据收集工作的重要性不言而喻。关于Heap，他们是湾区很好的创业公司，也是一个工程导向的团队。GrowingIO现在的产品和Heap产品在底层技术设计框架，分析理论以及核心功能上有很大的差异。您上面阐述的是Heap关注的CSS原理以及技术实现功能与GrowingIO专注的点是非常不同的，GrowingIO在技术上考虑的数据信息流框架不是以CSS选择器为核心进行的。过去10来年的网站和App分析的历程里，特别在LinkdeIn的分析过程中我们养成了更关注内容，而非只是容器的分析习惯。而且在后台的产品分析展示层，两种产品的设计思想有很大的分别。用户可以在界面和使用的方法上可以看出来基本完全不是一个思路。不过所有的创业公司都在各种分析自动化的都路上努力，我们希望中国的互联网企业也能用这种思想和产品提高效率。
大多对于可交互式的应用程序，例如Android应用，iOS应用，网站，Windows Phone应用，Windows的窗体程序、Java的窗体程序等等，其实在界面渲染时都有几点共性：
1. 图形背后都有图形树，我们所看到的输入框、文本框、按钮等等其实都是view，而view的摆放其实也都是有对应的视图方式，例如线性布局、网格布局、表格布局、相对、绝对等等，然后view加布局就组成了我们要看到的界面，比如最简单的就是网站的DOM结构了，有层级关系，对于Android而言就是View视图的层级关系了，调用系统级API基本上都能获取这个树结果。
2. 窗体都有生命周期，比如Android的Activity的生命周期
3. 对于我们可视的这些界面元素，当他们显示出来、被点击了、被选中了、被滑动等等操作的时候，系统也都会有相应的接口给开发者通知他们去处理，所以也就是对于View而言可以绑定或者委托或者是监听他们的一些触发事件，比如刚刚提到的加载、点击、选中等操作。
讲到这里，应该很清楚了，应用程序在呈现程序界面的时候，其实有一套生命周期的准则在里面，控制了从界面元素创造到响应用户操作到销毁，同时也有一个图形树的准则在里面，控制了这些界面元素的显示层级和顺序，最后在用户交互（包括展现）各个界面元素的时候，会给开发者提供一系列的接口，让开发者去处理这些行为。
所以原理清楚了，后续无埋点其实也就能想到怎么做了，现在市面上主流有两种，一种是预先跟踪所有的渲染信息，一种是滞后跟踪的渲染信息。两种做法不太一样，后者要简单一些，前者要重一些，但是也有一些办法优化（不交互的元素肯定多于交互元素），各家也就都有自己的方法在里面。
无埋点的技术，其实在国外，楼上已经有人回答了，Heap analytics是鼻祖，后续用户行为分析大佬Mixpanel也在去年中期推出了，诸葛io也借鉴了两者，在国内最早正式推出了三大平台的无埋点分析方案，同时，国内也还有talkingdata的灵动分析和growingio提供了无埋点分析方案。
多说几句，关于抄袭论，GrowingIO的CEO Simon已经回答了。诸葛io属于友商，也想站出来说两句，我们不能且以都为无码就论抄袭，无码也好，私有部署也好，多维分析也好，也只是方式或者功能，数据采集的方式或者数据分析的功能，但是分析工具承载很重要的其实是solution，也就是解决问题的场景，分析本身因为不同数据源，不同角色，不同部门，不同行业的需求不一样，所以场景也就很多样化。所以分析平台最大的差异也就不是功能，而是解决问题的场景。每一家都有自己的思考，经验以及方法论，从采集数据后的分析框架与擅用场景也就会有很多差异。
有人提及了无埋点和有埋点的优劣问题，选择无埋点还是有埋点也是建议大家从自身情况去选择，不同的分析工具和分析平台还需从自身分析场景来体验以及对比，才能找到最适合自己的。真正打动用户的不是趋之若鹜的功能或者噱头，还是在于能解决什么样的问题。
最后大家关注GrowingIO的同时，我也顺带提一句自家的诸葛io，国内（多次违反广告法）的精细化用户行为分析平台, 更多信息可以访问诸葛iO官网，或者诸葛io的知乎专栏和微信公众号，目前上线近一年，众多知名App和网站都已接入或购买我们的服务，专注于数据驱动产品分析和用户增长。
有人说 http://Growing.IO 跟 Heap Analytics 一样，这是不对的，你可以自己拿 Firebug 一类的工具抓包看看。http://Growing.IO 会抓取很多相关的上下文信息，也支持更复杂的查询和分析。然而所谓的“抓取所有的信息”是不可能，因为你根本没办法定义“所有的信息”。抓取的信息越多，也就意味着浪费的流量也越多，存储和索引的成本也越高。
做过信息检索的就应该知道，有一个最关键的概念是 precision/recall。http://Growing.IO 的策略是尽可能地提高 recall，而这个成本一部分是终端客户承受，另一部分是在 SaaS 服务的数据管线上增加压力。对于 PC 端的应用，这可能不是问题。但是对于移动端的应用，这就意味着更多的移动数据成本和耗电，此外还有相关的隐私风险。
个人觉得 http://Growing.IO 的技术对于 Web 来说是比较适合的，但是对于移动数据采集而言，有一种用高射炮打蚊子的感觉。个人觉得 Mobile Analytics 的未来是 Lean Analytics，仅采集需要的数据，并且尽量在终端上进行预处理。
当然，真正的问题是开发者是否愿意为数据服务花钱，以及愿意花多少钱。商业模式永远都比技术细节更加重要。
我的核心观点可以用“数据即业务”5个字去概括。对于这5个字的解释是：
数据是业务的一部分,相信互联网行业的出现让软件职业生态对于数据价值的认识达到了前所未有的高度。然而，互联网行业还是相对年经的，软件职业生态中很多人仍没有意识到数据其实是业务的一部分，大多人仍以更为传统的思想去看待业务，最终使得我们缩小了“业务”这一概念的范畴并将数据与业务加以孤立对待，结果导致大家对于数据工作的重要性缺乏足够的重视。
一旦理解数据是业务的一部分，工程师、产品经理对于数据的使用与关注度自然就会提高。对于工程师来说，更为直白的术语将变为“数据即代码”，也即对于数据的处理应当像对待那些非数据的功能代码一样去对待。
1）需要对数据进行设计。工程师需要从业务的角度去思考哪些点要埋、如何埋性能更优和价值更大等问题，这些思考应放到功能代码的设计过程中去。从这个角度来看，我并不认可全面埋点这种盲埋的方式，该方式对于数据的初始挖掘是有一定价值的，但成本与使用效率都不理想，对数据最有效能的使用方式一定是与业务（指功能）相结合去收集和表达。盲埋或许是以战术勤奋掩盖战略懒惰的前奏。
2）需要对数据进行重构。重构一词在业内使用得很广，相信读都能很快领略到我想表达的意思。一旦以重构的态度去面对埋点问题，就不会担心埋点的混乱与不到位的情况、不会陷入以静态的思维去看待理点问题。尽管希望存在“数据架构师”去把控数据的埋点质量，但最好的方式是“全民数据架构师”。后者虽然过于理想，但应是互联网行业的一种方向。理由是：让数据被重视一定需要每个人都参与到数据建设与挖掘的工作中去。“数据混乱”问题与“代码混乱”问题在当下其实是同一个问题。
数据驱动开发
我管理整个技术团队时发现，数据由谁来关注和使用是一个很大的问题。以前我认为应当由产品经理关注和使用数据，但实践表明很多产品经理其实也不理解数据的价值，或者他们所理解的价值其实也没有深入多少，更多停留于用户使用心理和行业的一些固有范式，别指忘他们从技术的角度去看待数据的收集与使用。当然，（我团队的）大多工程师也停留于我以前的认识，认为只要自己根据产品经理的需求去埋点就万事大吉。这一认识下的工程实践效果很是糟糕。
在后来，从与兄弟团队的学习中我发现，所有开发工作应当由数据去驱动更为有效。需要让工程师以数据表现去证明开发工作的价值，逼迫他们在工作中重视数据的收集与使用。数据驱动开发某种程度上需要工程师具备一定的产品经理思维，也让工程师掌握用数据去与产品经理探讨需求的价值，缓解“干得多但业务结果表现差”的情况。这一做法也必将使得产品经理与工程师有更多的共同语言，甚至达到减少对产品经理岗位需求量的最终目的（可以了解一下Google、Facebook这些公司中产品经理与工程师的配比情况）。
什么样的商业模式需要“大数据”？从行业来说，在我看来，任何Direct to consumer（DTC）的行业都是数据分析，数据挖掘等等发挥价值的地方。 也就是说任何的B2C,C2C，涉及到大量用户你无法人力进行一对一服务的行业，才是利用计算机的运算能力帮你解决问题的战略要地。大家都在讨论大数据与互联网、金融、政府等领域的结合，为什么谈农业大数据的这么少？相关的公司这么少？我想很大的原因是农业信息化的程度还不够。现在大家很少再提“信息化建设”这样的词，但在我的印象里从 2000 年左右，“信息化建设”是一个像现在谈“机器学习”一样时髦的词汇。那个时候不管是政府还是大企业，都在推进信息化建设，上线 ERP、官网、办公系统等，那是一波浪潮，持续了十年左右。从 2010 年左右开始，这种生意就没那么好做了，许多的潜在企业已经被挖的差不多了。但农业的信息化，可以说是原地踏步，和工业领域完全不在一个阶段。那么到了大数据时代，工业领域至少还有了一定的数据基础，但农业是完全没有的，可以说数据驱动的前提肯定是要信息化的。
再来谈数据分析，如果没有数据，就谈不上分析了。最近听到一个新员工讲到她在一个企业做数据分析的经历。当时一个部门，每天都在做各地仓库的配货，各个品类配多少，是凭经验来的，往往是漏洞百出，每隔一段时间，都要做次清货。于是她自告奋勇，在 Excel 上写了一段代码，根据以往的销售记录，来预测配货量。就这么一个简单的程序，让经营效率提升了很大。这里并不是这家企业掌握了更多的数据，而是采用了更多的数据分析的方法。这里我想说的是首先要培养数据驱动的思维，就是在各个业务环节，能不能基于某些数据来更好的做决策，利用机器去代替人工的工作。这种意识培养起来了，对企业就是一种革新，有了新的发动机。
我们再来说说为什么要做数据分析。在上世纪 80 年代的时候，曾经发生过商店买的冰箱门已经坏了，然后问顾客要不要买，如果不买，就让下一个顾客买，还有更多的人排队。那个时候是商品匮乏，供应不足，销售的问题根本不需要考虑，主要矛盾是把商品生产出来。到了 2000 年之后，像家电类的商品，供大于求的时候，就开始铺广告，建销售体系，只要这些做好，产品就可以卖出去了，归根到底是需求还在。可最近这几年，人口红利渐渐没了，竞争变的更激烈了，导致人力成本变高和供大于求，这样赚钱就没那么容易了，靠以前那种堆人的思路玩不转了，必须考虑精细化运营。对于铺的广告，不是说央视上播放了，看着挺气派，这就成功了，还是要看实际转化效果如何。对于潜在客户及已有客户，分析他们的特点，制定针对性的营销策略和提供合适的服务，这些都需要数据分析的支持。
目前已经有了一堆数据，如何从这些数据中获取更大的价值？这个问题如果让我直接给解决方案话，大部分的时候是给不出来的。虽然我对大数据分析技术比较熟悉，但对于各种各样的实际业务，那是很不了解的。大面上的思路，可能谁都能想到。在大数据概念的普及之下，大家都对数据的重要性不再怀疑，你再见到人时，不用花时间去说服对方相信数据很重要了。但这也带来了一个误区，就是不管有了什么数据，都想通过这些数据来产生巨大的效应。我的建议还是反着思考，先要围绕现有的业务场景，思考还有哪些关键问题没有解决，然后考虑解决这个问题，需要用到哪些数据，如果正好有，那就省事了，如果还没有，再想办法收集这些数据。也就是问题驱动，而不是数据驱动，数据起到的是辅助作用。还有就是前面提到的数据驱动的意识，这是第一重要的。
说了这么多问题，那到底有没有传统企业在大数据分析这块做的好的呢？我这里讲个餐饮业的案例。盈客在线是一家为餐饮业提供 S-CRM 的公司，会帮着餐饮品牌店做会员营销方案，比如会开展会员日这样的活动，某些菜品针对会员客户半价优惠。那这里问题就来了，这样会不会导致会员们只会在会员日过来用餐，其他时间就过来的少了？单凭猜测是不行的，我们还是要看数据。于是盈客在线的数据工程师针对一家品牌店做了用户留存分析，就是看有会员日活动的会员店，和没有会员活动的会员店，在用户留存上有什么差异？结果分析发现，有会员日活动的留存，要明显超过那些没有会员日活动的店家用户留存。
B2C公司的数据团队应该有，DW和BI，DW包括产品经理，ETL开发，DBA，运维
BI就是数据分析师，DW是必须的，BI是备选，在前期没有DW，可以由GA来代替，让BI做数据分析，但是GA只能做简单的点击流，不能做到最深的商品运营图，数据走势,个人觉得数据是为业务服务的，所以所有涉及到前端的数据都应该划归到业务部门去！
那数据部分做什么？两件事情
1、数据的展现（可能PD的活比较多）
2、数据挖掘的支持（这个比较专业）
其他就别做了，越做越郁闷，分析和市场、运营、产品脱节都很厉害的,每个公司应该都不太一样，部门职能肯定会有区别，像我们公司，数据分析部门称为参谋部，他们只对运营数据、市场数据等等进行分析，其它神马技术类的操作又规到技术中心了，技术中心会在参谋部有需求的时候进行技术支持。一般应该包括：
运营分析师：销售数据分析，运营项目分析，用户分析
网站分析师：流量分析，广告效果分析等
DBA：主要支撑分析师提取数据
如果再做一些大型项目，还应该包括：
数据产品经理：系统搭建，规划，比如流量分析系统，运营分析系统,竞争对手分析等
数据仓库工程师：底层数据搭建，比如log点击流数据搭建，底层销售数据搭建等
算法工程师：负责bi项目算法的实现，比如个性化推荐算法等,
一类是应用产生数据
主要内容的满足应用需求所需要的数据，作为监察系统所需要的是实时流式数据（交易系统实时数据）和批量块（结算系统批量数据），数据类型的是文件数据和关系型文本数据。此类数据量占总数据只有10%，传统基于小型机的关系型数数据处理系统可以处理此类数据，基于大数据平台技术的实时处理计算系统也可以处理此类数据。
另一类是行为产生数据
主要是应用系统衍生的行为产生的数据，即与监察系统相关的企业行为数据，互联网产生的关联数据等等，数据类型的是XML, html, log, tag…。此类数据量占总数据量是30%，传统基于小型机的关系型数据处理系统可以处理此类数据的一小部分结构化数据；大量半结构化和非结构化数据只能由目前新兴的大数据平台技术进行处理。
最大的一类是机器产生的数据
主要是运行机器时时刻刻产生的大量日志数据（syslog日志数据），互联网网络爬虫爬取大量非结构化文本数据等等。这些数据在以往传统架构的解决方案中，由于数据量巨大都被忽略了，此类数据量占总数据量是60%；目前新兴的大数据平台技术完全可以采集分析处理这些数据，揭示数据背后的关联关系。
基础数据平台主要的数据采集源是关系型数据库的实时交易数据和监察数据，以及其他辅助数据，数据类型主要涵盖了结构化的关系型数据，半结构化的数据和非结构化的文档、图片影像等数据。
腾讯的数据源也分别来自这三个。
数据采集看你本身需求的规模，如果是大规模的维护系统，可以用专门的采集引擎,比如基于apache服务器的nutch。如果以填充网站为目的，觉得哪个网站的内容好，想借为已用，这种需求随机灵活，而对抓取量又不太高的采集，可以采集python的爬虫工具scrapy。当然php也有可以实现各种网站抓取的方式，但是似乎没有成型的框架，因为抓取本质是基本网络协议，http什么的，所以你对这些协议了解的清楚，又懂一些脚本语言，基本都会画出一个可以实现你需求的采集的工具。但是效率就千差万别了。框架会提供你完善采集的多元素补充，你几乎涉及到采集应该处理的全部问题，它都给你提供了对应的方案，你有耐心死扣方案，总能读懂他传授你的意思，然后按理为之，就可以不断把自己的爬虫实现起来。但是采集只是数据处理的一个环节，采集之后如何对数据提纯精炼，基于自己商业化目的的导向，可能还涉及到知识产权等问题，当然这不是技术采集考虑的层面了。至于数据的分析，当然，我都是用python多一点，pYthon提供了许多内置的math函数处理库，比如说numpy,scipy,matplotlib,这些网上都有对应的使用教程，入库或把采集到的数据按这些组件可以处理的格式保存，然后把数据导入进来，折腾吧。1.数据采集工具如火车头采集器
2.Python爬虫
从去年到今年，整个互联网行业遭遇到了非常大的挑战。首先是互联网流量红利的逐步消失，使得大家在获取新用户上不得不投入更高的预算，由此也逐步开始重视用户的精细化运营，留存和复购也成为很多从业者非常关注的运营指标。
其次，资本市场迎来了一个寒冬期。在一轮狂热之后，资本的态度更加理性，逐步回归到商业的本质，对企业的收入和盈利有了更高的要求。由此也使得很多从业者的关注焦点从 PV、UV 这些流量指标，转向了 GMV 等收入指标。因此，本次活动就和大家探讨如何实现 GMV 的增长，如何提升用户的留存和复购。
从活动中你可以学到什么？
运营工作的核心是数据驱动。本次活动会从不同维度的数据层面，来讲解如何通过数据来分析和定位问题，提升 GMV 的增长，并邀请到业内知名的数据驱动业务的公司，为大家介绍他们的 GMV 增长实践案例。
活动推荐人群？
如果你是一名企业高管，或者运营、市场的相关人员，相信活动一定可以让你有所收获。
活动时间地点：
2017年5月21日 13:30 ～ 2017年5月21日 16:30
（北京海淀）中关村创业大街昊海楼5楼盛景网联
活动嘉宾介绍：
李爽：神策数据数据分析专家
曾就职于美团、汽车之家数据仓库开发工程师，主要负责 C 端数据开发。
现就职于神策数据，负责旅游、游戏、网络文学等行业。先后主导广发证券、百度文学、金山云、点点客等项目。
夏苏敏：Ping++ 大数据总监
曾就职于百度大数据部门任资深产品经理。先后负责百度预测、百度司南、百度大数据+等多款大数据产品，对于数据的分析和价值挖掘有非常资深的理解。现在在 Ping++ 主导并负责大数据产品的设计和研发。
于高禾：一亩田基础业务负责人
本科研究生毕业于北航。曾就职于当当网、百度，负责数据、推荐等方面的工作。
2014 年加入一亩田，目前负责交易、支付、广告、数据等基础业务。