广告投放中cpm，cpc，金额预算控制

一个广告用户可能希望每天投放500个cpm，或者500个点击，或者500块钱。如果我们投放缺量了，比如只有400个cpm，那么，我们就不能按照用户的要求完成用户的投放，我们就需要告诉用户为什么只投放了400个cpm，如果我们投放了600个cpm，那么超过的量就需要我们自己买单。

 

这种场景最初是在广告投放引擎中出现，而且超量问题一直是一个麻烦的问题，某一行代码逻辑不够严谨都可能导致超量问题。

 

假如我们投放的机器可能有5台或者10台机器，每台机器如何分量，以及如何能控制不超量。接下来会描述一些可行的解决方案。

1：首先以传统广告投放引擎为例：

因为有多台机器，所以必须要有一个来控制10台机器的投放控制服务器，可以是一台，也可以是多台，如果是多台，还需要一个控制多台的服务。接下来举例以一台为例子。

a：如果是cpm或者金额预算控制：

在投放机上设置一个默认的server_count，比如有10台机器可以设置为10，则每台机器能投放的量为十分之一，假设没有投放控制服务，则每台机器按照十分之一的量来投放也不会超量，但是每台服务器的投放能力肯定是不一样的，如果有投放控制服务器的时候，先让每台机器按照默认的量来投放，并将投放数量定时发送到投放控制服务器，比如10秒钟发送一次，投放控制服务器将会实时计算每台机器的投放数量，动态的调整每台机器的server_count，投放多的机器则多分，投放少的则少分，不断的计算与迭代，直到最后投放完成。

b：如果是cpc控制：

cpc预算控制比较复杂一下，因为我们不能直接控制cpc，只能通过cpm来控制cpc，这时候就需要预估ctr，如果点击率暴涨或者暴跌，ctr的计算也会变得更加的复杂，假设ctr为千分之一，500个点击可以投放500个cpm，但这只是理想情况，因为在显示之后过了几分钟，甚至十几分钟都有可能点击，所以需要一个延后的计算，特别是最后的10%的量的时候不会一下子分出来，需要过一段时间才能分出来，而这个时候又可能导致缺量，所以当时在做投放引擎的时候并没有找到一个很好的控制方法。

2：下面介绍dsp后台投放系统的控制

dsp和投放引擎最大的区别是，dsp只是去参与竞价，竞价了并不代表成功，只有最终收到winnotice才表明竞价成功并显示。

a：显示或者点击控制

dsp中每日显示和点击通常被用来做为频次控制，比如每个campaign每天或者24小时之内需要显示和点击多少次，当收到显示或者点击监测时，将显示监测和点击监测数据设置到redis存储服务器中，当请求竞价服务器的时候从redis中获取显示或者点击是否到达上限，如果到达上限，则该campaign不能参与竞价。（如果不计算ctr，点击控制其实不太准）

b：dsp预算控制：

如果广告主是cpm投放：

方法一：分bid量，比如一个cpm默认1块钱，一天投放1000块，竞价成功率为10%，,则总共可以分1000*1000*10次bid，然后按照server_count分配到每一台机器，然后winnotice的时候上报投了多少钱，然后再根据剩下的钱分bid到每台机器，如果还有bid量则参与竞价，没有bid量则不参与竞价，直到最后预算花完为止。这种方法有一个缺点就是cpm的价格如何估算，还有一个缺点是如果更新不及时，可能导致某一段时间不能参与竞价。

方法二：分bid量和分显示量结合，当预算充足的时候分bid量，预算不多的时候，直接分显示量，还有pv可显示的时候，才参与竞价

方法三：每次收到winnotice的时候，上报花了多少钱，比如上报到redis，bid服务器将是否有预算作为一个定向请求预算控制服务器，预算控制服务器通过获取redis的数据，以及投放设置数据，计算是否还能参与竞价，返回所有可以参与竞价的campaign。这样的缺点是每次bid请求都要请求预算控制服务器，如果是异步调用，每次调用不是问题，如果不是异步调用(也不是基于协程的框架)，就会导致程序性能急剧下降。

如果广告主是cpc投放：

则需要先预估ctr，通过ctr将点击量转换为显示量，然后再按照显示量去控制

如果是cpa/cps投放：

也需将cps转换为cpa，cpa转换为cpc，cpc转换为cpm，做起来会更复杂，对算法要求比较高。控制的准确率也会更低。

以上提到的都是一些解决方案，有些大公司可能有更加优秀的解决方案，这里只描述我所了解到的解决方案。

原文最初写于网易博客，先移到此处