[大数据]数据驱动增长-字节A/B实验（四）

作者介绍

@张锦波

字节跳动解决方案总监

之前的三期，张锦波老师已经给我们带来关于火山引擎的精彩分享，本期重点讲述分享中的QA问答环节的内容。

QA

主持人：那么有问题的小伙伴可以在屏幕区打下你的问题，然后我们挑选三个问题进行“ QA 环节”的问题解答。在锦波老师讲座的过程中，我这边从后台已经收到一些问题，就先选中其中的几个问题，有请老师作解答。

问题1：目前的火山引擎对外(尤其是数据中台和智能套件)有什么业务?

张老师：火山引擎是字节跳动旗下的 ToB 品牌，它包含了从上层应用的 SaaS，中间层的 PaaS ，以及基础层的Laas 。综合来说，火山引擎是具备核心能力的对外输出和提供服务的平台。

先从 SaaS 层面来说，我们提供了就像讲座中提到的涉及营销管理的组合功能模块。包括我们的自动化营销的平台、关于测试实验的 AB 测试实验平台，以及用户行为分析、埋点治理的相关功能而形成的平台。还包含有，涉及全域的单个用户洞察旅程的相关的体系。

不仅如此，我们还提供了内容相关的服务，也会包含在我们的平台当中来提高用户的使用体验。关于这部分内容，如果展开来说，就比如是我们提供内容的定制服务、内容的管理、内容的分发和推送。甚至还有一些很有趣的玩法，与之相关的，比如，我们有一些 H5 或者是视频建站相关的一些工具和平台，还有包括基于 AI 算法的互动小工具，以及现在属于比较火热的，像虚拟形象的数字人 AR/VR 的一些相关的技术。同时，以及近期被大家所熟知的“元宇宙”，我们最近也收购了与“元宇宙”相关的技术，准备往这个方向输出相关的服务能力，给大家提供一些产品化方案化的能力。

那在中间的 pass 层。不知道大家是否了解字节跳动，这家公司的内部一直强调和秉承着一个小的业务前台，大的中台这样一个理念。所以，当我们面前对外输出时，我们会把自己内部沉淀多年的数据中台、 AI 的中台和研发技术的中台，将他们进行一定程度的封装之后，实现比较的效果以后，用来服务和影响我们的终端客户。

比如，我们也提供了AI-lab中台能力，包含音视频的，直播云的数据中台、研发技术的中台、算法的中台等等。在底层，包括我们的存储计算网络以及我们基于流量的像短信服务的一套的能力附着在火山引擎当中，实现了火山引擎完备的端到端的一站式的解决方案。不仅如此，在这过程当中，也为我们的用户提供更上层的基于行业、基于主题，或者是某些场景，提供方案和指导。

主持人：好的，还有一个同学问的可能稍微偏细节一点，看锦波老师这边能否回答一下，他问的是“流量是如何切分的，是选取某一天的百分之十？还是选取用户七天或者14天的进组数据？”

问题2：流量是如何切分的，是选取某一天的百分之十？还是选取用户七天或者14天的进组数据？

张老师：是这样的，关于测试实验用户流量的切分。建议是所切分中的流量能够尽可能多的覆盖整个用户场景。我们基本不建议说都是开 7 天甚至 14 天或者是更长时间以上。因为用户在他一天一周的这样一个时间周期内，往往他的行为模式是不同的，所以要收集全。

如此得到的数据，其实是一个累积进组的状态，在这样的场景下，我们对于流量的切分其实是有一个底层，遵循科学的随机分组的一个分流系统。在实验开始的时候，我们就会开启相关的配置。比如，实验中是配置 10% 或者是 20% 的流量，也可以选择其它的比例来做小流量的测试。那么我们也会选择满足整个全域流量的百分比用户数，比如，第一天新到的这个用户；比如，布控了我们自己实验代码的那个位置触发规则的相关用户。

一旦进行了实验，实现了曝光，那么这个时候会请求一次分流，我们会根据它本身 ID 信息，来判断具体落在了哪个分流桶里面，以及确定它是不是进入了实验，以及如果进到了实验里，具体是进哪一个实验组。然后，这个时候相应的对它进行实验策略的曝光。那这也是每一天新来的用户，通过这样的方式，我们就可以把它累积下来，然后去进行一个累积迭代的计算。

最开始的时候我们会分天计算，当然方式可能从整个数据科学层面来评价的话，会不是特别的完备，后续话我们更科学地优化了整个底层的统计策略，然后是按照累积的这种方式去计算每一天新进组的用户，和这些用户本身带过来的指标上的一些显著性的变化。

主持人：好的，还有一个用户比较有意思，他在问：“比如说在用户规模 DAU 为5000的情况下，AB测试实验是否还能体现出价值？”

问题3：比如说在用户规模 DAU 为5000的情况下，AB测试实验是否还能体现出价值？

张老师：其实，我们在最开始的时候也是遇到 DAU 非常少的情况，但是也是可以开启相关的一些实验的。但是说到底，确实，我们还是需要在大流量的情况下，才能更好够保证我们的抽样误差能够尽可能的更小一些。

如果在流量比较小，或者说样本比较少的情况下，有些实验的进行就会有出现一些问题。所以，我们会根据一些底层的统计策略，比如降方差等，然后同时也会有一些自动流量调优的方式，去持续和去探索我们最优化的一些策略，也会通过产品化的或底层统计策略的方式去帮助我们来处理这最开始的时候，在产品能启动的这个阶段，在 DAU 没那么高的情况下，能够尽快的拿到一些数据，这是都可以做到的。底层是有非常多统计算法、统计策略上的一些优化迭代和产品上在 AI 控流这个算法模型上的一些优化。

主持人：观众们比较热情，我最后再挑一个问题，也可能有一些 B 端的企业比较关心，这个问题是 “B 端企业的数据是否可以与火山引擎集成？如果集成都有哪些集成方式？”

问题4：B 端企业的数据是否可以与火山引擎集成？如果集成都有哪些集成方式？

张老师：在火山引擎的平台内关于企业的数据接入，平台上是已经提供了非常多的工具，支持平台接入各式各样的场景。比如。通过私有化部署等。我们的客户也是有不少来自这样的场景，希望通过平台来实现数据经营的闭环，通过套件实现量化分析，这其中用到的都是企业用户自己的数据。

比如说，通过企业用户的 SDK 埋点，采集到企业自有 App 上的数据，或者在自己的私域触点上采集到榜上的数据，在进行对应的数据加工、处理和治理之后形成数据产品的输出，比如用于经营分析的看板或者是报表。也就是说，我们保证了即使是在 SAAS 上的多租户的模式，各个不同的企业之间他们的数据的一个安全性和隔离性。那么我们同时也提供了这种 ocram 类似的私有化部署的方式，完全能够在我们整个用户自有的数据中心里面去做数据的流转，达到自主可控。

我是否可以这样理解这位提问的线上小伙伴的这个问题，其实他想问的是不是可以和自己的一些业务功能数据去做一些融合和打通，现在毕竟是“断直连”了，就有一些这种强监管的一些措施的出台。这确确实实是我们现在都需要认真考虑和面对的问题，我们也会通过向隐私计算或者联邦学习等方式去进行一些探索，会有这样的一些工具或者是能力在持续不断的输出和共创。

主持人：好的，由于时间的关系，我们QA环节就到这就结束了。然后大家如果还有问题，可以通过我们的的交流群继续进行交流。感谢张锦波老师的分享。

想了解更多数据知识也欢迎看，7 位大厂产品联合写的《大数据实践之路：数据中台+数据分析+产品应用》这本书。