The Future of In-App Header Bidding: A Hybrid Solution?

The following is a guest contributed post by Kevin McGowan, Vice President, Product Management, One by AOL.

Header bidding has supported major revenue increases for desktop-based digital publishers. By improving the sequential bid process, allowing advertisers to compete directly in a unified auction before ad server calls, it has dramatically raised CPMs.

But what about mobile? Smartphones continue to grow as the screen of choice for consumers, rivaling desktop media consumption year-over-year. And in-app experiences are driving that growth. Today, audiences spend more than three hours a day on their devices and 87 percent of that time in-app. In keeping pace with consumer demand, mobile app ad spend outpaces mobile web ad dollars three-to-one.

Mobile publishers also want to flatten the traditional waterfall and allow demand partners to compete at the same time for the same inventory. So, for app publishers to optimize spend and maximize yield, the benefits of desktop header bidding need to arrive in-app as well. Though in-app header bidding exists, it’s still in its infancy. The technology is evolving to meet the opportunity.

So, what does the future look like?

Server-to-server adoption will grow

As in-app header bidding takes off, it will meet many of the same challenges publishers encountered in the desktop environment, with latency being the biggest hurdle.

To date, most desktop header bidding solutions have been client-side configurations. They occur in the browser. As an end-user views a webpage, the browser temporarily downloads code, then processes it. While each new header bidding partner can increase yield, each partner requires new code – and today, 75 percent of publishers use at least five different header bidding partners. This introduces a lot of code complexity into the browser, slowing site load time and bogging down the end-user’s experience, often substantially. In response, more publishers are pushing header bidding programming to remote servers (server-side), managing multiple partners outside of the browser. This optimizes yield, without sacrificing site performance for users.

Expect similar changes for mobile. More header bidding partners means more client-side code representations – typically in the form of SDKs – integrated within an app. Already, many mobile publishers and developers rely on over 15 different SDKs. That number will only grow as in-app header bidding among mobile publishers increases. As with desktop, this creates a number of challenges. The more SDKs, the bigger an app’s file size, for example. In mobile, where there is battery drain, limited storage capacity and users pay for data to download apps, larger files are at a significant disadvantage, especially in developing markets. Mobile devices are also less powerful than desktop PCs, meaning a slower user experience with more header bidding SDKs added. As a result, more publishers are looking to limit the number of SDKs they rely on, while bringing in-app header bidding server-side.

But hybrid solutions are the future

Even with the industry’s shift to server-to-server, client-side header bidding solutions for mobile publishers aren’t going away anytime soon. Here’s why.

Today, many of the large advertising and monetization partners for publishers have not yet invested heavily in server-side capabilities for their demand platforms. Why? They simply do not feel that they need to put resources toward the change. Instead, they’re content with – at least for now – pushing developers to their SDKs, which already have impressive scale. As they see it, what they’ve been doing is working. And server-to-server is still in the early stages, with low adoption among publishers. These partners are using their leverage to limit demand access server-side. To unlock monetization opportunities with them, publishers must integrate with their SDK. As some of the biggest demand partners only offer client-side programming, it will be difficult for a wider range of mobile publishers to simply switch over to server-to-server solutions. More than likely, publishers will have to incorporate a variety of solutions in-app – both client-side and server-side – which unfortunately means more technical complexity.

It looks like the future of header bidding solutions will require a hybrid combination of server-to-server and client-side technology. This will give publishers the flexibility they need to unlock and unify all demand sources, regardless of technical requirements, while also making header bidding monetization much more efficient. With this technology, publishers can do as much as they can client-side and push partners to the server, while maintaining the ability to accommodate large players like Google and others. This kind of technology will also help to eliminate growing latency concerns among publishers given growing numbers of partner integrations. It will be a one-stop solution that can work with multiple demand platforms and their coding requirements.

As header bidding adoption among app publishers and developers grows, the technology will need to evolve to deliver true revenue yield without hurting the end-user experience or creating integration inefficiencies. Server-to-server’s emergence in-app is just a first step. In the future, expect the technology to advance further, with a hybrid server-to-server and client-side header bidding solution being the key to the industry’s progress.

The post The Future of In-App Header Bidding: A Hybrid Solution? appeared first on Mobile Marketing Watch.

#URLinkedUp Mobile Marketing Watch http://mobilemarketingwatch.com/future-app-header-bidding-hybrid-solution-72477/

#Mobiletech Check out URLinkedUp > http://www.urlinkedup.com

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s