RTB rips the black box part 0:pacing:is everyone doing it wrong?

Having tried to solve pacing problems for our RTB customers , thepacing problem is: If a client gives you a budget to run an advertising campaign, In a certain period of time to serve the ads, the budget within the point of time, more evenly to the budget exhausted. If you spend more than your budget, you'll have to put your money on your own. If not consumed, this will be a little embarrassing for the next time you work with your customers. And if you don't consume evenly, you'll find yourself facing a bunch of angry customers. For example, a few minutes to burn the client's budget of $. It sounds obvious, doesn't it? But the problem is much more difficult than it sounds.

Doing it wrong

When datacratic first put his head into RTB , the main tool that controls budget consumption is a daily limit. It took us a few hours to find out that the following method is not feasible: we set up several types of filtering to determine when to bid on all requests. But the result is either that we have not consumed the daily budget, or that the budget has been burnt out soon, usually the latter. In practice, we bought the show from 0 and consumed it later in the morning.

No more bids after the daily limit is reached

If the customer is asking for a 30-60 Day, it doesn't seem too bad to use the above delivery method: Because the budget is consumed at the required time and the same amount is consumed every day. But we are not happy that there is a large period of time every day we do not make any bid. So we added a small feature to bid for x percent of traffic, and when this feature was released, we found that there was a very interesting phenomenon in the results: the traffic we used to buy is actually the most expensive traffic in a day! is an average winning price for a larger push plan, and it has a clear rule: if you start buying traffic from noon, the price ofCPM is gradually falling, until midnight suddenly steep up near 40%,CPM then some fluctuations, and then in the morning after the fall and then rise, until noon to reach the peak. Then another day begins with a new cycle.

You can see a steep rise in prices every night.

So why would there be a steep rise in the price of midnight? Supposedly this should be a fully competitive market, but after midnight the 1 minutes of traffic really than 2 minutes ago Traffic Multi-value 40% ? We're not completely clear on that! Our current speculation is: there must be a lot of competition environment DSP and we just started: set a daily limit per day, and reset the daily limit at midnight. This means that there is a high demand for traffic at midnight, because of this, the price is lifted (or perhaps one of the dsp After the daily limit is reset, its bid is higher than the previous bid DSP also high, which makes this small traffic price steep rise). And because dsps has different daily limits and flow control strategies, so they are consumed at different points in the day, This has led to a decline in demand, further causing prices to fall. From there is a rule is not obvious, but will multi-day effect superposition, get, can see in 3 o ' clock there was a similar steep rise, 3 o ' clock is midnight on the West coast.

The winning price per minute after the aggregate average in August

There are some other possible explanations for this steep rise now. Maybe we are in this position in the Northeast, so there is a change in the composition of the request flow in our region, so maybe this is just a regional rule? Although the steep rise of 3 o ' clock makes this explanation sound less reliable. Midnight also happens to be the time we start bidding, but our quantity is quantity-wise, and our quantity is not enough to explain this steep rise. It is also possible that some of the big sites have some minimum bid limits at midnight. or other DSPs are smart enough to find that the CTR after midnight is much higher than a few minutes before midnight. I am full of doubts about these explanations, and I am very welcome to discuss with anyone who has read my article. But whatever the reason, the following conclusions may be true: if you only want to advertise within a few hours of the day, don't choose to start running early in the morning, and10AM ends.

Do not know the domestic DSP Development has not done this data analysis, I analyzed the results and datacratic not quite the same, but I am still in the burst flow stage, may not be enough statistics, but there are some rules. Have a chance to have some discussion.

closed-loop Control to Rescue

Let us first assume this article, inRTBThe circle has aroused great concern, and this early morning price rise phenomenon disappears, or you may just want to spend the budget evenly on a daily basis, how to do it? As mentioned above, we can have a dailyx% proportional traffic to bid. The simplest way to do this is to divide the daily limit by the unlimited day consumption and get the bid ratio, which in principle can consume the day limit in the wee hours. However, in practice, only a fixed proportion of traffic bidding, the daily exposure will be very different, sometimes over budget consumption (if you do not set a daily limit) sometimes will be consumed by the budget. Maybe some days you will get a very large volume of requests, perhaps because you high ssp is making changes. If your request volume is in 9 Point is a straight line, because < Span style= "FONT-FAMILY:CALIBRI;" >google qps limit, this allows < Span style= "FONT-FAMILY:CALIBRI;" >google support team supports it. I was confused about why the request was so uniform. Perhaps ssp failed. And there will be a big change in auction traffic, such as a sudden increase (or a significant reduction) of requests from your targeted region. It is obvious that I am now considering the impact of the ad position, the requested traffic will sometimes have a large number of spam requests from an ad bit, resulting in a drastic change in my bid exposure. Maybe it's your bid logic itself that makes the consumption rate inconsistent. All of these factors will cause your consumption to vary over time:

Although the bid probability set is a constant, the rate of consumption may be uneven

So what's the solution? This problem is a cybernetics problem for us, and we have switched from no feedback control to feedback control. If you want to use probability to control the bid, then if you set the request probability, then after a week after the auction analysis results, this is basically no feedback control. If every morning you look at the previous day consumption is how much, and then adjust the spot probability of the day accordingly, then this is the practice of feedback control, feedback control is the output feedback to the input. This scheme is easy to automate, and it is natural to shorten the feedback cycle from days to minutes. Our RTB System redesigned the implementation of the bid speed according to this scheme, we can control the difference to the target bid speed to 1-2%, we only use the simple feedback mechanism: every 2 minutes, refer to the front 2 minute bid speed, set the ' correct bid speed ' for the next 2 minutes. So, for whatever reason, we assume that there are fewer 20% requests, such as at night, where the probability of the auction goes up and the consumption rate remains approximately equal. There are some more complex feedback control schemes, but this basic solution is good enough.

is the result of our feedback control. Note that the output without feedback control looks like Mordor 's Mountain (The ring), while the output of the feedback control is like the Shire Plain.

for real data, a little smoother to reveal deep changes,Pace ( Blue, probability *) will rise at night when traffic drops, consumption speed ( green ) will consume speed with target ( red ) almost consistent.

Like any good optimization algorithm, it does exactly what you want it to do: it strives to minimize the gap between consumption speed and target consumption speed. However, if the system has a serious failure, resulting in a period of time can not bid, when the failure to recover, this scenario will not adjust the target consumption speed to compensate for the previous period of the impact of the inability to bid:

After the failure, the consumption speed is not compensated (the slope is the same as the slope of the previous target consumption rate)

In order to deal with the impact of the failure, there are some because the system is imperfect, so that the accumulation of errors caused by the budget, not to the budget, we need to dynamically adjust the consumption speed target. We redefine the optimization goal of our feedback control: The consumption rate is always saved at the same level as the remaining consumption at the remaining time. This means that if one day or an hour fails, no manual intervention is required to compensate for the consumption speed target after the failure. This system also has a very good nature, it will automatically stop when the remaining consumption is 0 .

Obviously, you don't want to use the same rate of consumption at any time, in fact I think you're definitely not. A feedback control system can support almost any curve that you want to consume speed. You can use variables outside of the bid probability to control them ( For example, a real bid price, or a directional condition, or any way you can think of it ). Finally, an agile reader may find that the method described above only works if the requested traffic is larger than the amount you can buy, and if your bid probability is set to 100%, you will not get your daily limit, even if you win all the traffic is impossible to reach the budget, Even if you win all the traffic, you can't get to the budget. The method above is invalid.

RTB rips the black box part 0:pacing:is everyone doing it wrong?