字节跳动杨震原：抖音电商是如何实现数据驱动的( 二 ) 火山引擎是字节跳动技术中台

这和很多传统的货架电商模式是不一样的。实时需求场景非常多，业务活动的频次又很高。如何在这样不断爆发的需求之下，还能够保证数据支持能够很实时地完成，我们的做法是实时数仓。
实时数仓看起来并不是一个新的概念，很多公司都在做实时数仓，想做出来也并不很难，但是真的去业务里应用实时数仓的时候，遇到的挑战还是非常多的。我举一个例子，比如说数据的一致性问题，今天直播可以很快收到数据实时的分析。但是当过了两三天之后，当你去看一些统计数据，发现前后不一致怎么办？这就是很大的问题。
再比如在非常快的需求迭代过程中，整个链路的全流程管理是不是能做好。数据的发布，是不是有合适的工具，测试是不是有合适的工具，以及数据监控是不是能够到位？实时数据一旦出问题，它修复的代价是很大的。它不像离线的数据，大不了重跑一遍就可以了。
所以从整个流程来看，做好实时还是很有挑战的。我们的数据产品经过了很多业务、很长时间的迭代，实时数仓已经做得比较完善了。对抖音电商来说，我们现在已经能够提供比较全套的实时数据。

文章图片
实时大屏，可以给运营人员、主播实时反馈各项核心指标；实时分析，是指如果现有的实时指标不够，可以在实时分析的平台临时性地做一些分析查询，比如说你突然想分析某一个目标人群，或者你想做一个临时的漏斗分析等等，这里提供了非常灵活的SQL的查询，并且对实时数据流做处理；实时预警可以配置各种规则，当业务情况发生变化，比如当前的流量突然下滑，它就可以提供报警的功能，或者配置自动触发一些操作；实时营销也给运营人员提供了工具，比如运营发现“创单到成功购买”的转化低，可以分析出未成功购买的人群是不是对价格敏感，或者是其他因素影响，从而制定一些对应的营销策略，让业务有更好的转化。
文章图片
大促频率高、新玩法多，如何敏捷支持各项业务诉求？第二大挑战是敏捷的需求。如今电商大促的频率很高，电商这个业务又有个特点，新玩法多。要做好敏捷支持，有很多技术的方法。我今天想给大家分享一个组织模式，就是数据BP 。数据BP实际上是一种分工的方法。我们有做公共产品的团队，叫做数据平台，就是去做一些通用的功能，做通用的数据产品，能够在基础上提供支持。数据BP则是嵌入到每一个业务里面去的，比如说抖音电商就有一个数据BP团队，他们完全和抖音电商的业务目标去对齐，为抖音电商的目标而努力。同时他们也对数据平台内部非常了解，能够充分地利用数据平台的产品。同时，抖音电商的数据BP还会把业务需求引入到数据平台，帮助数据平台成长，这个机制我们认为是成功有效的。我们总结了几个数字说明数据BP的服务标准，叫0987 。
文章图片
0是做到零数据事故。这看起来是一个很基本的要求，但是在业务复杂多变的情况下，实现零数据事故并不容易，它对技术的能力、对运维、对治理都提出了很高的要求。第二个数字是9 ，指的是90%的需求满足。从这个数字中，大家也可以看到数据BP是一个服务型团队，它要能把业务的需求转化出来，满足好。这要求团队对业务很熟悉，能够和产品、和业务的人员有深入的互动，能够一起讨论需求，去帮助业务修改甚至提出需求，这样才能真正实现90%的需求满足。第三个数字是8 ，指的是80%的分析，要能够通过主题表、中间表的方式来覆盖，这对中间数据的建设提出了一个很高的要求。 80%这个尺度我们自己衡量了很久，认为是一个合适的值。当这个数字很大，比如说希望所有数据都能够通过中间表覆盖，其实是不必要的，因为可能过度抽象很多中间数据，也许需求刚刚提完，中间数据表刚建设完，业务就变了。但这个数字太低的时候，也就意味着有大量的分析是直接基于原始数据来做的，这就会带来很多问题，比如一些指标相似而不相同，口径不一致，一些分析跑得很慢等等。从大量业务实践来看， 80%的分析覆盖是一个相对合理的目标。最后这个7 ，指的是70%的NPS ，这在行业里是一个很高的标准，代表业务满意度的一个评价。我们要能够通过这个指标，去发现数据服务环节中的各个问题，来提高业务的满意度。数据BP的机制在字节内部是很有效的。我举一个例子，不久前抖音电商的618大促活动，业务提了很多玩法需求，都需要定制的数据支持。这里面有10个需求在5月17日才完成数据详评，上线开发时间非常紧急。但因为有之前沉淀的模型，数据BP判断可以复用4个，部分可复用3个， 10个工作日内就做了100%的交付，并沉淀新的玩法模型，可以应用到下次的大促中。我觉得如果没有数据BP的组织模式，想支持好这样紧迫的活动是很难做到的。