社会热点

做数据分析如何保障数据的准确性?

电脑版   2020-11-26 10:03  

做数据分析如何保障数据的准确性?:从业多年,在数据准确性上摔过不少跟斗,总结了一些切实有效的方法,能够帮你尽可能的规避错误,确保数据的准确性,分享给大

1

从业多年,在数据准确性上摔过不少跟斗,总结了一些切实有效的方法,能够帮你尽可能的规避错误,确保数据的准确性,分享给大家

对数据上游的管理

虽然看上去,数据分析师是掌握数据资源的人,但从数据的生产流程来看,数据分析师其实位于数据的下游,数据需要至少先经过采集环节、清洗环节、存储环节才能被数据分析师拿到,甚至有的体量特别大的数据,他的调取和处理环节也不能被数据分析师控制。所以,想要最终做出的数据不出错,那就要先确保我们的数据上游是准确的。

虽然数据上游一般是由其他业务或技术人员负责,但数据分析师也可以通过提需求或生产过程参与的方式,对数据上游进行管理:

  • 采集环节,负责采集环节的业务或技术人员往往会把注意力聚焦在采集实现方式上,而忽略了采集来的数据本身对应的业务含义,数据分析师需要在这个环节上跟他们反复说明根据业务含义反推出来的采集细节,确保大家在理解和实际执行上没有偏差,最好在设置一些采集质量的控制点,帮助业务或技术人员做好采集工作。例如,APP的数据采集经常需要前端技术同学进行打点采集,这时数据分析师应该和技术同学一起讨论打点方案的各个细节,比如“启动”这个点对应的业务含义是想计算每天的活跃用户数量,那么启动点的采集就应该既包含点击APP图标启动又包含后台呼启,其中后台呼启与上一次退入后台的时间间隔应该至少大于30秒,否则可能被认为是用户的正常操作而非完成一次使用后的退出,30秒也是根据业务实际情况人为讨论设定的。
  • 清洗环节,分析师应该在确认采集环节的细节后跟数仓工程师沟通数据清洗的规则,比如某个字段可能会含有某些方面的脏数据,需要通过何种规则被清洗掉。例如,打点采集上来的行为数据可能会因为用户手机网络环境问题或其他前端原因而导致上报的行为时间戳错误,那么清洗的时候就应该利用获取到的数据上报时间戳去填充或直接去掉这条记录。
  • 储存环节,数据分析师应该根据具体业务的实际需求,向数仓工程师提出相关的结果表建表需求,和与之配套的调度需求,同时也可以利用上一节梳理过的数据分析指标体系参与到数仓结构规划的讨论中。例如,公司管理层需要每天关注的核心数据指标最好统一放在一张结果表里储存(为了提升BI的计算效率),管理层每天要在早上10点看到,那么对应的数据分析师应该在早上8点看到(以便提前发现问题并留出修正时间),结合数据采集和数仓拉取时间那么保险起见应该在7点完成底层表调度。
  • 调取环节,我建议数据分析师能够梳理出一个常用的数仓表文档,便于平时日常的数据调取,而如果用到相对陌生的表则应该先与数仓工程师沟通确认表的字段含义、数据源头等再进行调取使用。
  • 处理环节,遇到体量比较大的数据需要借助工程师进行处理时,应该先明确好数据处理的要求和步骤,最好落实成一个执行文档再交给工程师让他按此进行处理,处理结束后要对数据结果进行核验。
设立数据“安检站”

“大包小包过机安检”只要你坐过北京的地铁,相信这句话一定耳熟能详,为了确保所有旅客不把易燃易爆等危险品带入地铁内危及他人安全,地铁在每个进站口设置安检站对所有过往人员物品进行检查。虽然避免数据错误的最主要方法就是检查,但全流程无休止的数据检查显然是费时费力且效率低的,我们其实也可以在数据流入流出的关键节点设立“安检站”,只在这个时候进行数据检查。

一般我会在这些地方设立“安检站”:

  • 数据调取完成,如果原材料出错,后面一切都错,所以你需要把住数据流入的第一道关。
  • 数据处理完成,你需要利用数据处理后的结果进行分析判断,如果处理结果出错,你可能会因此错失关键线索而在问题里打转,会浪费远比你检查一下数据而多的多的时间。
  • 数据报告撰写完成,这是数据流出前的最后一道关,当然要仔细检查一遍,出了这个“安检站”,数据错误就会暴露在外无法再挽回了。

几种行之有效的检查方法:

  • 直接核对,拿处理前和处理后的某条数据对比,虽然简单粗暴,但对于一些关键数据的确认很有必要。
  • 勾稽关系验证,利用数据与数据之间的逻辑或计算关系,来验证数据的准确性。比如,A+B=C或者A>B>C。
  • 参照对比,跟历史或同类数据对比,看看数据是否存在比较大幅的差异,如果出现差异又没有对应的背景原因的话,那很有可能数据错了。比如,平时的月新增用户是30万人,但最新一个月变成200万,且这一个月并没有追加大成本做推广,那么很有可能是数据错误。
  • 穿行测试,偷师审计中经常使用的一个方法,审计上的穿行测试(walk through testing)是指追踪交易在财务报告信息系统中的处理过程,而我们这里的穿行测试是通过一个实例数据去检查数据中的各个环节是否符合逻辑,比如用几个少量的购买用户ID去用户活跃数据、用户广告浏览和点击数据、用户购买数据等中去找他们实际的数据记录看看与逻辑是否吻合。这个方法一般用在数据调取完成后的检查。
  • 业务事实判断,一个很郁闷却经常发生的事情——数据分析师检查了几轮都没发现的错误,却会被老板轻易发现。老板其实并不比分析师掌握更多的数据,他们只是对业务更熟悉,他们会根据业务的实际情况对具体数据有一个预判,比如某个商品昨天的销量,数据分析师看到的只是个数字,而老板看到的却是这个产品经历了怎样的设计和讨论、前期做过多少次头脑风暴或市场调查、与之匹配的推广投入是多少、同类型竞品大概能卖出多少等等,这些事实让那个简单的数字变得丰富,而数字但凡出现一点点错误都会与那些历历在目的实时场景不符。我们可以学习老板们的这一点,也找寻一些业务事实或者直接询问业务人员业务情况来辅助我们对数据准确性做判断。
确保数据准确的几个日常习惯

除了上述成体系的错误规避手段外,几个日常的好习惯也可以让我们尽可能的离错误远一点:

  • 养成数据监测习惯。每天要把重要的数据指标全部过一遍,最好能结合业务变化进行数据监测,这个过程可以通过写每天的数据日报完成。很多重大的数据调度问题我都是靠数据监测发现的。
  • 先于其他人看到数据。每天尽量早点到办公室,在其他同事尤其是老板还没打开每天的BI报表之前,先看到数据,如果发现问题能够及时纠正或至少能先行通报数据错误。
  • 别太相信自己的记忆。人脑不是电脑,一定有记不清记不准的情况,所以如果能有足够的时间查询一下数据,就别自己靠记忆去回答数据问题。
  • 尽量为自己争取多一点时间。很多错误往往是我们准备时间不够,慌乱中压力大容易错,又缺少必要的实际检查,所以尽量为自己争取多一点数据准备的时间是很有必要的。
  • 永远带着电脑。既然不能依靠人脑,那就只能依靠电脑,在任何可能会发生数据查询的时间和空间内最好都带着你的电脑。
  • 如果发现数据错误,一定要及时承认并在第一时间修正,如果想掩饰一个错误,那么就可能会引发更多的错误。

以上,是确保数据准确的大致经验总结,几句最关键的话再重复唠叨一下:

  • 信任是数据分析师立足的根本,一点点的数据错误就可能将积累了几年的信任迅速毁掉。
  • 永远别忘记检查,无论时间多紧迫,无论任务难度多小,无论数据提供给谁
  • 数据分析是个“勤”行,一定要尽可能深入业务和技术的各个层面,一定要跑在别人看数据的前面。

本文版权归原作者所有,如需商业用途或转载请与原作者联系。

分享

相关信息
 
李靓蕾会原谅王力宏吗

2021-12-30 14:01:01