第3章广告请求链路

3. 广告请求链路：用户发起请求 -> 媒体SDK -> ADX -> DSP竞价 -> 返回创意

好，咱们今天聊点实在的。广告请求链路，说白了就是一条「钱」和「流量」的运输管道。你想想看，用户刷一下手机，一个广告就出来了，这背后其实是一整套系统在几毫秒内完成的博弈。

我个人习惯把这条链路拆成五个关键节点。每个节点都有坑，我一个个说。

用户打开一个App，或者浏览一个网页，这就是起点。但这里有个容易被忽略的点——请求是谁发起的？

不是用户直接发起的。是App里的SDK，或者网页里的JS代码，在页面加载时自动触发的。用户只是「被动」参与了这件事。

关键数据：这个请求里带了什么？

我记得有一次排查线上问题，发现某个地区的广告填充率特别低。查了半天，原来是用户请求里带的GPS坐标精度不够，导致ADX无法做地域定向。嗯，这里要注意——请求数据的质量，直接决定了后续链路的效果。

媒体SDK是广告请求的「翻译官」。它把App里的用户行为、设备信息，打包成一个标准化的请求，发给ADX。

我曾经遇到过一个问题：某个媒体SDK版本太老，请求里带的设备ID格式不对，导致ADX那边解析失败。结果就是——用户能看到广告位，但永远刷不出广告。你说用户烦不烦？

避坑指南：我曾经在对接一个新媒体时，发现SDK的请求超时时间设成了10秒。你想想看，广告请求总共就几百毫秒的事，10秒超时等于没设。后来我强制要求所有SDK的超时时间不超过2秒。

媒体SDK还要做一件事：广告位的管理。比如这个广告位是Banner还是插屏？尺寸是多少？这些信息也要打包进请求里。

ADX（Ad Exchange）就是广告界的「证券交易所」。它收到媒体SDK的请求后，会做几件事：

这里有个技术细节——ADX的竞价请求是并发的。也就是说，ADX同时向几十个DSP发请求，等它们返回出价，然后选最高的那个。

注意：并发请求不是越多越好。我见过一个ADX，同时向100个DSP发请求，结果网络带宽被打满，响应时间飙升到3秒以上。用户早就不耐烦地关掉页面了。

我个人建议，ADX的并发数控制在20-30个DSP比较合理。既能保证竞价充分，又不会拖慢响应速度。

DSP（Demand-Side Platform）是广告主的「代理人」。它收到ADX的竞价请求后，要快速决定：这个流量值多少钱？

DSP内部会跑一个模型，根据用户画像、历史行为、广告主预算，算出一个出价。这个过程通常要在50毫秒以内完成。

DSP出价后，把结果返回给ADX。ADX比较所有DSP的出价，选出最高的那个。然后通知胜出的DSP：「你赢了，把创意发过来吧。」

胜出的DSP把广告创意（图片、视频、落地页链接）返回给ADX，ADX再返回给媒体SDK，最后展示在用户面前。

这里有个容易出问题的地方——创意的加载速度。如果创意文件太大，比如一个5MB的视频，用户网络又不好，那广告位就会一直空白。用户等得不耐烦，直接划走了。

最佳实践：

我记得有一次，一个广告主上传了一个4K分辨率的图片，文件大小8MB。结果广告展示率不到10%，因为大部分用户还没等图片加载完就离开了。后来我建议他们压缩到200KB以内，展示率直接翻了三倍。

你想想看，从用户发起请求到广告展示，整个链路必须在200-300毫秒内完成。超过这个时间，用户就会感觉到卡顿。

我给大家一个参考数据：

加起来刚好300ms。每个环节都不能超时，否则整个链路就崩了。

我的习惯：我会在每个环节都加一个超时熔断机制。比如DSP超过100ms没返回，ADX直接跳过它，用次高出价。这样至少能保证广告能展示出来，虽然可能不是最优的。

好了，广告请求链路就这些。说白了就是一场「毫秒级的拍卖会」。每个环节都在抢时间，每个环节都在博弈。你只要记住一点——用户等不起。所有优化，都要围绕「快」这个字来做。