按:广告系统是互联网商业化过程中核心系统之一,像今日头条、百度等,大头利润都靠卖广告。广告系统有何独特的特性?可从中多学习。本文来自新浪徐挺的分享。
摘要
其实新浪很早就开始研究广告系统了,根据UserID + CookieID + 用户行为日志等多重要素进行用户区分,进而针对个体用户做控频投放。同时为了更好的监控广告服务平台的性能和准确性,新浪广告技术团队在此基础上进行了众多改善措施。
技术架构和痛点
sinaX 服务化之前的架构
可能有些朋友对互联网广告的技术架构不太了解,这里先介绍下大概的构造。基本上所有的公司的技术方案中都有一个adexchange——负责广告流量接入以及流量优化的模块(图中的中间模块)。
从上端过来的广告流量都会进行流量优化,优化完成后将向下方的各个投放DSP询价。
整个过程类似拍卖,一个流量进来后,如果被判断为优质流量,就会向一些DSP发起竞价请求,DSP根据内部的算法优化以及用户行为优化给出价格,adexchange接收到这些报价后会决策出胜出者,最后广告请求被给到胜出者。这里面adexchange主要在做两件事,一是决策出竞价胜出者,二是生态层面的调整,adexchange对下方所有投放引擎并不是一致均等对待的,而是根据阶段性广告生态的要求做出调整。
早期我们的adexchange是基于Nginx服务器,在服务器内部有Lua写的业务逻辑,也就是前面提到的竞价规则和流量最优化调度。
SinaX 旧架构的痛点
由于adexchange对投放引擎并非是一视同仁,所以整个流量呈现的是一个漏斗模型。
在adexchange的开发过程中,为了能够更好的实现漏斗模型以及业务提升,我们在内部进行了二次开发,开发过程中发现了很多问题。
用Lua做功能开发并不方便,因为需求的频繁变化导致需要即时响应,而即时响应的过程中有些功能使用Lua嵌入非常麻烦。Lua代码可维护性差,一旦出现人员变动,新人阅读之前代码的成本很高。
第三是业务内的监控很难做,如果采用Nginx加Lua的方式,严格来说唯一的解决方案就是使用某种方式将日志输出,很难在Nginx内部提取状态量发送到关键业务检测点上。最后是测试问题,基于Nginx加Lua的环境做完全量测试或者全量灰度测试很麻烦,一般只能通过直接嵌代码的方式解决,无法采用一些传输的技术方案。
<