1.主要集中在传输处理，即在数据仓库内部做数据质量检测。我认为这样做的原因是在于不同团队的协同机制无法做到完善，所以只能保障数据团队内部（含分析师）可掌控的数据质量情况。这个也是成本间的权衡，关键点就在于人手不足（含人员流动，业务收缩等因素）以及顶层领导重视程度（老师所提到的考核机制在这个阶段可能会是“得罪人”的事项，会给人“多做多错”的感受，这个是我个人的推测）。所以在业务导向更重的情况下，源头采集监测较难实行。而应用监测上来说就是没有完善的指标体系，所以量化什么指标监控也是空中楼阁。 2.我个人倾向于实用优先+完美主义路上多走一小步，即要满足业务诉求前提下多提供一些质量完善的措施。比如我曾经碰到一个诉求，是要看兑换码兑换的源端，这个数据在服务端没有存我只能拿客户端日志来匹配，这样便造成了一小部分数据有问题。原则上将追求准确性应该是让业务开发再迭代处理，但是考虑到现阶段运营只是拿数据做参考，所以也就和运营讨论后认可了当前做法。这件事给我的启示便是不要替运营擅自做决定，因为不同角色的立场是不同的，个人需要做的是往前走一小步而不是一大步，因为一大步往往预示着更多的精力投入但是运营很可能不认可最后成为无用功。 3.另外老师追问一些问题，数据质量监控的实现是否大部分依赖于sql查询？源头采集有哪些技术可以应用于监控上？同时埋点这里有个头痛的问题，就是大部分数据是准确的，但是某个版本一两个埋点的控件出现问题（可能是传入的参数不对，也可能是修改没了），这种情况我该怎么做到监控发现（原因在于每个埋点的控件含义是不同的），比如页面id传输和页面的控件id都是准确的，但是某个点击埋点的点击控件参数有问题？