菜单 搜索

从预估到成本,AI深刻影响了视频广告的商业模式?| 文末福利

媒体资源网 http://www.allchina.cn 2023/6/16

不少互联网外企在过去的十年里把分部开到了中国,它们大多数都是觊觎这里的庞大市场潜力。当然,也有例外。

对于坐落在大洋彼岸的这座北京研发中心而言,它的诞生完全是因为 FreeWheel 奔着这里有丰富的技术人才资源而去的结果。在这里上班的 300 多个人中,除去极少数职能部门员工外,放眼望去基本清一色都是工程师。

根据公开资料,这家成立于 2007 年,总部位于美国硅谷的视频广告公司,主要为大型电视媒体和优质内容供应商提供企业级的视频广告解决方案。它的客户主要在北美以及欧洲,包括 ABC, NBC, ESPN 等美国 90% 以上的主流电视媒体和运营商,单日广告播放量近 10 亿次。当然,这些销售业绩背后的所有重要产品研发工作几乎都归功于北京研发中心。

凭借其在国际市场上的业务需求, FreeWheel 的产品规模在不断扩大,已经从流量端覆盖到需求端,而背后支撑产品运营的大型技术平台,可以接入来自不同内容的设备甚至不同协议,比如支持跨 IP 网络和有线电视网络。他们最终要做的是把基于流量端的技术平台转向全栈平台,甚至自运营流量的方向拓展。

当然,作为互联网视频广告肥沃的掘金地,已扎根中国十年的 FreeWheel 也想在这块东方土地上扩展出自己的商业版图,但这需要得到这一市场的接纳,以现在的情形看,更重要的也许是让行业对他们所做的事情获得更大范围内的认知。

由此,AI科技大本营就 FreeWheel 视频广告的具体业务模式,在直播场景下的技术解决方案,以及人工智能技术在互联网视频广告的应用等问题,与首席架构师孙大伟等四位受访者聊了聊:

孙大伟,FreeWheel 首席架构师,负责预测系统、广告服务器系统的研发工作;

张磊,FreeWheel 架构师,负责数据平台和数据产品的整体技术把控;

陆琴,FreeWheel 高级开发经理,主要负责线上质量与监控;

牛励诚,FreeWheel 首席工程师,目前专注于广告服务器的基础架构以及广告程序化交易平台的搭建。

以下为对话内容实录(有删减):

业务合作流程

AI科技大本营:客户投放广告时与 FreeWheel 的合作是怎么展开的?

孙大伟:分为两部分内容,一部分是鼓励接入流量端。比如 ABC, NBC, ESPN, Comcast 等都拥有非常好的流量,像比较好的体育赛事或者电影,他们会把广告流量导入到我们的系统平台里。在需求端,我们允许客户自营广告,也叫 O&O(Owned & Operated)广告。

我们支持这个模式的原因是面对高端视频内容,广告价值也非常高,天然适合这些品牌类的广告,在这样的市场里,这些顶级流量会通过招标售卖广告。客户把顶级广告拿过来,在我们的平台上按照客户定制化的需求去投放这些广告。

另外一部分是程序化交易市场。在一些情况下,当流量到来之后没有特别适合的广告,我们引入了程序化交易市场的概念。在一些场景下从交易市场拿到的广告,可能对于 FreeWheel 或者对于客户,对于流量端,为了业务价值更大化,我们也会引入程序化广告跟自营广告或品牌广告进行竞争。这样使得我们在整个业务流里实现收益最大化,这是我们现在广告交易两个主要的方向。

牛励诚:我们早期更多是媒体方的广告服务器,新的 FreeWheel 要做一个新的平台,一方面要服务于所有的供应方,这里的供应方既包括了 ABC 这样的优质媒体客户,也包括非 FreeWheel 的客户。

比如有些客户不一定用 FreeWheel 的平台管理他们的内容和广告,但是我们可以通过程序化的交易方式把第三方流量导入系统,这样的好处是购买方可以通过我们的平台到达更多的观看者,这些观看者并不仅限于我们自己的客户,也可以从上游接入一些互联网广告交易平台或第三方的卖方平台(SSP),从而让平台里的广告购买方获得更多广告投放的机会。

然后是需求方,我们支持用户在我们的系统里自己预购广告订单,联系广告主签订合同,用我们的平台自己管理广告这样的直接售卖方式。此外还有程序化交易方式,对接更多的买方平台(DSP)或者下游的需求,最终目的是让上游的供应方获得更好的流量货币化的方式。

我们的平台是全栈的,基于这个平台未来还可以做一件事,我们可以创建自己的广告市场,相当于我们自己运营的广告市场,可以从不同的供应方购买流量,我们来决定这些流量卖给什么样的需求方。

广告市场的创建相当于有更大的灵活性,我们整个广告平台收费的模式也有变化,因为传统的更多是服务于我们的媒体方帮他们投广告,比如 CPM 收一个固定的比例,但未来收费方式看运营情况,如果把广告以更好的价格卖出去,我们可能抽取更高的提成。

AI科技大本营:广告呈现呈现形式是怎样的?

孙大伟:从用户端来看,跟以前我们基于 CTR 预估比较类似,我们把事件泛化为 X-event,我们内部的优化目标像可视化曝光(Viewable impressions)这些产品在预测系统和广告服务器系统里都在使用,本质是向客户端投放他们可能更感兴趣或者收费率更高的广告。

与搜索广告、直播平台的竞争

AI科技大本营:与传统的搜索广告形式对比,视频广告投放方式在产品设计和技术应用上有什么不同?

孙大伟:我们追求给当前的用户看什么广告,能够使得转化率有更大的提升。与传统的搜索广告相比,第一,在搜索广告里,内容和广告的相关性是被考虑的重点,它把跟终端用户兴趣等相关的广告进行推荐,实现更高转化率。但在视频广告里,我们发现用户跟视频及广告的关联程度,在广告效果贡献上远远高于广告跟视频的关联程度,因为视频观看是一个流式,不太会被打断,换句话说如果视频内容或广告内容足够好,用户一般不太会离开不看。

所以在搜索广告中用的推荐技术、协同过滤在我们这儿用的比较少。我们这里用的更多的是基于逻辑回归、GBDT(Gradient Boosting Decision Tree)这样的技术。

另外,在搜索广告里点击率一般是在10%以下,深度和覆盖率会受到比较大的约束。但在视频里,曝光量发生率是 80% 到 90% 以上,可视化曝光发生概率也非常高,一般在 60% 以上。数字的不一样带来技术上很大的不一样,比如我们的调优目标从5%到10%就是一倍的改动,效果提高一倍,但是我从 60% 提高到 65% 只是十二分之一。

正负样本的平衡也不太一样,比如 50%、60% 正负样本以某种方式是比较平衡的。还有其他一些关键技术点,比如视频流量远远小于搜索广告流量,有时是基于规模的限制等等,有时在搜索广告里做不了的事情反而在视频里能做。但通用的技术还是比较统一的,只是细节点不太一样。

AI科技大本营:如果我们要开拓国内市场,业务上最直接的竞争对手应该是一些视频和直播平台。

牛励诚:在视频或者直播广告领域,基本上是业务上的区别。对不同业务的支持导致技术上不同的挑战,我觉得可以从几个点说一下,一个是 FreeWheel 的客户分布在全球各地,使得我们在全球各地部署多个数据中心来支持不同地域的业务。多个数据中心带来的问题是在运维上的复杂度,包括数据中心、数据同步如何做很好的支持,这是因为多个数据中心带来的挑战。

还有 FreeWheel 的客户,我们接入的流量很复杂,我们要面临各种各样的终端流量,比如来自于台式机、移动设备和这两年比较火的 OTT 设备,甚至来自于有线电视。对于不同终端的集成方式也不一样,比如有线电视广告投放系统和数字投放系统是两个完全不一样的系统,特别针对直播这种情况,最近几年常用的视频直播技术都是基于流媒体的直播技术。

还有需求方,除了用户直接售卖自己广告的方式,我们还支持程序化的购买,程序化实时的向 DSP 发送 Real-time Bidding 收集需求方的广告。因为我们的广告后台不仅仅是一个媒体方的广告服务器,也包含 SSP,避免不了的是一方面需要更强大的连接管理。

如果把 DSP 程序化交易的广告和客户直接售卖的广告放在一起,我们需要重新设计一套广告的排期算法,从而保证把市场上拿到的DSP广告和用户自己的广告放在一起,做一个合理的竞价排序。

所以针对这个场景我们一是要做第三方 DSP 广告实时转码技术,保证任何一个 DSP 返回的任何一个广告可以通过实时转码转成不同的视频格式,可以在不同终端上播放。

此外,我们的客户是优质内容客户,他们对内容的保护意识非常高,所以我们对第三方广告有广告审核处理,在确认安全的情况下才会投放到客户端内容上。大概这几点是跟国内其他的视频、直播广告投放系统的差别。

技术的高并发与高可用

AI科技大本营:视频广告系统支持直播赛事最重要的技术特点是高并发和实时性,结合相关案例谈谈 FreeWheel 的技术系统是怎么实现这些要求的?

牛励诚:高并发和实时响应这两个是相关的问题,因为当我们抛开数据规模、量级去谈系统性能其实没有意义。

FreeWheel 对每个广告请求的 SLA 是 300 毫秒,其实内部对广告响应的时间要求要更严格,大多数广告请求在 20 到 30 毫秒之间就要完成响应。对于超级碗我们最大的挑战是系统压力的提升,在超级碗之前,我们的客户 NBC 给我们的并发流量的估计是 500 万并发用户。我们事后统计发现,当时真实并发用户峰值是 300 万。对比历史上 FreeWheel 后端系统遇到最高的并发量是 100 万,技术挑战也是不一样的。所以在超级碗之前我们做了很多事,(考虑)针对全新的并发量级怎么进行扩容和架构调整。

先说一下在广告服务器方面的优化和调整。从扩容角度,我们有考虑垂直扩容和水平扩容。垂直扩容是怎样提高单点性能,除了必要的硬件升级,我们更多精力花费在服务端的优化。关

于 Linux 服务器端的优化,比如非阻塞 IO 的使用,“锁无关”(lock-free)的数据结构,缓存的使用,这些基本原则大家都不陌生,但要注意一点,可能在优化过程中,一个是要结合我们的业务选择合适的优化方式,另外要避免过度优化,我们需要在系统性能和代码的可读性、可维护性中取折中、平衡。

再者是算法优化,我们针对超级碗一些特殊的集成方式有针对性的进行算法优化,比如效果比较显著的优化是我们对整个广告的定向算法做了优化,优化以后整个广告请求的响应时间大概节省了 30% 左右,但算法优化也一样要避免过早、过度优化,这是我们做的垂直优化。

AI科技大本营:那我们又是如何解决垂直扩容问题的?另外当服务器不断扩容之后,对整个系统来说,造成更大的负担,从而引发新的问题?

牛励诚:跟垂直扩容对应的是水平扩容,这是为了增加整个集群的总体吞吐量。水平扩容这一块最简单、直接的,最容易想到的方法是我们增加更多的广告服务器。

对广告服务器的扩容有几个地方需要特别关注。首先,如果我们希望做到一个平滑的、可伸缩的扩容,我们要保证广告服务器是无状态化的服务,需要我们把所有的用户状态保存到进程以外,把日志输出到 Kafka 消息队列下游,再去对消息队列进行流式的处理,做到这一点就满足了做动态平滑扩容的一个前提条件。

在此基础上,我们现在有计划把广告投放服务迁移到 AWS 的云服务器上,这个项目在进行中,我们预计今年 6 月份世界杯的时候,会正式在生产环境中采用基于 AWS 的混合云部署。当然我们增加更多的广告服务器还会带来一些问题。当我们的广告服务器扩容以后,所依赖的服务和外部依赖也需要相应的扩容和架构调整来适应它。

举个例子,我们之前是用 Memcached 做数据库前端的缓存,当我们的系统并发量提升以后,发现 Memcached 的局限性显示出来了,比如它没有一个特别完美的集群方案,现在做的集群方案运营成本非常高,因为 Memcached 没有原生的集群方案,所以这次我们把所有的缓存数据从 Memcached 上面迁移到更加成熟的缓存系统 Aerospike 中,它是原生支持集群方案的,所以集群的扩容对我们的业务和运维是完全透明的状态。

再比如我们的广告计费服务器。今天我们的广告计费服务器设计是中心化的架构,我们所有的广告服务器需要连接中心化的广告计费服务器来同步广告预算的信息。这次我们广告集群扩容大概扩了 1.5 倍,会发现中心节点的广告计费服务器有比较大的性能瓶颈,所以我们短期做了优化,在广告服务器和计费服务器中间加了缓存,从而减少了直接对计费服务器 CPU 产生的压力。长期来看我们会继续做这个方案,可能会采用去中心化计费服务器架构,这样从根本上解决了计费服务器的单点性能问题。

FreeWheel 广告服务器架构是全球多数据中心、异地多活的架构,当我们的服务器变多、压力变大以后,对数据中心之间的同步也有挑战。现在我们会试图提供更好的网络 QoS,比如我们会识别不同应用、数据的优先级,为不同优先级的数据提供不同的带宽优先级,这样可以保证关键数据的实时性,而对不是那么关键的数据可以容忍一定时间的延迟。

我们也担心系统不停的扩容会带来其他的问题,所以现在我们尽量希望减少整个服务器的粒度。今天我们整个广告服务器基本上是比较粗粒度的部署,一个进程里从广告请求到返回广告响应,很多的工作流程。

此外,我们目前也尽量希望把整个服务器架构的粒度更精细化,做一些服务的拆分,这样我们在扩容方面更有灵活性,只要找到有瓶颈的节点,对那个节点做一些扩容就可以了。

AI科技大本营:还有一点是直播过程中的实时响应问题。

牛励诚:一方面我们的客户是优质视频客户,在直播场景下没有犯错的空间,一旦错过一个广告间隙,客户的损失可能是百万美元以上,一旦错过没有机会弥补这个损失,所以这对我们服务的高可用也提出更高的要求。

架构上高可用主要是消除所有的单点问题,我们所有的服务都冗余化,所有的存储是有主备切换、分区容错。我们支持异地多活的部署方案,这都是事前的准备。我们还要针对超级碗这样瞬间突然来的高并发做流量控制预案,通过 DNS 技术灵活的把流量在不同数据中心之间进行分配。

还有一个很重要的是资源隔离预案。FreeWheel 有很多客户,在服务超级碗的同时还有其他客户的流量也在我们的平台上,这样带来一个问题,因为所有的客户是分享同一个广告服务器的集合(Pool)。

我们说的资源隔离是通过负载均衡的技术,有能力在短时间内实时、很快的情况下,把客户的某些流量隔离到单独的硬件资源上,这样一旦某些流量出现问题,我们可以很快的隔离出来,不同用户的流量不会互相干扰。这是我们事前针对高可用做的预案和准备。

事发过程中我们会依赖监控系统、各种标准(Metric)观察系统健康状态。一旦监控系统有一些警报,我们可能考虑服务降级。本身在广告投放中我们对性能会有问题,或者稳定性上有风险的模块会提供运行时的降级接口,再结合自动化的工具,很快、很方便地做到运行时的一键降级,这是对广告服务器高并发的一些处理方式。

————————————————

前方高能!「2020 AI 开发者万人大会」强势来袭!此次大会特邀来自微软、英伟达、亚马逊、华为、腾讯、百度、阿里、华为、字节跳动、美团、快手、蚂蚁金服等100 位技术大咖,分享最新AI技术、产品与行业实施案例、技术实践经验与AI未来发展趋势。

心动不如行动!私信发送“优惠码”,即可获取报名地址 优惠码,你将免费获取299元门票一张!!