【AI技术生态论】FreeWheel孙大伟：AI如何改变视频广告的商业模式？

记者 | Just
出品 | AI科技大本营（公众号ID：rgznai100）

「AI技术生态论」是CSDN发起的“百万人学AI”倡议下的重要组成部分，与AIProCon万人开发者大会、Top30 AI技术生态行业案例征集和评选、开发者与AI大调查、AI大师课一起，打造一个覆盖百万开发者的AI生态联盟。


2020年，「AI技术生态论」栏目将对1000+AI生态大咖进行系列访谈，勾勒出AI生态最具影响力人物图谱和AI产业全景图！


本文为 「AI技术生态论」系列访谈的第九期，更多AI技术和产业生态报道，敬请期待下一期精彩内容！

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

对于坐落在大洋彼岸的这座北京研发中心而言，它的诞生完全是因为 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）观察系统健康状态。一旦监控系统有一些警报，我们可能考虑服务降级。本身在广告投放中我们对性能会有问题，或者稳定性上有风险的模块会提供运行时的降级接口，再结合自动化的工具，很快、很方便地做到运行时的一键降级，这是对广告服务器高并发的一些处理方式。

实时监控平台

AI科技大本营：数据平台在技术系统中承担了怎样的角色？

张磊：日志信息是通过队列过来的，整个数据平台很大一部分工作是接收日志并进行处理。我们对客户提供实时产品，客户可以得知他们的广告投放情况。另外，通过我们的平台提供实时的系统级别或者业务级别的监控，能够知道系统内部的状态。此外还提供一些非实时的，但是有时间限制的离线数据产品。

像超级碗这种比赛，由于我们之前没有足够的数据或者足够的经验，所以我们的客户 NBC 两场比赛带来的流量，没有办法用之前比赛的流量去测试和验证，只能根据根据离线压力的测试，预估应对超级碗这种大流量的挑战。

对于数据平台来说，比如有效性队列，Hadoop 平台系统，还有上面跑的各种各样的任务以及实时的流式处理的东西，所以之前我们会做水平扩容和垂直扩容，这是必须的。另外一点，我们有一套非常完备的应对方案，我们现在有六个数据中心，系统一直在 AWS 上面，数据要同步，如果遇到网络拥堵的情况，在 AWS 的集群上，所以我们会牺牲一部分纽约的带宽保证服务。

AI科技大本营：实时监控平台对技术系统的重要性体现在哪些方面？

陆琴：最近一年我们在监控上有很大的进展，因为线上大型直播赛事的驱动，我们需要在直播赛事中更好的了解广告服务器在线上的运行情况。同时从客户业务的级别看，对于不同的客户，不同的集成，涉及到不同的平台和不同的屏幕，所以我们要了解客户不同平台集成的健康状况。

我们主要是从两个方面加强线上监控。一方面是从应用的角度加强监控。应用的监控之前已经有了，但是还是存在一些响应数据不够及时，维护成本比较高的问题，所以我们在去年一年重新梳理了广告服务器线上应用的监控，总体而言做应用监控是从广告服务器本身和所依赖的应用服务之间去加强的。

另外我们采用了新的监控模型，更快的采集线上业务数据，并采取全新的数据存储方式，使应用的数据采集完之后可以很快、很方便的展现在 UI 上，同时加强监控系统的设计，从数据采集、收集到警报触发都做了全方面提升。应用监控方面相当于重新设计了一套全新的系统，从整个监控方面进行了全方位提升。

牛励诚：关于应用监控，我们做了一套全新的监控系统，特点是非常灵活，每个模块都可以通过插件的方式插入。比如数据采集支持各种各样的代理，通过统一的接口输入进去就可以了。比如监控数据的存储也是可插入的，现在是基于 InfluxDB 这样一个 Time Series 时序数据库的方式做存储，但是未来对不同的数据类型会采用不同的数据存储的方式。比如 UI 展示，我们的控制面板也是可插入的，我们也开发了一套自研的定制化的监控方式，所有的组件可以通过一定的接口很方便地插入系统架构，这对未来的扩展性来说也比较方便。

孙大伟：不光是广告服务器，在 FreeWheel 里各种应用、不同模块服务量非常大，我们不光建立这样一套监控平台，更重要的是怎么使用监控平台，包括怎么从流程上保证在这个平台里暴露出来的异常事件可以被及时捕捉和处理。现在这个平台也在跟内部的 OPSGenie Noc 系统进行集成，当事件发生之后按照一定的规则定义紧急程度，然后我们通过类似于打电话、发短信等等方式通知到相应人员。

如果这个人没有及时响应，还有往上报警升级的一系列机制，在这个监控平台的基础上，整个 FreeWheel 的应急处理能力比之前提高了很多，尤其对于大型赛事的直播起到非常大的作用。

陆琴：除了应用方面的监控，我们在今年的直播赛事中还有一个比较大的改动是基于业务数据实时的监控。由于我们之前没有数据平台支持，只能从广告服务器端看这个广告服务器响应是不是正常，吞吐量、性能是不是没有问题，但这次可以定位到不同的客户和不同的平台，观测他们业务数据的变化。

在超级碗和冬奥会的直播过程中，我们基于业务监控平台发现了客户的问题，或者是客户的客户的问题。比如在超级碗的过程中发现我们的客户使用的第三方 CDN 服务商，在下半场的时候， CDN 服务器出现比较大的性能延迟，导致客户从我们平台上收到广告响应到播放广告（Call Back）之间有大概有 20 秒到 50 秒的延迟。从用户感受上来看就是会“黑屏”一段时间，这是从监控平台上发现的。

张磊：我们数据平台会为监控平台搭建一个实时的东西，也会从六个数据中心收集出来原始的记录（log），我们是用 Spark Streaming 做这个事情。这个东西如果你单看，比如做一个监控，可能也不是特别困难，但是跟超级碗流量混合在一起，本来只需要处理一种的，但现在整个容量需要完全预估出来。

另一方面，监控不是一成不变的，我们经常有一些临时需求，怎么让后台处理更灵活地响应这些需求，而不是每次需要重新去改写代码重新发布，这也是对我们的挑战。之前我们预留一些可能用到的指标，接下来我们会让整个系统更加灵活可配置，最终让灵活的新需求基本完全不用数据平台来做。

AI科技大本营：与直播超级碗相比，在支持冬奥会这个场景时对技术要求有什么不同吗？

牛励诚：超级碗最关心的是高并发，因为是 300 万到 500 万的并发压力。冬奥会并发压力没有超级碗这么大，尽管系统的并发量是百万级别，但冬奥会不像超级碗是一场比赛，而是多场比赛同时进行，虽然用户有这么多，但对整个系统请求时间是平均分布的。

冬奥会的特点是集成方式特别复杂，大概有十几种平台的集成，这对监控提出了一些挑战，一方面怎么同时满足这十几种集成，怎么在比赛过程中实时监控十几种数据平台的数据。

另一方面在监控过程中分很多监控，比如应用级的监控，适用于 Time Series 我们是用 InfluxDB 的方式监控，对于业务的监控是基于数据平台。还有对于系统的 Debug 信息的监控，我们会通过 Kafka 的方式把它输入到我们的 ELK 系统，然后用 ELK 再做一些监控。

还有一个挑战是冬奥会是将近 20 多天的时间跨度，怎么在 20 多天里 7×24 小时的保证线上状态的运维，这就需要中国团队跟美国团队协作做技术支持。

AI 赋能互联网视频广告

AI科技大本营：互联网视频广告也是人工智能技术应用的一个场景，在这些新技术的结合上你们做了哪些尝试？

孙大伟：在 FreeWheel 现在的产品里，人工智能应用场景很多，比如广告计费模式，如果只是基于曝光计费，人工智能在这方面的用途不是特别多，但是基于效果的使用场景越来越大。

比如从视频广告里识别出来业务信息，可以大大简化客户流程，如果这个信息不去分析，只能由客户把这个填到数据库里。FreeWheel 现在运营的广告流量来自不同的设备、屏幕甚至协议等等，在有线电视里很重要的概念是广告排期，因为有线电视的协议站跟互联网的不太一样，广告是不能随意实时的插在视频流里，得有视频排期的概念。

如果我们流量端那么多，不同的节目、频道，如果进行人工排期工作量比较大，尤其是小型电视台，可能有几百个电视台，我们怎么能利用机器学习方法进行自动化排期，使得收益自动化，广告本身的目标可以实现等等都是我们在 AI 方向可以考虑的。

对于 FreeWheel 的业务而言，有了 AI 之后，第一是提高预估准确性。尤其是 2B 业务，我们要服务的大客户非常需要提供精准预测帮助他们做计划和定价，还有保量广告，要预估这个广告能不能按期投放。第二是可以最大化我们的收益。我们怎么平衡保量广告和来自于市场的广告，怎么优化投放算法，这都是在最大化收益方面所需要去考虑的。第三，改进流程提高效益。可以改进 FreeWheel 内部流程，也可以提高客户效率。

在广告业务流程中，从开始广告的意向到最后广告订单的确定，中间的追踪到报表这个流程非常复杂，我们希望 AI 降低一些流程带来的成本。

AI科技大本营：今后的技术发展方向或者要解决的难题是怎样的？

孙大伟：首先是弹性的能力。不管是广告服务器还是平台和业务预测等等，弹性能力是每个团队都在考虑的重要方向，尤其是我们广告实时投放的业务，必然带来的问题是在高峰时流量可能是平时的百倍甚至千倍。随着业务扩展，高峰和低谷时的对比更强烈一些，在这个情况下我们怎么水平扩展服务能力？

高峰的时候不仅广告服务器要扩展服务能力，后台数据处理也要有相应的弹性能力，否则数据就有堆积。在我们考虑每一个模块弹性能力的时候，怎么对主要的服务进行弹性的扩展，都是我们需要考虑的一个重要的方向。

我们要达到的目标是使得我们在水平弹性能力不仅在技术上可行，而且要在部署和应用，比如我们大量使用 AWS 提供的弹性伸缩、弹性计算能力，所以当有大流量发生的时候，能够非常自动化的在 AWS 里面设置更多服务器，使得我们可以应对流量上的挑战。

其次是服务化。我们现在广告服务器的粒度比较粗一点，基本上用一个大的进程应对了整个从流量的进入到最后把广告填好退出的工作流程（workflow），这个过程是非常复杂的。而随着新业务的到来，我们不仅要直接应对大客户的流量，我们也要接入 SSP 的流量，也要跟 DSP 打交道，在这个时候不同的流量服务的要求不一样，对于容量的要求也不太一样。

还有工作流程本身非常复杂，在这个过程里有一些是很重要的结点，我们必须要“走”的，但是有些在高压情况下可以放弃的，在这个情况下怎么调整这个架构，使得架构能够应对不同的流量、不同的 SLA、不同的使用场景，怎么让模块之间内聚的更好一些，怎么切分模块都是非常好的话题。我们怎么做服务编排，怎么做部署和监控，都是相对接下来要做的一些事情。

第三是 AI 的使用。特别是随着交易市场产品的推出，以前 FreeWheel 是纯平台，我提供服务你使用服务，FreeWheel 并不直接参与收益的划分，很多收益还是通过 CPM 的方式。但随着交易市场产品的推出，FreeWheel 真正要购买流量，发给相应的需求端投放广告。怎么对流量进行定价，怎么找到收益率更高的 DSP，我们要更多依托于 AI，使得 AI 可以非常智能的帮我们预测出来一些底架的东西包括收益率等等。

ID Graph 也很重要。平台这么多，其中有很多设备，设备之间进行 ID 认证就非常难了，因为流量不止在 FreeWheel 端。比如一个视频网站，用户不管是在 iPhone 里还是 iPad 里安装了应用，可以通过帐号进行关联。

对于 FreeWheel 而言，流量端是非常多样化的，有不同的应用、设备、OTT 和机顶盒等等。这对广告主的用处也非常大，因为他们期望广告能够触及更大的范围，也希望有人群定向。而 FreeWheel 拥有 Comcast 的数据，但我们要把这些数据和基于移动设备的用户打通，才有可能把这些用户数据拓展到更大的用户群体上。

广告主也有很多其他需求，比如有频度控制的要求，也必须在把用户识别出来之后才能有这样的一些能力，这也是今年一个比较重要的方向。

【End】

---

CSDN全新人物专栏重磅上线

PS：今日福利！

同样作为“百万人学AI”的重要组成部分，2020 AIProCon 开发者万人大会将于6月26日通过线上直播形式，让开发者们一站式学习了解当下 AI 的前沿技术研究、核心技术与应用以及企业案例的实践经验，同时还可以在线参加精彩多样的开发者沙龙与编程项目。参与前瞻系列活动、在线直播互动，不仅可以与上万名开发者们一起交流，还有机会赢取直播专属好礼，与技术大咖连麦。

评论区留言入选，可获得价值299元的「2020 AI开发者万人大会」在线直播门票一张。 快来动动手指，写下你想说的话吧

点击链接，观看直播吧！