广告服务器的基础架构方案(第 3 部分)

本文介绍了在构建广告投放平台时可以使用的 Google Cloud 的功能和产品。

本文属于以下文章系列:

如需了解本系列中使用的广告技术术语,请参阅概览。

广告投放是将众多广告主之一的广告(通常是最相关的广告)通过发布商的媒体资源展示给客户的过程。该媒体资源可以是网站、应用或游戏。

广告服务器的复杂性取决于它提供的功能。在行业方面,广告服务器是发布商和广告主用于管理广告系列、广告和广告投放人员的工具。相比路边展示静态广告的广告牌,广告服务器起到的作用要更大。展示广告是广告服务器的核心功能,但广告技术平台(如 Google Ad Manager)具有更多功能,并且比向客户展示独特广告提供了更多优势。

本文介绍如何构建一个包含以下主要功能的强大广告投放平台:

  • 管理广告系列、帐号、帐单和报告。
  • 选择最相关的广告。
  • 向目标用户展示广告。
  • 管理展示次数、点击次数或转化次数等事件。
  • 将相关操作发布到分析数据存储区。

通常,广告服务器每秒需处理数万个广告请求,每个响应在几毫秒内发送。能够如此快速地响应如此多的请求意味着可用性、可扩缩性和低延迟时间都是广告投放解决方案的关键要求。由于没有一种服务器解决方案能够满足所有这些要求,因此本文着眼于设计分布式系统的意义。

有两种不同类型的广告服务器:

  • 卖方:这些服务器通过直接从广告服务器的界面管理广告主,使发布商能够最大限度地提高广告收入。卖方服务器通常托管广告,但也可以托管广告的引用。一些广告服务器也将为买家提供自助服务的界面。
  • 买方:这些服务器使广告主、营销部门或广告代理能够管理其广告更新。这些平台用户不是向发布商提供实际广告,而是提供一段代码片段,与买方广告服务器通信以检索广告。

下图描绘了一种可能的广告服务器系统的架构。

可能实现的广告服务器系统

广告服务器平台的主要入口点由 Cloud Load Balancing 提供:

  • 请求广告。
  • 提取广告素材。广告是从最近的 Cloud CDN 缓存中提取的。
  • 跟踪展示次数或(唯一)用户的操作/点击次数等事件。

通过 HTTP(S) 负载平衡日志记录和监控或在收集器上运行的自定义代码记录对负载平衡器的请求,并在 Dataflow 处理之前发布到 Pub/Sub 以进行分析和用户分析。

为请求提供服务的工作器利用:

  • 预算信息。
  • (唯一)用户个人资料。
  • 广告系列的详细信息。
  • 计数器。
  • 可选的经过训练的模型。

以上部分内容需要根据您的具体要求进行调整:

  • 您可能不希望为广告选择使用多个不同的数据库,为简单起见,您可能愿意使用层次结构型数据库或关系型数据库。在这种情况下,您可以使用 Cloud BigtableCloud Spanner
  • 处理出价请求时,您可能需要亚毫秒的读取延迟时间,并且能够接受额外的操作开销。在这种情况下,您可以在需要时使用具有本地复制功能的第三方区域内存数据库。
  • 您可能希望使用可在抢占式虚拟机上设置的事件收集器来最大限度地降低费用。如果您不需要进行任何在线处理,则可以使用 Cloud Logging 捕获事件并使用 BigQuery 进行分析。

管理广告系列

要管理广告系列,广告主需要一个至少包含网络前端以及用户界面 (UI) 的用户前端。广告主还需要提供一些报告功能。如需了解推荐的方案,请参阅用户前端(在第 1 部分中)。

通过此用户界面设置的共享资源层次结构包括广告主、广告系列、预算、广告素材和帐单。创建此层次结构时,系统会记录一组规则,这些规则构成广告选择决策过程的一部分。此数据存储在元数据管理存储中(在第 1 部分中)。

大多数广告服务器每天都需处理数十亿的广告请求。因此,不建议直接在存储应用于这些广告主规则的元数据的数据库上加载此负载(除非您决定使用 Cloud Spanner)。相反,请考虑选择读取密集型存储模式所涵盖的方案之一(在第 1 部分中)。

选择最相关的广告

接收和解析广告请求

请求通过放置在发布商媒体资源上的广告代码进行发送。广告代码如下所示:

<script src="[URL_TO_YOUR_AD_SERVER]?key=value"></script>

加载代码后,它会触发广告服务器的广告请求。该请求包含 HTTP 标头、用户代理、页面上下文、IP 地址、定位信息(可能是用户标识符)和广告详细信息(包括其大小)等信息。

广告服务器必须提供 HTTP 端点 [URL_TO_YOUR_AD_SERVER] 才能接收和处理这些请求。处理请求中详细介绍了推荐的方案(在第 1 部分中)。

分析用户

不同的广告服务器有不同的广告选择方式。此逻辑不在本文的讨论范围内。但是,应当了解用户是展示相关广告的关键。此解决方案假定需要高级用户分类。

与许多发布商合作的广告服务器可能会识别不同媒体资源中的同一用户。(唯一)用户标识符可以是用户能够替换的网页 cookie 或移动设备 ID。

广告服务器可以利用该用户标识符来丰富由广告请求(IP,页面信息)提供的信息以搜索数据存储。广告服务器必须能够在数 TB 的数据中搜索数百万行的用户 ID。广告服务器必须以毫秒为单位返回答案,并且还必须最小化管理开销。

(唯一)用户个人资料存储(在第 1 部分中)提供了概览。虽然您可以使用该文章中提到的任何方案,但我们建议您使用 Cloud Bigtable 进行广告投放,因为它:

  • 是一个可以存储数 PB 数据的宽列 NoSQL 数据库。
  • 以一位数毫秒级速度检索行。
  • 支持区域复制。
  • 完全托管。

选择广告系列和广告

广告选择过程分几步执行,如广告选择(在第 1 部分中)中所述:

  1. 使用(唯一)用户个人资料存储(在第 1 部分中)对用户进行分析。
  2. 使用元数据管理存储数据(在第 1 部分中)的副本选择匹配的广告系列和广告。使用读取密集型存储模式(在第 1 部分中)之一进行复制。
  3. 使用上下文存储(在第 1 部分中)过滤相关的广告系列和广告。
  4. 选择广告。

广告服务器选择与用户细分相匹配的广告系列和广告后,会根据上下文存储数据值对其进行验证,例如频次上限、黑名单或耗尽预算。然后,广告服务器会从剩余的广告系列和广告中选择最佳广告。最终选择的逻辑完全取决于您自己。例如,您可以权衡广告系列,选择具有最高每千次展示费用的广告系列或具有最大剩余预算的广告系列。您还可以计算广告的点击率潜力,或合并混合权重的参数。

一些更高级的选择系统使用机器学习来推荐基于每个用户或每个细分的广告。本文未详细介绍机器学习工作流,但您可以阅读有关构建机器学习功能的更多信息(在第 2 部分中)。

将所选广告投放给目标用户

到目前为止,可以将详细步骤视为属于发布商方广告投放的工作负载。但是,在选择广告后,广告服务器会返回一个链接或一段 HTML 代码,这些代码可以指向:

  • 发布商广告服务器上的位置。
  • 可能属于广告主的外部位置。这样的广告服务器被视为买方广告服务器,并实现第三方广告投放 (3PAS) 的模型。通过此位置,广告主可以更新广告,而无需与发布商的广告服务器联系或通信。此位置还使他们能够管理自己的跟踪。

无论营销者喜欢自己托管广告素材还是将其托管在发布商的广告服务器上,广告投放的流程都保持不变。

存储广告素材

广告素材是视频或图片等媒体文件。存储这些项目需要具有可扩缩和高可用性的对象存储。

Cloud Storage 是推荐的存储。它可以承载数 PB 级的原始或非结构化数据。它还提供备份和归档选项。仅需使用 Cloud Storage,您便可以管理广告素材的生命周期,将其从热存储移至冷存储,以降低 NearlineColdlineArchive 的费用。

投放广告素材

尽管 Cloud Storage 等对象存储是全球可用的,但由于距离的原因,它往往会增加网络延迟时间。此外,对象存储可能比通过内容分发网络 (CDN) 投放广告更昂贵。

由于广告像素和广告素材通常是公开内容,因此您可以使用两种 GCP 解决方案之一来缓存 Cloud Storage 中的内容:

  • 公开对象:通过缓存控制,Cloud Storage 可以使用现有的 Google 基础架构来缓存内容,但具有有限的类似 CDN 的功能,无法强制广告素材在全球范围内下架。

  • 配对 Cloud Load Balancing 和 Cloud Storage:Cloud Storage 上托管的内容可以通过启用了 Cloud CDN 的 Cloud Load Balancing 进行处理。与 Cloud Storage 出站流量相比,Cloud CDN 提供折扣网络价格,并提供签名网址支持缓存密钥失效

    下图演示了第二种解决方案。

    配对 Cloud Load Balancing 和 Cloud Storage

如需了解与其他提供商进行的性能比较,请参阅这些第三方 Cedexis 报告

管理广告事件

不同类型的事件对系统都是有用的,如以下示例所示:

  1. 广告请求:在收到来自烹饪网站的 user_ABC 广告请求后,系统可以通过添加诸如烹饪 > 印度菜或其他反映用户兴趣的信息来改进 user_ABC 细分。
  2. 广告展示:在 CPM 模型中,会向目标用户展示广告。系统会记录展示次数,以便更新剩余预算。
  3. 广告点击:用户点击广告。此操作可能会影响广告优化结果,尤其是多个(唯一)用户在一段时间内点击同一广告时。
  4. 转化:用户点击广告并对广告主的媒体资源执行预期操作,例如购买商品或注册。

处理事件时,在流程的每个步骤中,找到一个适当的价格、数据新鲜度和操作开销的平衡点非常重要,尤其是在以下情况下:

  • 收集和提取来自展示次数、点击次数、转化次数和广告请求的大量和高转换速度事件。
  • 实时或离线处理事件,以提取值并计算计数器,如预算、上限和点击率。
  • 实时或离线将结果导出到各个存储,以便进行帐单对帐或执行适当的投放操作。

如需了解详情,请参阅事件生命周期(在第 2 部分中)。

我们建议采用以下架构来捕获和处理实时事件:

用于捕获和处理实时事件的架构

有了这个架构:

  • 展示次数和点击次数会将对 HTTP 端点的请求发送到托管在 Cloud Storage 上的静态代码或托管在 Google Kubernetes Engine (GKE) 上的网络服务器收集器。
  • 通过负载平衡器 HTTP 日志记录请求事件,或者将收集器捕获的事件发布到 Pub/Sub
  • Dataflow 订阅 Pub/Sub 主题并处理事件。
  • 然后,Dataflow 将原始和/或已处理事件导出到 BigQuery 以进行分析,并将其导出到智能(上下文)数据库以更新剩余预算。

您的要求决定了在 Cloud Storage 还是 GKE 收集器上托管静态代码:

  • 如果必须执行其他后端操作,请使用 GKE。
  • 如果您担心操作开销,请使用 Cloud Storage。
  • 如果您可以偶尔重试请求,但需要降低运行 GKE 或 Compute Engine 收集器的费用,请使用抢占式虚拟机,如计算平台部分(在第 1 部分中)所示。

后续步骤