A group of publishers is testing a header bidding solution from Rubicon Project that is compliant with Google’s Accelerated Mobile Pages program.
Tribune Publishing is among those who have implemented header bidding for AMP.
It’s the first time header bidding functionality has been leveraged in support of the “platform publishing” craze that has lately seen publishers export their content to places like Facebook Instant Articles and Google AMP.
“This [technology] will probably be disruptive, and companies and technologies that don’t keep up will fall behind if AMP is widely adopted,” said Rubicon Project CTO Neal Richter.
Rubicon Project has been working “in earnest” on its header bidding solution for Google AMP since mid-February, the company said. Rubicon built two modules, one with header bidding and one without. Plus, publishers using DFP as their ad server can already access Rubicon’s programmatic demand that way.
But they haven’t had a header bidding option until now.
That header bidding is available so early in Google AMP’s existence (the program’s training wheels only came off a few weeks ago) is notable. Google, it’s widely understood, is not a fan of header bidding since it diminishes the inherent advantage its DoubleClick Ad Exchange has with DoubleClick for Publishers customers.
There’s a fairly simple reason Rubicon succeeded in penetrating the Google fortress: AMP is a broader project with goals that go beyond just the DoubleClick team. A major reason for its existence is that Google search results load too slowly in mobile browsers, affecting that line of revenue.
But while AMP offers a great user experience, the ad experience isn’t quite the same. Those browsing the web using AMP may notice that content loads before the ads. That issue, which can affect viewability rates, exists because ads can’t be cached in AMP the way content is.
Because the ad experience is still being worked out, both in terms of monetization options and ad latency, publishers are moving cautiously with AMP.
“Publishers don’t necessarily want to roll out Google AMP if it can’t be monetized well. It’s a chicken-and-egg problem,” Richter said. “Having the content load, and then having the ads fit within the content, seems rational from a user experience [perspective], as long as the ads aren’t slowed down so much they lose their effectiveness.”
Google AMP is already making accommodations to publishers’ monetization needs. In order to prevent content jumping down below an ad once it loads, AMP wouldn’t allow publishers to accept multiple ad sizes for a single slot, a common tactic that allows publishers to accept whatever ad size will fetch the highest price.
However, Google AMP changed policy, deciding to allow publishers to enable “resizing,” as it’s called, for ads that aren’t immediately in view. Richter expects further developments within AMP, like the ability to trigger an ad only when a reader reads more content. Similar to lazy loading, it would improve the viewability (and thus effectiveness) of ads within AMP.
Theoretically, faster-loading mobile pages will lead to more content consumption, and more ad revenue for publishers. Rubicon Project hasn’t seen anything from its publishers yet to prove that point, but it’s behind Google AMP’s focus on speed.
“Delivering the fastest mobile experience is incredibly important,” said Rubicon VP of engineering Pieter de Zwart. “Google AMP dovetails with those efforts.”
