数据建设工作该如何展开

　　数据建设工作并不是一件简单的事，在做好数据建设是需要讲方法的。
　　之前有个读者给亮哥留个言，但亮哥无法回答，只有沉默了，想了想，今天还是写一篇文章吧。
　　读者问：
　　亮哥你好，看你的书很久了，但是有一个问题困扰了我很久。在做用户数据分析的时候，我们常用的第三方类似Umeng这种统计工具，其相关数据是不互通的，也就是我没办法从用户的活跃数据，反推到这部分用户在功能使用上的情况。另外多数公司在人力物力上的不足，以及时间成本的影响，都没有条件自建数据统计工具，这种情况下，有没有什么比较好的办法，可以处理这样的矛盾呢？另外自建数据统计系统，有什么好的建议吗？
　　1。数据的维度
　　维度这两个字，很多人在做数据分析提需求的时候，都会碰到。
　　但也有很多人写成纬度、围度，其实亮哥不知道哪个是对的，但是从我的理解来说，维度比较合理。
　　在互联网里工作，对数据这件事情，可以说，任何一个工种，都必须与之打交道，只不过关注的点可能并不一致而已。
　　对于做市场、PR、公关的同学来说，他们关心的是大而化之的数据，你会发现那些市场品牌宣传稿、公关稿里谈及数据，都很大，譬如：
　　某产品上线至今，拥有X万亿注册用户，日活用户超过Y万亿，平均每5分钟，产品就会被下载一次每秒钟同步处理Z笔交易
　　诸如此类。
　　对于做产品的同学来说，他们关心的是用户怎么使用产品，用户从哪些入口进入，在哪些页面或功能点上停留进行使用，多长时间或达成何种目标后离开。
　　对于做运营的同学来说，他们关心获取一个新用户需要多少钱，自己的活动有没有好看的ROI，自己申请的预算是否带来了预估的效果，下个月的KPI究竟是用户活跃还是转化付费。
　　所以，如果一家公司里，没有人关心数据，或者说，该关心数据的人不关心数据，或者关心了错误的数据，那就是一场灾难。
　　数据的维度非常广泛，有时间维度（日、月、年、时、分、秒），也有动作维度（注册、激活、登录、使用、转化、付费、流失），还有空间维度（访问时长、页面数），以及各种率。
　　对于一家企业来说，想要好好的运营（我说大运营），对于数据的把控是十分重要的，这一点不必多说。
　　2。做产品最需要知道的一些数据
　　Web和App，大家关心的点是不一样的。
　　大多数人会接触的都是非常表层的数据。
　　譬如说，Web时代，讲究UV、PV、访问页面数、停留时长，这些看起来是很通用的指标；App呢，就讲究注册用户数、活跃用户数、付费用户数，这些看起来也是很通用的指标。
　　所以，你会发现，Web时代，Google、百度都会提供统计工具，实现方式也很简单，申请个账号，获取一段代码，把代码放到每个页面里，这是最粗的做法；App时代，也有人提供统计工具，友盟啊、诸葛io啊，之类的，有些只要你接入SDK，有些则需要你上线部署。
　　但是，我说的这些都是很粗的维度。
　　这些粗颗粒的数据，在粗放式运营时可能很管用，但是它们都只能体现最表层的数据，也就是说，你可以通过数据的走势去判断目前产品的健康程度和成长情况。
　　但是，一旦数据发生大波动，你想要找到原因，就难了，因为这些宏观数据并不进入微观领域。
　　你想要了解微观，那么，Web时代，你要会配置路径，所谓路径，就是流量从进入到离开，经过的路线，和打游戏一样，你要植入足够的侦察力量，你才能拿回来一些情报用作监控，或者分析；App时代呢，你需要有自己的数据团队，他们要能够去通过埋点搭建出用户的行为模型，在模型里，可以看到用户的使用情况。
　　其实就这么简单，因为这些都是基础工作。
　　而在基础工作中，提出需求和上线解决就很重要，这也就进入了这位读者纠结的部分。
　　3。如何提出数据需求
　　这里，亮哥要和你聊聊怎么去提数据需求，以及从哪里去摸出数据需求的线索。
　　如果今天，开发团队里有一个数据小组，你知道作为运营要如何去提数据需求吗？
　　第一，你要非常了解业务。
　　什么是非常了解业务呢？我在训练一个数据专员的时候，会要求他用2周时间，什么事儿都不干，去和每个业务Leader聊天，弄清楚目前涉及到各业务的产品中，整个业务流程是怎样的，用户的使用流程又是怎样的，需要几步动作，最后会反馈什么。然后回来和我说，能说清楚的，进入下一环，说不清楚的，重新去了解，直到能掌握业务的真实情况才算完成。
　　第二，要基于业务的未来去提埋点需求。
　　也就是说，要建立数据体系，不仅要知道业务的现状，也要非常了解业务的未来，这个时候，就需要一张清单，目前业务涉及的产品，都做了什么，还有哪些是未来一段时间（譬如，3个月）会进行调整的，清单里要有功能、埋点状况、计划完成时间等一系列的状况说明，然后备注需要通过这个埋点，了解什么。
　　譬如说，一个注册流程。
　　注册流程是否简单，我们可以通过：注册完成率、X步放弃率来看，那么就要统计进入人数、注册用户数、资料填写的每一步的完成和放弃的绝对值与比例。
　　可能你会说，知道注册完成率就好了，为什么要考虑X步放弃率。
　　很简单，X步放弃率中的X步出现越多，就证明这一步存在问题，进而要去提出优化假设并通过数据验证，是否让X步放弃率降低。
　　第三，需求明确，且重点明晰。
　　我真的有见过，去问需要数据埋点吗？需要。怎么个埋法，哪些位置需要埋？答曰：所有都要。
　　其实这种回答代表着，要么没想清楚自己要什么，要么是根本不知道应该关注什么。
　　我们在数据建设中，有一个名词叫做经营分析关键指标项，这个名词的意思是：不管业务涉及多少数据，只要这个指标发生变化，数据就一定会对应的有变化，而且是大变化。
　　譬如，电商里有个公式，叫做：
　　销售额销售单价x销售量。
　　这里面，如果要销售额增加，那么要么单价上升，要么销量上升，所以，这两个指标就是关键指标。
　　但是，如果商品本身的售价一直都很稳定，那么关键指标其实就是销量。反过来，如果数据表明，这个商品本身价格是坚挺的，不存在随意修改的可能，那么关键项就是拉动销量增长，你可以不用关注单价变化，反之亦然。
　　所以，提数据需求一定要弄清楚核心数据和边缘数据，关键数据与辅助数据，提出来的需求才有人愿意和你玩。
　　4。数据的分层次推进
　　如同提问者问的一样，很多公司并没有那么多的财力、物力，还要自己做数据平台吗？
　　我的回答必然是：要！
　　问题是，怎么做？
　　这里就要谈到一个层层推进的问题了。
　　前面已经提到了，有些数据的颗粒度很粗，可以利用第三方去完成，而一旦进入业务支撑的数据分析，靠第三方就不太可能了。
　　那么，不管你是多小的公司，分层去推进数据建设这件事儿，永远是成立的。
　　Step1：搞定核心业务的数据
　　埋点本身是费时费力的活儿，但是我相信，只要是能活下来，或者有希望活下来的公司，即便没有找到商业模式，也应该意识到自己的核心业务是什么了。
　　那么，围绕核心业务所需要的数据，先把这个业务的所有数据的埋点给做掉，就是最初要做的事情。
　　Step2：明确核心业务的数据呈现结构
　　有些业务是漏斗式的，用户通过1、2、3的分步骤操作，来完成业务流程，那么，通过建立数据漏斗，就能看到用户在整个业务流程里实际的使用情况。
　　譬如说，交易平台，用户的业务流程是：
　　浏览下单支付收货评价
　　你其实会发现，漏斗在这里是明显存在的，浏览下单有下单转化率；下单支付有支付转化率；支付内部有支付成功率；支付完成收货有个确认转化率；收货完成评价，有个评价转化率。
　　但对于核心业务流来说，前期只需要去搞定浏览下单支付，即可。
　　什么，人力还不够？那么下单支付总归要做的。
　　等把核心业务流做完，再去向前和向后去延伸埋点布局。
　　同理，当核心业务的数据建设告一段落，就继续去做其他的非核心业务的数据建设。一个一个来，虽然看起来工作量不小，但总有完成的一天。
　　Step3：埋点建设与报表输出
　　第二步做完就赶紧先埋点。有能力，去做自动化报表，没能力，用个简易后台提供查询即可，再没能力，数据同学提供查询SQL，开发权限给相关的接口人员自行提供查询。
　　Step4：如法炮制其他业务的数据建设
　　做法基本一致，只要能做一个，就能做第二个，并不难。
　　5。自动化不急于一时
　　很多时候，数据建设工作难，其实是难在怎么去做自动化。
　　自动化当然好处多多。
　　不用手工SQL，直接系统邮件日报表、周报表、月报表；
　　对关键指标项直接监控，有问题通过各种渠道报警相关人员；
　　但是，并不是一开始就要做自动化。
　　运营常常说，有工具要上，没工具靠人肉也要做。
　　道理是一样的。
　　关键是，对于数据建设这件事情的重要性，公司和老大们是否意识到了，是否愿意去给资源？
　　如果没意识到，以上这些都是废话，如果意识到了，我觉得作为运营人员，学会提需求，足矣。
　　一个很现实的问题是，大多数老板并不真的关心数据。
　　我记得在某公司的时候，数据老大和我聊天说漏嘴，他说，整个公司，你访问数据的频率是最高的，基本上每天都在看，但是我们老板，从来不看数据。
　　其实，做数据的人，最怕2件事儿：
　　做了没人用没人看；
　　看了没人反馈提问题或者提需求。
　　所以，为了不让数据同学付出的心血浪费，一旦公司决心要做数据建设，那么这条路就要坚持走下去，并且，提需求的记得一定要多多去看数据。