为了在一个大规模广告平台中同时支持广告保量（如PDB、合约CPM）和广告竞价（如RTB、oCPC/oCPM），需要一个健壮且灵活的混合系统架构。该架构需要能够高效处理海量广告请求，精准匹配广告与用户，智能分配流量，并确保不同类型广告活动的目标达成。

以下是一个典型的混合广告系统架构的组件化描述：
file

架构组件说明：

  1. 用户端 (Client-Side):

    • 用户APP/网页 (UA): 用户与广告交互的界面。
    • 广告SDK/JS Tag: 嵌入在UA中，负责发起广告请求、接收广告素材、渲染广告、上报曝光/点击等行为数据。

  2. 广告请求接入层 (Request Ingestion Layer):

    • API网关/负载均衡 (GW): 接收来自SDK/Tag的广告请求，进行负载均衡，并将请求分发到后端服务。
    • 请求解析与预处理 (ReqParser): 解析请求参数（如设备信息、用户信息、广告位信息），进行初步校验、格式化，补充服务器端信息（如IP解析的地理位置）。

  3. 核心广告决策引擎 (Core Ad Decision Engine): 这是系统的“大脑”。

    • 流量分配与优先级模块 (TrafficAllocator):
      • 接收标准化请求，首先根据全局规则、AB实验配置、反作弊结果等进行初步过滤。
      • 核心职责是决定当前请求应该优先满足保量广告还是进入竞价流程，或者两者都参与（如动态分配）。
      • 通常保量广告（PDB）优先级高于竞价广告。
    • 保量广告模块 (Guaranteed Delivery Module):
      • 订单管理系统 (GD_OMS): 存储和管理保量广告订单的详细信息（合同、预算、目标量、定向、价格、投放周期等）。
      • 库存预估与预留 (GD_Inventory): 预测未来流量，为保量订单预留库存，避免超卖。
      • 定向匹配 (GD_Targeting): 根据请求信息和订单定向条件，匹配合适的保量订单。
      • 投放节奏控制 (GD_Pacing): 确保保量订单在投放周期内平稳消耗预算并达成目标量。
      • 保量广告选择器 (GD_Selector): 从满足条件的保量订单中选择一个或多个广告进行投放（可能也存在内部排序）。
    • 竞价广告模块 (Auction Bidding Module):
      • 广告检索与召回 (Auction_AdRetrieve): 根据请求信息从广告库中检索出符合定向条件的竞价广告候选集。
      • pCTR/pCVR预估服务 (Auction_Predict): 对候选广告进行点击率、转化率等预估。
      • 智能出价引擎 (Auction_Bidder): 结合广告主出价、预估值、预算、目标成本（oCPC/oCPA）等，为每个候选广告动态计算竞价出价。
      • 竞价服务 (Auction_Auctioneer): 组织竞价，收集所有有效出价（包括来自外部DSP的RTB出价，如果有对接），根据竞价规则（一价、二价、底价）确定胜出者。
      • 广告排序器 (Auction_Ranker): （在平台内部竞价或处理多个内部候选时）综合出价和广告质量分对广告进行排序。
    • 最终广告选择与决策 (AdSelector):
      • 综合保量模块和竞价模块的结果（如果流量同时走了两条路径或有优先级覆盖）。
      • 考虑收益优化（eCPM）、用户体验、广告多样性等因素，做出最终的广告投放决策。

  4. 广告投放与数据反馈层 (Ad Serving & Feedback Layer):

    • 素材获取与拼接 (CreativeFetcher): 根据胜出的广告ID，从素材管理系统获取广告素材，可能需要进行动态创意拼接。
    • 广告投放服务 (AdServer): 将最终的广告内容（素材URL、落地页等）返回给SDK/Tag。
    • 曝光/点击/转化追踪 (ImpTracker, ClkTracker, ConvTracker): 接收并处理SDK/Tag上报的广告行为数据，进行日志记录和初步处理。

  5. 支撑与数据平台 (Supporting Platforms & Data Infrastructure):

    • 用户画像平台 (DMP/User Profile): 存储和管理用户标签、人群包，为定向提供支持。
    • 预算管理系统 (BudgetSys): 实时跟踪广告活动的预算消耗情况，控制超投。
    • 素材管理系统 (CreativeSys): 存储、审核、管理广告素材。
    • 数据报表与分析系统 (ReportSys): 对投放数据进行聚合、分析，生成报表，供广告主和运营人员查看。
    • 反作弊系统 (AntiFraud): 识别和过滤无效流量及作弊行为。
    • 机器学习平台 (MLPlatform): 支持pCTR/pCVR预估模型、智能出价模型、库存预测模型等的训练、评估和部署。
    • 数据湖/数据仓库 (DataLake/DWH): 存储海量原始日志和聚合数据，支持离线分析和模型训练。
    • 实时流处理平台 (StreamProc): (如Flink, Kafka Streams, Spark Streaming) 处理实时的行为数据流，用于实时统计、监控、特征计算和反作弊。

交互流程简述：

  1. 用户设备通过SDK发起广告请求。
  2. 请求经网关到达请求解析模块，进行标准化处理。
  3. 流量分配模块首先检查是否有匹配的、需要优先满足的保量订单。若有，则保量模块进行定向、Pacing判断，选择广告。
  4. 如果流量未被保量订单完全消耗，或根据策略需要，流量会进入竞价模块。竞价模块进行广告召回、预估、智能出价、竞价拍卖和排序。
  5. 最终广告选择模块根据保量和竞价的结果，以及平台策略，选出最终胜出的广告。
  6. 素材获取模块准备广告内容，由广告投放服务返回给SDK进行展示。
  7. SDK上报曝光、点击等行为，由追踪模块记录，并通过流处理平台进行实时处理和后续分析。
  8. 所有核心模块都依赖支撑平台（如DMP、预算系统、机器学习平台）提供数据和服务。

该架构旨在实现保量合约的严格履行和竞价效率的最大化，同时具备良好的可扩展性和可维护性，以适应不断变化的业务需求和技术发展。

滚动至顶部