APP 只展示高价广告几乎每个接入了广告联盟的 App 开发者在做变现阶段时都会考虑这个问题。高价广告意味着更高的 eCPM、更高的单次展示收益那为什么不直接把低 eCPM 的广告源全部过滤掉技术上的确可以做到一部分但代价往往比收益更明显填充率下降、延迟上升、收益波动变大甚至可能被广告联盟的风控体系判定为流量质量异常。这篇文章会从广告竞价机制讲起分析 App 开发中“只展示高价广告”的几种实现路径再把每个路径背后要付出的开发成本、流量成本、用户体验成本和收益风险拆开讲清楚。这不是一篇教你怎么“薅广告联盟羊毛”的文章而是一篇关于广告变现技术设计和方案取舍的经验总结。面向正在做 App 开发、打算接入广告联盟或者已经在接广告但收益和填充率一直调不好的团队。读完以后你应该能回答三个问题能不能只展示高价广告用什么技术手段做到如果坚持做会付出哪些代价1. 先理解“高价广告”从哪来才知道技术能不能筛很多人把“高价广告”理解成广告联盟后台里的一批固定广告商品开发者可以按价格挑着展示。这是最大的误解。广告交易是实时竞价广告主不会给出一个固定售价开发者看到的高 eCPM 是由每次请求、每次展示的竞价结果统计出来的。1.1 广告不是商品库里明码标价的商品广告联盟里的广告请求流程大致是这样App 初始化 SDK 后在某个场景请求展示广告SDK 把广告位信息、设备信息、用户画像标记、地区、时间等参数发送给广告服务器广告服务器再把这些参数交给一组参与竞价的 DSP需求方平台或广告主去报价某个广告主胜出后广告创意返回给 App最终展示给用户。如果广告位没有真实用户流量没有用户画像标记没有广告主愿意为该次曝光出价那么这次请求就不会被填充。即便这条广告请求是从一个历史上 eCPM 很高的 App 发出去的本轮没有广告主竞价结果依然是 no fill。所以“高 eCPM 广告源”并不是稳定的库存。价格是动态的广告主会在不同时段、不同地区、不同用户身上出不同的价。一天之内同一广告位的价格可以相差很多。1.2 一次广告请求到展示的完整链路接入广告联盟时开发者需要理解请求链路里至少包含这几个环节App 内的广告管理模块向聚合层发起请求。聚合层按配置请求一个或多个广告源 SDK。广告源 SDK 再到自己的服务器和实时竞价系统完成询价。广告源返回广告创意、价格信息、过期时间等数据。聚合层决定展示哪个广告源返回的创意。展示成功后上报展示事件后续再有结算、归因、防作弊等异步流程。如果 App 不使用聚合平台只是单独接一家广告联盟那么可选空间很小基本上是“人家给什么广告就展示什么广告”。只有当 App 接入了多家广告源或者接入了支持多广告源管理的聚合平台时才能在代码或配置层面做筛选。1.3 eCPM 是结果不是一次请求前就知道的报价eCPM 全称 effective cost per mille意思是每千次展示可以获得的收益。常见的计算口径是[ eCPM \frac{总收入}{展示次数} \times 1000 ]但一个广告源返回广告时App 往往不能直接拿到一个“最终结算价格”。瀑布流模式下广告联盟 SDK 可能只返回一个排序参考值竞价模式下实时出价可以拿到但使用实时竞价也意味着 App 要同时让多个广告源进入竞价流程。所以一个很关键的技术判断是你在客户端看到的“高 eCPM”通常是历史统计或者聚合平台给的一个预估/参考值不是本次请求的真实成交价。真正常见的优化做法是基于历史数据预判哪些广告源值得优先请求而不是在每次请求时看价格再挑选。1.4 对工程技术问题的重新表述“APP 只展示高价广告”这句话放到工程里应该被改写成更准确的描述当一次广告请求可以连接多个广告联盟或多个广告源时如何通过聚合配置、路由逻辑或实时竞价技术让那些历史 eCPM 较低、填充表现不稳定、质量风险较高的广告源被延后请求或者不再请求。问题从“挑广告主”变成了“挑广告源、挑流量分发路径”。这是可以实现的但每一种实现都有代价。2. 技术上能实现“只展示高价”的三种主流路径现实工程里最常见的手段有三种瀑布流排序、实时竞价选最高价、自建广告源路由层。它们控制的粒度不同适用的团队规模也不同。2.1 瀑布流配置把高 eCPM 广告源排在前面瀑布流模式是传统广告聚合常用的方式。开发者把不同广告源按历史 eCPM 从高到低排序排序靠前的先请求如果靠前的广告源没有填充再尝试后面的广告源。从效果上说这确实能实现“大多数情况下优先展示高价广告”。比如Mediation 瀑布流顺序: 1. AdSource A 历史 eCPM 8.5 美元 2. AdSource B 历史 eCPM 4.2 美元 3. AdSource C 历史 eCPM 1.8 美元 4. AdSource D 保底渠道当 App 发出广告请求时聚合层先请求 A。A 有广告就展示 AA 没有广告再请求 BB 也没有再请求 C。在多数聚合平台上这不是写在客户端代码里的而是通过后台配置完成的。你需要给每个广告源配置广告位 ID。请求顺序。超时时间。是否开启价格下限floor price。在该广告源无填充时是否立即回落。如果设置了一个较高的 floor price可以理解为“低于该价格的广告不要返回给我”这就在一定程度上去掉了低价广告。2.2 实时竞价让多个广告源同时报价展示最高价瀑布流的缺点是串行请求耗时和效率都不理想。为了更接近“选最优价”广告行业的解法是 in-app bidding也就是应用内竞价。在应用内竞价模式下App 同时向多个支持竞价的广告源发起请求各家广告源在几百毫秒内返回值。客户端拿到这些返回值后再根据 price、过期时间、尺寸、素材内容等条件选出最终的展示来源。现实中的广告源 SDK 通常已经封装了这套逻辑开发者需要做的主要是配置。示意逻辑不等于真实代码但可以这样理解// 示意逻辑不代表任何广告 SDK 官方接口 public class RealTimeBiddingController { private ListBidder bidders; public void loadAd(String adUnitId) { long requestStart System.currentTimeMillis(); for (Bidder bidder : bidders) { bidder.requestBid(adUnitId, new BidCallback() { Override public void onBidSuccess(BidResponse bid) { bestBidSoFar.compareAndSet(bid); } Override public void onBidFail(String reason) { log.warn(bid fail from bidder.name() , reason reason); } }); } waitUntilTimeoutOrAllRespond(requestStart); BidResponse winner bestBidSoFar.get(); if (winner null) { onNoFill(); return; } if (winner.getPriceInUsd() getFloorPriceInUsd()) { onBelowFloor(); return; } winner.show(); } }实时竞价的优势是它能在很大程度上避免“人工拍脑袋排序”。谁出的价高谁就赢开发者不需要预先把广告源分成三六九等。但注意一个容易被忽略的问题实时竞价只能决定“在参与竞价的这些广告源里谁赢”。如果某个低价广告源不参与竞价或者某个广告源在这次请求中因为没货返回低价那么整体填充率仍然可能偏低。只展示高价广告这件事在实时竞价里同样要受到填充率的约束。2.3 自建广告源路由层按业务规则动态过滤如果团队接入的广告源足够多且数据上报链路完整也可以自建一个广告源路由服务。App 在请求广告前先向自己的控制服务查询当前广告位应该启用哪些广告源、屏蔽哪些广告源。这个方案的核心是把广告源过滤规则放到服务端比如{ adOptimization: { version: 20240501, enable: true, worldwide: { enabledSources: [AdSourceA, AdSourceB], disabledSources: [AdSourceC], noFillFallback: [AdSourceD] }, country: { US: { enabledSources: [AdSourceA], minEcpmUsd: 6.0 }, ID: { enabledSources: [AdSourceB, AdSourceD] } } } }App 进入广告场景时先拉取这份配置再决定把这次请求发到哪些广告源。这个方式的控制力最强但客户端、服务端、上报系统要一起联动工程成本比前两种高很多。对于只有一两个广告位的 App 来说做自建路由纯属过度设计。2.4 三种方式的核心代价对比实现方式是否实时比价开发成本填充率风险推荐场景瀑布流排序否按历史 eCPM 排序低主要依赖后台配置排序不合理时填充率下降明显中小团队广告源数量少应用内实时竞价是多家同时出价中依赖 SDK 支持和聚合平台支持可控但仍可能遇到全域无填充广告源较多希望减少人工调优自建路由服务由自建服务决定高需要客户端、服务端、数据链路一起建设配置错误将直接导致无填充大型 App广告位多有专门变现团队3. 客户端别写死价格用服务端规则控制低价来源很多人第一次尝试“只展示高价广告”会直接在客户端写一个 if 判断if (ecpm 4.0) { return; // 不展示低 eCPM 广告 }这种写法要尽量避免。原因是 eCPM 不是客户端能准确预测到的实时值把业务阈值写死在代码里后续调试和调整都很难做。更合理的做法是把判断逻辑做成一个可以动态调整的开关。3.1 先理解历史 eCPM 的作用客户端能做的最合理的预判是基于历史数据。比如统计过去 7 天某个广告位、某个广告源、某个国家的 eCPM 中位数或 P70 分位值再决定是否继续使用这个广告源。如果只用一个全天平均 eCPM会遇到一个问题某个广告源在欧美地区 eCPM 很高但在东南亚地区几乎没有广告主出价。把全渠道放在一起平均会高估它的整体收益能力也会低估其他渠道在特定国家的价值。因此在代码里做过滤时至少要以“广告位 广告源 国家/地区”这样的维度去看数据。3.2 一个最小可行的过滤原型下面是一个示意代码用来表达“低价格广告源要不要参与请求”的判断逻辑。它不是某个广告 SDK 的官方 API只是一个可参考的原型。public class AdSourceOptimizer { private final double minEcpmThreshold; private final RemoteConfig remoteConfig; private final AdStatRepository statRepository; public AdSourceOptimizer(double minEcpmThreshold, RemoteConfig remoteConfig, AdStatRepository statRepository) { this.minEcpmThreshold minEcpmThreshold; this.remoteConfig remoteConfig; this.statRepository statRepository; } public boolean shouldRequest(String adUnitId, String adSource, String country) { // 当远程开关关闭或紧急回退时放开所有广告源优先保填充 if (!remoteConfig.isAdOptimizationEnabled()) { return true; } Double medianEcpm statRepository.historicalMedianEcpm(adUnitId, adSource, country); if (medianEcpm null) { // 没有历史数据时不要直接拦截避免新广告源永远无法起量 return true; } if (medianEcpm minEcpmThreshold) { logSkip(adSource, medianEcpm); return false; } return true; } private void logSkip(String adSource, double medianEcpm) { // 记录跳过原因用于后续排查填充率问题 } }这段代码想说明三点有“紧急开关”随时恢复默认请求逻辑。以“历史中位数”作为参考而不是单次请求的临时数据。没有历史数据时放行避免新广告源因为冷启动一直被屏蔽。3.3 用 Remote Config 做分阶段灰度在真实项目里这个阈值不应该是一成不变的。它需要跟随统计数据变化。建议把阈值放到 Remote Config 或自建配置中心中按以下维度下发全局阈值。国家/地区粒度阈值。广告位粒度阈值。是否启用 kill switch。这样做的意义是当发现填充率在某个国家快速下降时可以通过配置中心立刻降低阈值不需要重新发版。如果每天都要发版调价那这套系统基本没法生产化。同时要设计灰度流程。先让 5% 的用户使用新的过滤阈值观察无填充率和 ARPDAU再逐步扩大到 10%、50%、100%。这里一定要避免一步到位。因为单看 eCPM 变高并不代表收益变好填充率一旦掉下来总收入可能不增反降。4. 真正要付出的代价收益、延迟、稳定性和风控这一部分是全文重点。技术可以做到“只展示高价广告”但你要想的不是能不能做到而是做了以后原来的流量模型会发生什么变化。4.1 填充率代价低价广告源被过滤后高价位不一定会补位假设一个 App 每天产生 10 万次广告请求广告源 A 的 eCPM 很高但填充率只有 30%广告源 B 的 eCPM 一般但填充率有 80%。如果强行只让 A 参与请求每个请求都会先去找 A但 A 只有 30% 概率返回广告。剩下 70% 的请求在等待超时后才去请求 B 或其他低 eCPM 广告源。这会带来一种很常见的现象后台 eCPM 指标上涨了但填充率下降总展示量下降最后整体收入下降。eCPM 只是一个单位收益指标它不是总收入。可以把广告源过滤看成一次“流量切成两段”的操作高 eCPM 广告源命中时收益很高高 eCPM 广告源没命中时你要么展示一个延迟回落的低 eCPM 广告要么展示空白。只看平均 eCPM 广告源 A请求 100填充 30eCPM 8 美元 广告源 B请求 100填充 80eCPM 2 美元 在无过滤瀑布流中 总收益约 30 * 8 80 * 2 400按千次展示等比例估算 如果只让 A 参与 最多只能拿到 30 * 8 240剩余请求大概率变无填充或极低填充这个例子里的数字只是示意但它能解释为什么很多团队设置高 floor 后第一周 eCPM 好看月底收入却变少了。4.2 延迟代价高价广告源需要的响应时间并不短瀑布流模式下广告源是按顺序请求的。如果排在前面的高 eCPM 广告源返回慢后面的广告源就要等。一次广告请求本身超时时间通常是 3 到 5 秒如果广告源 A 耗掉 1.5 秒无填充广告源 B 再耗 1.5 秒无填充用户可能已经离开页面了。只展示高价广告的另一种隐含代价是为了追求价格你愿意等待更长的时间。但广告场景尤其是插屏、激励视频和开屏广告对延迟非常敏感。用户等待越久展示机会流失越多最终能够展示的广告反而变少。如果希望既能控制价格又能控制延迟可以考虑预加载和并行请求而不是每次进入广告场景时才临时拉取。但预加载又带来另一个问题提前加载的广告可能过期展示时可能无效这需要 SDK 和数据上报配合。4.3 工程化和稳定性代价越“聪明”的路由越容易出故障自建路由看起来很理想但它要求团队维护一套规则引擎、统计报表、配置发布系统和异常监控。任何一个环节出问题都会直接影响线上广告收入。例如服务端配置字段写错导致某一地区所有请求被禁用广告源。客户端缓存了旧配置导致新广告源迟迟不起量。历史数据统计口径不一致导致某广告源被误判为低价来源而长期拦截。kill switch 没有生效问题爆发后需要等客户端更新缓存才能恢复。这些代价不是技术能不能实现的问题而是团队有没有能力长期维护这套系统的问题。对于大部分中小型 App使用成熟聚合平台的自带能力比自建路由更稳妥。4.4 收益稳定性代价一天的异常波动会抵消一周的优化广告收益不是线性的。低价时段、周末、节假日、广告主预算变化都会影响实时 bidding 价格。如果客户端只保留高 eCPM 广告源那么在广告主预算不足的时段这些广告源可能大量无填充整体无填充率会突然升高。更麻烦的是只保留高 eCPM 来源会让你的收益曲线出现明显的“阶梯式”波动有广告主竞价时收益很高没有广告主竞价时一片空白。真正稳定的广告变现应该让收入曲线平滑而不是靠运气。建议至少监控三个指标的变化指标含义优化时重点关注什么eCPM每千次展示的平均收益只看这个指标容易误判填充率请求中能成功展示广告的比例过滤低价源后可能下降ARPDAU每个日活用户带来的日均广告收入综合判断用户价值与填充率的平衡如果 eCPM 上升了但 ARPDAU 不变或者下降说明过滤策略并没能带来真实收益增长。4.5 用户与产品代价空白广告位比低价广告更伤体验很多团队只关注收益忽视了用户看到“广告加载失败”或“空白区域”时的体验损失。一个申请了广告位的页面如果因为阈值过高而长时间显示空白用户会认为产品有 Bug而不是认为广告主没有竞价。所以“只展示高价广告”通常会牺牲一定的广告可见性。没有广告出现也就没有收入没有收入但用户承担了额外的加载等待和页面抖动。这是产品层面必须算进去的隐性成本。4.6 平台风控和质量成本不要让流量被判定为异常需要强调不是所有广告联盟都会惩罚“选择性请求高 eCPM 渠道”这种做法本身属于正常的流量分配优化。但有一类风险必须提防如果某些流量在广告联盟后台长期表现为“请求稀少、只命中高价值广告、基本没有低价值展示、填充率长期极端”且流量质量本身不稳定那么变现后台的质量评估模型可能会将这部分流量标记为待观察流量。这个结论不是官方政策而是行业里广告流量质量分析常见的方向。更安全的态度是把优化目标放在提升整体竞价环境和广告源匹配效率上而不是把低 eCPM 广告源一刀切全关掉。你要优化的不是“只展示高价”而是“让每次展示尽可能匹配到愿意出更高价格的广告主”。4.7 高 eCPM 过滤一定会遇到的典型表现阶段可能表现需要警惕的问题刚开始配置eCPM 明显上涨填充率可能同步下降运行一周某几个地区无填充率升高广告源在这些地区没有广告主预算引入配置后所有高风险流量都走高 eCPM 源某些用户群体长期看不到广告收益统计展示收入下降但 eCPM 上涨总收入被展示量拖累5. 收益下降、无填充率升高按这条链路定位问题真正上线“只展示高价广告”后最常见的反馈不是“收益变高”而是“怎么收益反而降了”。下面是一个可以照做的排查链路。5.1 先看数据再看配置最后看代码排查顺序推荐按这个方向走先确认线上的广告源过滤配置是否真正生效。看无填充率、请求超时率、展示量变化。按国家和地区拆分数据确认是局部问题还是全局问题。查看日志确认广告源是被过滤掉还是请求了但无填充。用测试设备复现确认代码分支是否按预期执行。最后检查广告 SDK 版本和聚合平台配置是否一致。5.2 根据现象定位原因问题现象常见原因检查方式处理建议eCPM 上涨但总收入下降展示量下降低 eCPM 源被过滤后没有高 eCPM 源补位对比过滤前后的请求量、展示量、填充率降低最小 eCPM 阈值或开放保底渠道某国家无填充率很高该广告源在该地区没有广告主预算按国家维度拆数据对不同国家配置不同阈值广告请求迟迟没有结果高 eCPM 源串行请求耗时过长查看请求超时率和单源平均耗时增加聚合超时限制或开启并行请求配置改了很久仍未生效客户端缓存了旧 Remote Config查看配置拉取时间与缓存策略为配置增加版本号并支持强制刷新广告源几乎没有请求量历史数据为空或统计维度错误查看统计代码的广告源维度是否记录正确排查统计上报链路和维度拆分5.3 用日志确认客户端过滤逻辑如果是自己增加了广告源过滤逻辑可以在代码里记录三条关键日志。if (medianEcpm null) { Log.d(AdOptimize, no history, open source: adSource); return true; } if (medianEcpm threshold) { Log.d(AdOptimize, skip low ecpm source: adSource , medianEcpm medianEcpm); return false; } Log.d(AdOptimize, open source: adSource , medianEcpm medianEcpm);Android 客户端可以用 adb 查看adb logcat -s AdOptimize adb logcat | grep -E AdSourceOptimizer|skip low ecpm|open source这里要注意不要在线上版本长时间输出高频日志尤其不要在每个广告场景里都打印 Debug 日志。可以加一个只对测试包或白名单设备生效的开关。5.4 修复后要做回归验证调整完配置后不要只看一天的数据因为广告收益周期性很强。建议回归验证周期至少包含一个完整工作日。一个周末或休息日。至少覆盖主要目标国家的主要广告时段。用户版本覆盖率超过一定比例后再下结论。验证内容不只要看 eCPM 是否更高还要看请求量、填充量、无填充率、ARPDAU、刷新率异常等综合指标。6. 更稳妥的方案从“只展示高价”转向“最优单位用户价值”对于绝大多数 App不建议把目标设置为“只展示高价广告”。更符合长期利益的指标是在保证基础填充、延迟和用户体验可接受的前提下尽可能提高每个日活用户带来的广告收益。6.1 分组配置不要让一个阈值管所有场景同一个广告源在不同国家的 eCPM 差异可能很大。一个简单的时间配置可能是错的尤其是把“某个地区高价广告源”的结论扩散到全球。建议按照下面的分组维度设置分组维度说明广告位类型开屏、插屏、激励视频、Banner、原生分开配置国家和地区欧美、东南亚、拉美等地区差异大用户新老新用户的广告容忍度低老用户相对稳定时段广告主预算波动会形成高低峰App 版本可以使用灰度版本验证策略6.2 使用 A/B 实验代替主观判断“只展示高价广告”在团队内部听起来很有吸引力但上线前应该先做实验。实验组可以设置“旧配置 目标 eCPM 过滤”对照组维持原来的混合请求观察时间建议 7 天以上至少覆盖一个周末。核心指标建议用 ARPDAU而不是单独看 eCPM。如果 ARPDAU 没有显著提升说明这套过滤对真实收益没有帮助。6.3 生产环境的配置外置化与回滚方案千万不要把过滤逻辑只实现在客户端代码里。生产环境下广告优化策略必须能满足“动态调整、快速回滚”。推荐的技术链路是客户端启动时或定期拉取 remote config。remote config 中包含所有广告源过滤阈值。开启 kill switch遇到异常时把所有广告源放回请求列表。客户端的策略判断只读取缓存配置不依赖本地硬编码。配置中心记录每次变更前后的数据方便回溯。这样即使新策略有问题也可以在 1 分钟内切回旧配置不用等应用市场审核和用户更新版本。6.4 可复用的广告变现优化检查清单真正落地一套广告变现优化方案时可以从这几项里逐条确认[ ] 是否明确“高价”是基于历史 eCPM还是实时 bidding 价格。[ ] 是否按广告位、国家、时段、用户类型拆分过收益数据。[ ] 是否有 Remote Config 或配置中心支持动态调整阈值。[ ] 是否具备紧急回退开关能快速恢复默认请求逻辑。[ ] 是否同时观察 eCPM、填充率、无填充率、ARPDAU 四类指标。[ ] 是否在测试环境中使用官方测试广告位避免污染真实数据。[ ] 是否设置合理的请求超时时间避免低填充广告源拖慢展示链路。[ ] 是否保留至少一个综合保底广告源保证极端情况下仍有广告展示。[ ] 是否通过 A/B 实验验证新策略而不是直接全量发布。[ ] 是否建立日粒度报表能及时发现某个国家或广告位的数据异常。6.5 开发生命周期里最容易忽略的三类坑第一类坑是只在客户端写死阈值。代码上线后无法快速调整一旦广告主预算变化整个策略就失效必须重新发版。推荐的写法是 remote config 或配置中心。第二类坑是不拆分地区。某广告源在美区 eCPM 很高但在其他地区几乎无填充。如果不拆分地区平均后的数据会高估该广告源的价值导致它在低价值地区也被排到前排。第三类坑是忽略超时机制。串行请求高 eCPM 广告源时如果该广告源一直不返回结果可能把整条广告请求链路拖到超时。实际工程里建议设置单层超时时间并且在下一个广告源请求前先判断剩余时间是否充足。7. 给 App 开发者的下一步建议“只展示高价广告”这个问题本身就是广告变现技术和流量质量的复杂交叉点。技术能实现的方案很多但真正决定收益成败的往往不是你能不能把低 eCPM 广告源屏蔽掉而是你是否有完善的数据统计、实验验证和动态配置体系。如果你刚开始做 App 开发建议先不要碰自建路由这种重方案。先用一家主流广告联盟的 SDK 跑通数据再接入聚合平台搞清楚 eCPM、填充率、无填充率、请求超时率这些基础指标是怎么统计的。你能看懂数据波动才能判断一个优化策略是否有效。如果团队已经接入了广告联盟并且正在纠结“要不要只展示高价广告”可以从一个很小的实验开始只对一个广告位、一个国家或一个用户分桶做阈值过滤观察一周数据而不是直接全量切换。用数据回答“代价是什么”比靠逻辑推理更可靠。真正可持续的广告变现优化是让合适的人在合适的场景看到合适的广告同时保证广告填充稳定、请求延迟低、用户不被恶意打断。只盯着一两个高 eCPM 广告源短期可能看到漂亮数字长期却会付出填充率下降、收益波动和流量质量被怀疑的代价。