Banner Ad: Please Fix Your Pacing Algorithm
Decorative Header Image

Tag Archive for advertising

Using Proportional Control for Better Campaign Pacing

My post was originally published on the Rubicon Project blog. It was written with contributions from Dr. Neal Richter and Jonathan Zhuang.

Pacing algorithms come in a few basic forms at the Rubicon Project. The most basic is one called “as fast as possible” which can hardly be shown to do anything that resembles pacing. The Pacing controller is supposed to spread out impressions served for a campaign throughout the day. In general it takes the goal of impressions to serve in a given day as input and calculates a serving schedule for the campaign.

Estimated Curve of Available Impressions

A naive pacing algorithm will break the day up into 24 segments, let’s call them hours. It will allocate equal amounts of campaign impression for each hour and then recommend the campaign get impressions until the hour’s allocation is exhausted. This algorithm has a couple of pretty big flaws. Primarily it tends to serve the campaigns at the beginning of each hour and then once the allocated impressions are used up it stops serving until the next hour. The second flaw is that it has no understanding of the traffic distribution throughout the day. The 1AM hour doesn’t have the same amount of traffic coming in as the 10AM hour. If the inventory is relatively scarce the campaign will under-serve during the early hours, catch up during the peak hours, and then under-serve again in the later hours. Ultimately campaigns using this algorithm may not achieve their goals at the end of the day and it won’t serve evenly in a given hour. Read more

In a world without cookies

I’m hoping your mental audio kicked in with an interpretation of a movie trailer with a Don LaFontaine voiceover when you read the title. I wrote this post in response to a lot of articles written from a position of fear from the advertising industry at the prospect of web browsers shipping with 3rd party cookies disabled. Disclaimer: The opinions expressed here are my own and should not be construed as the opinions of my employer, associations or other groups I happen to belong to.

There’s a lot of highly visible worry in the news lately about online advertising losing the ability to set 3rd party cookies in a web browser. This technology is used to perform a variety of seemingly critical tasks: retargeting, audience targeting, frequency capping, user identification for RTB and probably a hundred other things – most of which I try not to know in detail.

The biggest concern seems to be that this growing part of the industry gets turned upside down if more browser companies decide to ship their products with 3rd party cookie disabled by default. Apple did this with their Safari browser which has been one component responsible for slowing down advertiser adoption of iOS devices. But advertisers have alternatives (like: display ads in other browsers, keywords, and online video ads) that they’re more comfortable with anyway, so there’s no telling how much of an impact the lack of 3rd party cookies on iPhones and iPads really has on the growth of the mobile ad revenue stream. Read more

The Real Problem with Getting More Spend Online

Two weeks ago I participated in a couple of events during AdWeek in New York.  The first was Rubicon’s own #letsfixit event where agency advertising representatives joined a panel with publishers and the rest of the demand train to discuss the difficulties of running ads online.  The attention shifted from learning about the process to learning about where the process fails.

Familiarity

Spend OnlineBernhard Glock of Medialink, who was not on the panel, but chimed in with a profound thought.  Buying on television is buying something that’s familiar, with seemingly known or at least comfortable impact and expectations on results.  By contrast, buying online display is a complete mystery.  His solution, just buy on television because that’s what he understands.

In addition to all the great insight each panelist shared, this sticks out as an important point of the event.  If there’s something to be learned by this it’s that the Kawaja diagrams are illustrating the point – online is confusing to the buyers, and that’s bad.  Read more

Using Dynamic Price Floors to Protect Publisher Value

I was reading a recent post on AdExchanger, “Smoking the RTB Weed,” about a Real-time bidding paper Metamarkets was gearing up to present at an industry event and it got me thinking about dynamic price floors (n.b. If you’re not already familiar with RTB, you might want to start with my earlier post on the topic to get up to speed. This post is pretty ‘inside baseball.’)

Disparity of Data

There’s a lot concern in the online ad ecosystem around the disparity of data between publishers and advertisers. These are not new concerns but they are attracting a lot of attention due to the opportunity that Real-Time Bidding (RTB) presents in leveling the playing field.

Historically advertisers have been incentivized to understand the audience behind the publisher in order to maximize their yield. This has led to a large investment in technology to serve the advertiser, tilting the balance of information to their favor and leading to rampant arbitrage.  As a result, most impressions are still sold without adequate protection.

Re-balancing Toward the Publisher

Real-Time Bidding affords the publisher an opportunity to re-balance the terms of the sale of inventory. In fact, in many ways the savvy, well-armed publisher can leverage RTB to gain an advantage in that each impression is evaluated and assigned a value by several buyers.

During an auction only one buyer can purchase the impression, but the data gathered from the other buyers is not discarded, rather it is captured by the publisher (or in our customers’ case, by REVV) and stored for analysis and pricing determination on all future bids.  Read more

RTB Primer

This post was written in the early days of RTB. While the description of the ecosystem it is still relevant, some of the products mentioned may have been renamed.

Real-Time Bidding diagram

Real-Time Bidding (RTB) might seem like old hat already, but there are still many misconceptions out there about how it actually works. It seems that there’s not a ton of material out there that explains RTB in a straightforward manner; until now.

The market explains RTB as sales channel where advertisers bid on their desired ad impressions, with the targeted impression going to the highest bidder. RTB ad serving is made possible through APIs shared among networks, exchanges and optimization platforms that dictate detailed transaction conditions.

While RTB’s value to publishers seems enticing as access to more demand sources equates to increased publisher revenue, the risks, however less apparent, are significant. Because RTB gives advertisers their desired audience at the lowest possible price, publishers are at risk of downward pricing pressure – and net negative revenue impact – resulting from the buy-side’s increased efficiency .

It’s for this very reason that the Rubicon Project recently launched the REVV Protected RTB 1.0 beta. I’ll explain how the REVV for publishers ™ 3.2 Yield Optimization platform handles Protected RTB at a high level to paint a clearer, basic picture.

How Bidding Works

A quick note – as you read through the following, bear in mind that the entire process described in the paragraphs below takes place in less than 80 milliseconds. For perspective, it takes about 300-400 milliseconds to blink an eye.

Let’s start with the ad request. This is the same ad request (a request from a publisher to fill a given ad impression) that would come in without Protected RTB engaged. The REVV ad engine checks the rules for that impression to see if it is eligible to receive real-time bids (the system calls that “Protected RTB enabled”) and which Demand Side Platforms (DSPs) should get exposure to it, per the publisher’s permission control settings (we currently work with a number of DSPs including AppNexus, Turn, Triggit, MediaMath, DataXu, Quantcast and Media6Degrees). If the impression is Protected RTB enabled, then the REVV ad engine packages the pertinent information about the impression and anonymized user information (no personally identifiable information) and sends to REVV’s real-time bid system.

The bid system receives the request from the ad engine, unpacks it and creates distinct request packages for each DSP.  Each bid request package includes information the DSP needs to make a decision whether to bid, including basic information about the site, the anonymized user information and ad itself parameters like dimensions and acceptable creative types. These request packages are all in a standard format defined for the REVV Protected RTB platform; each DSP has implemented the communication protocol according to REVV’s API specification. Read more