数据运营：数据建设是需要讲方法的

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