如何更好的提数据需求

　　本文主要是介绍业务部门（主要是运营部门）在没有完善的数据平台时如何更好的提出数据需求，来满足自己某些数据分析。
　　一、谁会提数据需求？
　　一般来说的话，更多的是运营提出的数据需求会更多。不过也会存在其他业务部门，比如财务、结算、市场、技术部等其他业务部门。
　　二、有哪些数据需求？
　　产品数据：PV、UV、页面跳出率、DAU、留存率、事件转化率、用户属性等等。
　　业务数据：注册数、下载数、订单数、取消数、注册转化率、订单转化率等等。
　　三、如何提数据需求？
　　举个栗子：国庆节会上线一个新业务的推广活动页，到时候领导需要看到这个新业务上线后的效果情况如何？
　　时间规划
　　虽然是国庆节上线，但是作为数据需求提出方，需要有时间规划的意识。不要等到活动页上线之后，再去和产品、数据小组提相关的数据需求，而是要学会把需求前置。特别是活动页的PV、UV等用户行为数据，因为如果在上线前没有提出需求，开发一般不会主动埋点统计的，所以等上线后发现没有埋点，已经为时已晚了。另外业务数据虽然可以从数据库中提取，但是由于提出需求时间在上线后，留给数据小组的处理时间不多，往往会造成领导时时催你要数据，你时时催数据小组帮忙提取基础数据。
　　分析维度
　　上线一个活动页，作为运营你要知道领导想看上线后的效果，那么效果情况能从哪些数据进行呈现。这个过程需要哪些基础数据，如何利用这些基础数据来进行分析。其中最重要的就是基础数据的来源。所以运营前期提数据需求时一定要明确基础数据的维度是什么？避免基础数据不是自己想分析的数据，以及减少与产品、数据小组来回沟通确认的时间成本。
　　假设场景：
　　运营：我需要国庆期间所有的订单数据…
　　数据员：要订单的哪些数据？订单号、用户ID、下单时间、预约取货时间、预约还货时间、订单状态？？
　　运营：哦哦，我要订单号、用户ID、下单时间、预约取货时间、预约还货时间、订单金额。
　　数据员：是下单时间在10.1-10.7号之间的订单数据？预约取货时间在10.1-10.7号之间的订单数据呢？还是实际取货时间在10.1-10.7号之间的订单数据？
　　运营：我要下单时间在10.1-10.7号之间的订单数据。
　　数据员：所有订单都要吗？还是只要预约成功的订单？
　　运营：只要预约成功的订单。
　　…….
　　以上沟通花了半天，这时候数据员把订单号、用户ID、下单时间、预约取货时间、预约还货时间、订单金额这些数据给运营了。运营埋头抓紧分析了，分析的过程中发现订单金额明显偏大，超出日常订单金额的平均值。
　　运营：你给我的数据，订单金额怎么那么大？是不是你拉错了？
　　数据员排查半天…
　　数据员：没有啊，这个就是订单金额。
　　运营思考半天…
　　数据员：你是不是没有排除优惠金额啊，订单金额要排除使用的优惠金额的。
　　数据员心里一万个草泥马…
　　上述这个场景，可以说是数据员还是比较负责的，会去和运营确认所需数据是什么。但是耗时较长，处理效率较低。那么如何避免此类情况的出现？需要运营明确基础数据分析维度。
　　就拿上面这个场景来说的话，需要明确时间维度、订单维度、所需字段的特殊情况。最好是能够了解订单表常用字段，一方面是可以具体告知数据员要什么字段，提高处理效率；另一方面便于辨别数据员提供的数据是否存在异常。如果不了解表结构也没关系，但是需要准确告知你要什么类型的数据以及相关特殊情况。
　　表达目的
　　提数据需求的时候，运营可简单描述此数据需求的目的。比如谁要这个数据？为什么需要这些数据？这些数据用来分析什么内容的？
　　表达目的主要有三个优点：
　　需求是否合理，产品、数据员作为需求接收方，可以根据此需求来评估需求是否合理，不合理的情况是可以打回需求的。
　　需求优先级，产品、数据员接受到的需求很多，如何给你的需求进行排期，取决于你的需求是谁提出的？要分析什么数据？能解决什么问题？进行评估需求优先级，之后进行排期处理的。
　　需求是否存在优化空间，针对运营表达的目的和所需的基础数据之间对比，为了能更好的满足所表达的目的，基础数据是不是可以有优化的空间，便于提供更优质的基础数据供运营进行分析。
　　四、总结
　　简单的来看，运营提数据需求好比是用户提产品需求。由于需求是内部员工提出，占有一定的主动权。所以需要明确时间、维度、原因三要素，便于产品、数据员高效、准确的完成此数据需求。