字节跳动杨震原：抖音电商是如何实现数据驱动的？
7月20日，火山引擎原动力大会在京举办。会上，火山引擎发布了全新Slogan“云上增长新动力”。并推出了以云为底座的一系列产品解决方案。
简单介绍一下抖音电商，大概是在2020年的6月份成立的。大家可以看到，我们数据产品对抖音电商支持的一些重要节点，还有电商业务给数据产品的NPS（净推荐值）打分情况。2020年11月，数据产品已经能够支持抖音电商里面的核心业务，获得了一个比较好的NPS反馈， 到今天NPS值应该已经达到70%左右了，这中间我们也做了各种各样的工作，很多的改进，也可以说是跟着抖音电商一路成长过来。
生意转化以秒计算，
如何提供高效实时反馈
支持一项全新的业务，数据产品会面临各种各样的挑战。第一大挑战是，实时。
抖音电商转化路径很短，转化时间常常以分甚至以秒来计算。大家可以想象，在直播卖货的过程中，不管是主播还是运营，他们对数据实时性的要求是非常高的。今天主播讲一件商品，可能在接下来的5秒钟，就有几万单甚至几十万单的订单产生，所以需要有非常实时的数据反馈，能够让主播、让运营人员更快更准确地做选品调整，或者及时制定一些营销策略，这样才能够让业务更好地发展。
这和很多传统的货架电商模式是不一样的。实时需求场景非常多，业务活动的频次又很高。如何在这样不断爆发的需求之下，还能够保证数据支持能够很实时地完成，我们的做法是实时数仓。
实时数仓看起来并不是一个新的概念，很多公司都在做实时数仓，想做出来也并不很难，但是真的去业务里应用实时数仓的时候，遇到的挑战还是非常多的。我举一个例子，比如说数据的一致性问题，今天直播可以很快收到数据实时的分析。但是当过了两三天之后，当你去看一些统计数据，发现前后不一致怎么办？这就是很大的问题。
再比如在非常快的需求迭代过程中，整个链路的全流程管理是不是能做好。数据的发布，是不是有合适的工具，测试是不是有合适的工具，以及数据监控是不是能够到位？实时数据一旦出问题，它修复的代价是很大的。它不像离线的数据，大不了重跑一遍就可以了。
所以从整个流程来看，做好实时还是很有挑战的。我们的数据产品经过了很多业务、很长时间的迭代，实时数仓已经做得比较完善了。对抖音电商来说，我们现在已经能够提供比较全套的实时数据。
实时大屏，可以给运营人员、主播实时反馈各项核心指标；实时分析，是指如果现有的实时指标不够，可以在实时分析的平台临时性地做一些分析查询，比如说你突然想分析某一个目标人群，或者你想做一个临时的漏斗分析等等，这里提供了非常灵活的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的组织模式，想支持好这样紧迫的活动是很难做到的。
如何在满足实时、
敏捷的同时确保稳定
电商业务与钱相关，数据一定要算对，容错率极低。同时，业务运营重度依赖数据，每天都需要根据数据来做决策，数据必须准时产出。这就带来了第三大挑战，就是稳定。
要想稳，实际上有一些基础的工作，比如监控、运维质量等。我这里想讲的一点是数据治理，在实时、敏捷的同时保证稳定，治理是一个特别重要的问题。因为如果不做好数据治理这件事，业务的复杂度，其中冗余的问题以及一些混乱的因素，是没有办法通过监控和运维机制就能解决的。
我们提到几个做法，一个叫分布式治理，一个叫经验复用，一个叫经验沉淀到工具（DataLeap）。
为什么提分布式治理呢？我们早期实际上并不是分布式治理，而是专职团队治理，就负责数据治理工作。但是当我们作为数据团队去支持众多业务的时候，这个模式就难以为继了，我不可能让一个专门的治理团队去治理各个业务。
所以我们提出了分布式治理，就是要有治理委员会去制定各种标准，这些标准也都是从业务上传，在每个业务中也会有专人负责治理工作，让治理工作自下而上产生出来。
经验复用，就是我们在一个成熟产品积累了很多经验，当我们再去支持一个新的产品，能够快速地把成熟产品的经验借鉴起来，不要再走一遍先污染后治理的老路。除了经验复用之外，还要把经验沉淀在工具中去，这才是能进一步扩大杠杆的方法。
DataLeap数据产品提供了一整套的数据治理工具。这源于在长期以来的数据处理中，我们会把一些通用的能力沉淀到工具中，当新业务直接使用这些工具时，就不会在初期挖很多坑，可以直接达到一个比较高的数据治理水准。
让数据驱动成为习惯
刚才聊了抖音电商在数据驱动实践过程中的三个挑战。接下来我再简单介绍一下业务不同角色如何做好数据化的运营和决策。
数据产品绝对不是只给管理者用的，它要能够给公司各个角色各个层级的人去用，帮助每个人都能够有更好的决策。但是不同的角色需要有不同的数据产品，这样才能够提高效率，更有针对性。
比如说对管理层，我们提供了管理驾驶舱，管理者能够直接看到一些宏观的指标，看到一些趋势的变化，辅助管理者做出更及时有效的决策。对于一线Leader，对运营和风控等一线人员，他们可能需要看业务数据，比如罗盘，同时他们也可能需要BI（敏捷分析平台），可能需要人群画像、行为分析等等能够指导一线工作的工具。因此我们针对不同的业务角色，也会去专门地定制不同的产品来满足各个角色的需要。
在字节跳动内部，每月有超过10万员工直接使用BI产品，可以说数据驱动已经成为大家日常工作的一种习惯，深入人心。
这是字节跳动整个数据产品体系的架构图，上面是各种业务，我们通过数据BP的机制支持不同业务。然后是一些是数据应用产品，直接给公司的不同角色使用。底下有一些偏基础的产品，比如说数据建设、数据引擎等，能够支持我们上层的应用。这样一套体系，既能够支持不同业务个性化的需求，也能够经验复用，把一些底层能力复用。这些能力和工具也都在火山引擎上形成了对应的产品，提供给外部客户使用。
技术与业务互相塑造、共同成长
我一直有一个理念，技术和业务是一个互构的关系，互相折腾，制造麻烦，共同成长。就像刚才我分享的抖音电商的例子，这个业务在成长过程中对技术部门提出了很多需求，给数据产品造成了很多“麻烦”。正是因为这些“麻烦”，数据产品才能更好地改进。反过来说，优秀的数据产品也让抖音电商的效率提高。技术和业务互构，互相塑造、共同成长。
以上就是我的分享。字节跳动技术中台支持公司业务的这些经验、这些技术能力，都已经沉淀到了火山引擎上。我希望火山引擎也能够帮助我们的客户提升业务价值，获得新的增长动力。谢谢大家。
欢迎点击阅读原文或扫描下方二维码，获取大会相关资料。更多阅读
◆ 2022火山引擎FORCE原动力大会即将开启，企业CXO有话说