Archive for Working On It

One bid per DSP per impression – why?

Why historically (and currently) only one single bid was allowed for each DSP per impression? Why hide demand from the exchange and create opportunities for the DSPs to arbitrage? – I know this is changing now with the possibility of multiple bids per DSP (openRTB v2) but why ad exchanges let this happen at the beginning?
This question was asked on quora, below is my answer.

Short answer:
A multiple bid response was discussed at the very first OpenRTB meeting.  It was not seen as a favorable feature by the demand side, at first.  Supply side partners were not in a position to force the issue, nor had the necessary research been done to support the idea.

Early days:
From the supply side’s perspective, as with many transaction systems, early efforts in RTB were focused on connecting the pipes.  RTB represented a new source of demand and the pressure was applied to getting plugged in to as many DSPs as possible.

On the demand side, there was resistance to the idea of sending multiple bids per impression because DSPs didn’t want to “second price” themselves – meaning that they didn’t want their second highest bid submitted, in a multi-bid response, to be used as the second price in the auction against their first bid.

Middle days:
In 2011 some supply side systems were supporting a multiple bid response.  Adoption on the part of the DSPs was very slow. Having a token DSP sending multiple bids per impression was the norm.

In 2012 some auction research was brought to light to point out the inefficiencies that single bid response brought.  DSPs who were reluctant to submit multiple bids were unknowingly (or knowingly) acting as bidding rings, which is known to be detrimental to an auction based market. See: Making RTB a More Efficient Marketplace for Both Sides.

Recent days:
DSPs are now adopting a multiple bid response, which is improving market liquidity.  Not every DSP is doing it.  Some may never do it.  Enough are sending in multiple bids to make a difference, though.  With added liquidity and upward pricing pressure, publishers are responding by bringing more and higher quality inventory into the RTB market.

Coming to a screen near you: Fewer Cookies

I wrote an earlier post call “In a world without cookies” which was my early response to the default setting in Apple’s Safari browser.  This issue has expanded, so I’m going to bring a little more light to the issue of privacy and privacy compliance in mobile, tablet and the desktop.

For the purposes of addressing privacy, the physicality of the device, whether it is a tablet, phone, or a desktop computer, can be mostly ignored.  The real technical distinctions with regard to privacy are between browsers and apps.  It’s also important to understand the need for advertising companies to maintain compliance with organizations like the NAI and initiatives like the OAB.  Together, the OAB and NAI dictate opt-out rules that online advertising companies must adhere to.

Block 3rd Party Cookies

Apple’s Safari browser has a default set to block third party cookies. Firefox will soon have a similar default setting.

The most prolific obstacle in privacy and compliance is probably a result of Apple’s move to disable 3rd party cookies by default in their Safari browser.  This is not just the Safari that ships on your iPad or iPhone, but all Safari browser installs, including that one on everyone’s beloved Windows machine.  Now, the team behind Mozilla’s Firefox browser has pledged to do the same.  Blocking by default causes two problems: advertising companies can’t do simple things like frequency cap using a cookie, and there’s no way to determine the user’s actual intent.  If the default setting was to allow 3rd party cookies, a user’s intent would be crystal clear if it was set to block.

The behavior of the 3rd party cookie blocking creates even more chaos.  If the setting is flipped to allow cookies, and an advertising company’s cookie is set during that time, even when 3rd party cookie blocking is turned back on the company’s cookie remains in the browser and remains totally functional.  A user would have to turn blocking on and then clear all their cookies to avoid this browser behavior.  This muddies the user intention waters even more.

The mess gets even messier.  In order to work around the 3rd party cookie setting, many mobile advertising companies are leveraging an HTML 5 technology called Local Storage.  This is a browser mechanism that works a lot like a cookie, but allows for a little more flexibility than blocked 3rd party cookies.  Frequency caps are, at least, being done with this mechanism in many cases.  Industry bodies like the NAI have not addressed this practice with an official policy.  For the time being, frequency capping has fallen into a gray area of privacy compliance which might be why this issue hasn’t been addressed yet.

The second obstacle is a little less obvious.  As advertisers and ad technologies move deeper and deeper into mobile and tablet apps, compliance and privacy has taken a back seat.  Apple shocked the ad world when it disabled device ID access to app advertisers, only to subsequently replace it with the ID For Advertisers (IDFA).  The only discernable difference is that the IDFA stored on a device can be reset.  iOS does not put this feature in the Privacy section of the settings, it’s buried deep in the About section.  That’s not even the main problem with device IDs or IDFAs.

The main problem is that advertising companies have no way to perform the compliance practices that they need to.  There’s no app for opting out of advertiser tracking.  Integrating an opt-out area into every ad would consume a lot of the already limited real estate on many mobile device ad sizes. Online privacy advocates and the online advertising industry have yet to vocally address compliance concerns in the app environment.

Do Not TrackFinally, the grand daddy of noise-making problems in privacy is not isolated to mobile devices and tablets.  It’s the initiative known as Do Not Track or DNT.  DNT is part of a proposed set of behaviors and browser settings that aim to encourage self-policing by the advertising industry and publishers until the legislation can be worked out to enforce it.  DNT starts as a setting in the web browser.  The browser includes the state of this setting (DNT on or off) in requests to a publisher web site.  It’s asking the publisher not to track the user when it’s turned on.  That means no cookies, maybe.  If you log in, it’s probably okay to get a cookie to keep you logged in.  If you click on an ad, maybe it’s okay to set a cookie there so the advertiser can properly attribute the click… maybe.

DNT is still just a proposal, but browsers are already showing up with the setting in their preferences.  Microsoft even set the default to be “on”!  Take that, Apple!  By and large, however, Microsoft’s web properties, including Bing, ignore the setting completely.

The best practice a publisher or advertiser can take is to adhere to the well-established criteria for online user privacy.  Consulting with levelheaded privacy experts is a good place to start.  The NAI has information to help users understand online privacy and the OAB website has information for web publishers, advertisers and agencies.

How do SSPs work with Google Ad Exchange?

I am not clear if SSP send a impression to a adexchange and get ad from it, and how it works? I know adexchange send a request to DSP then DSP send back response. But how SSP work with adx?
This question was asked on quora, below is my answer.

In its purest form an SSP would only send bid requests to DSPs. Google’s AdExchange actually behaves like an SSP in this regard. The AdExchange, however, does not behave like a DSP. It does not receive bids from SSPs, nor would it bid on them if it did. AdExchange receives inventory via a traditional ad request using an ad tag.

Online advertising has very few companies filling a single role, such as the role of SSP. Most SSPs are also in the yield optimization business. In cases where a yield optimization platform runs an impression through their SSP technology and doesn’t receive a bid that wins the impression, it’s possible that the impression may be sent to Google’s AdExchange via an ad tag redirect.

In some cases the publisher may even be responsible for such an occurrence. The publisher might have a pass-back tag set up with their SSP which, in the event that there’s no winning bid, redirects traffic back to the publishers adserver which, in turn, would redirect the impression to Google.

Google does have DSP technology, but it’s not AdEx. It acquired a DSP company called Invite Media in 2010.

Do DSPs provide advertisers with more data…

… than when purchasing through an ad exchange or even using an ad server? I am tasked with helping to expand my company’s online marketing, the options we are looking at are essentially 1) using an ad server to manage ‘private’ media buys 2) using an ad exchange like OpenX Market or 3) using a DSP. One major factor in this decision is the amount of data we can collect in order to optimise media buys.
This question was asked on Quora, below is my answer.

In the current marketplace a DSP is going to be able to give you more insight into your buys across many exchanges and SSPs. They are built from the ground up to cater to the needs of buyers.

You’ll want to find a DSP that can work with many SSP and exchange’s private marketplace technology stacks. You may even find yourself using an SSP’s interface to place orders with particular publishers. Those deals are likely to be executed through the SSP/DSP technologies, so you’ll still need your DSP to act as the buying agent once the deal is done.

Since data collection is one of your primary needs, you might consider using a 3rd party ad server if the DSP you’re working with doesn’t have one that suits you. You can use an ad server as a service or set aside some hardware and install one on your own.

Why does the average RTB win price jump up significantly at midnight EST?

…and do others see this jump at midnight in their own timezone?
This question was asked on Quora.com, below is my answer.

I dug into this problem several months ago after noticing the same jump in spend at that hour. Rubicon is on Pacific time so we refer to this as the “9 O’Clock Bump” effect.

Richter's Dodo

Dr. Richter pointing at a Dodo bird. “Adapt or perish”

After asking several DSPs about the problem we determined that it was, indeed, campaign budgets resetting combined with less-than-optimal pacing algorithms and in some cases lack thereof.

We’re in the process of finishing up some documentation on our pacing algorithm that does a pretty good job pacing to the needs of the campaign while considering the fairly predictable traffic pattern throughout the day. We’ll be putting this information out in the next couple weeks. Hopefully it will inspire some folks in the market to upgrade their systems and resolve some of this inefficiency. I’ll update post with a link to the document once we release it.

UPDATE: The document is finally out the door. You can read it here. (goes to the Rubicon Project tech blog)

Which are the main challenges in real-time bidding facing Demand Side Platforms (DSPs) today?

Is it the optimization of the bids, the allocation of budgets, managing potential conflicts between advertising campaigns from multiple customers and buying data? Or is it more related to other issues such as customer relations and getting ad networks out of competition?
This question was asked on Quora.com, below is my answer.

Mature Demand Site Platforms (DSPs) have conquered the primary requirements to being in business in the online ad space, including: campaign pacing, optimization of bids, campaign goals and budget allocations.  The old guard is now well established.  New DSPs, presumably with novel approaches to the market, may encounter some of these basic challenges.  There are a lot of examples they can look at in the market for guidance.

Ongoing challenges for all DSPs include things like the share of the customer’s budget.   Many advertisers are using more than one buying platform; whether those are multiple DSPs, ad networks, direct campaigns or other types technology platforms.  DSPs must present unique opportunities to customers.  This practice can lead to feature wars.  DSPs need to maintain parity with competitors and present novel offerings to customers to increase or even just maintain the budgets from those customers.

Even with the technology wars waging, DSPs must also maintain good relationships with their customers, even if they’re offering a self-service platform.  Sales and support go hand in hand in the online advertising world.  No one going after significant budgets gets a free pass.  Balancing the resources allocated to particular customers can be challenging in this business, like any other.  Conflicts between advertising campaigns, however, seem unlikely given the volume of inventory available on most platforms.  The human element can make adjustments if they arise.

Advertising Across Mobile Devices

This is the fourth in a series of posts walking readers through the mobile advertising space. Stay tuned for at least one more post in the coming weeks.

When evaluating advertising options on mobile devices, it is important to consider the screen size as well as whether the content is viewed in mobile web or a native mobile application. Content that is viewed in a browser is often suboptimal for advertising. When presented with a standard un-optimized web page the phone’s browser will shrink the content to fit the width of the display. This has the unfortunate side effect of also shrinking ads, often until they’re very small. In this scenario, advertisers are not getting their money’s worth, as their ads are often too small to see.

To successfully advertise on web pages displayed on a mobile phone a site’s layout must be mobile optimized. This single column of content optimized for a phone’s screen lends itself to an advertising unit that spans the screen unobstructed. While hardly anyone would think that these small banner units that span the screen are the answer to mobile advertising needs, this is at least a place to start.

In an attempt to expand the advertising opportunities on mobile, the IAB is working with advertisers and publishers to create new, more engaging ad units for mobile. These units have names like “Push” and “Slider”. They are initially inconspicuous on the page, but can take over the entire screen to create a more immersive experience. Adhesion banners stay in the same place on the screen, remaining in view throughout the user’s session. Creative thinking like this has led to ad units that expand to the limits of the screen of the device. Rather than being little boxes on the screen, these ad units use the full dimensions of the device to be more immersive and engaging.
Read the rest on the Rubicon Project blog.

What would be killer features for a brand-new SSP?

There are quite a few SSPs on the market. What product features would make a new one stand out? Or just name the most important features of an SSP solution, please.
This question was asked on Quora.com, below is my answer.

The primary customer of the SSP is the publisher. Most features are geared toward publisher needs. Access to demand is the paramount feature. Maximizing publisher yield over the long-term is also critically important. Companies that were already yield optimizers have taken the lead in the online display SSP space.

Additional features found in the top-shelf SSPs are reporting insights into the demand (i.e. who’s buying the inventory) as well as incorporating pricing intelligence into audience segments (i.e. what are my users worth). Armed with these two tools, a publisher is empowered to make more informed direct sales.

In fact, some SSPs are building utilities so support those direct sales efforts via the RTB protocol. This is being referred to in the industry as “programmatic trading” or “programmatic buying and selling”.

I think these are all stand out features of SSPs. Then there’s the one that doesn’t get mentioned too much: scale. Scale is probably the toughest challenge an SSP will face. Consider that a killer feature, as well.