As app developers juggle an ever-increasing list of considerations — such as the user experience, revenue goals, multiple types of demand sources, and more — the importance of reliable and flexible mediation tech is more important than ever.  

 Originally, ad mediation emerged to help publishers optimize their revenue more effectively, but the first generation of mediation often left monetization teams with more questions than answers.

As the tech has advanced and publisher needs have become more complex, let’s revisit mediation: how it works, why it’s important, and what publishers should look for. Let’s dive in. 

How Mediation Works 

At its core, ad mediation seeks to optimize ad revenue. At its best, mediation finds the best result for all sides of the advertising ecosystem: the publisher, the advertiser, and the end user. It does this by assessing in real-time which ad opportunity among a set of demand sources will yield the best result at that moment for that user. This drives higher eCPMs for the publisher, more relevant and enjoyable ads for the user, and better campaign performance for the advertiser. 

Open and unbiased auctions put the publisher in the driver’s seat, providing them with the controls and transparency required to optimize across waterfalls, ad lines, and various demand sources

This optimization is managed by an auction process, which can vary from one mediation platform to another. Among these, open and unbiased auctions put the publisher in the driver’s seat, providing them with the controls and transparency required to optimize across waterfalls, ad lines, and various demand sources.  

Further optimization is achieved when the ad mediation platform provides robust tools with options for creating user cohorts, placement settings, and demand integrations.

These mechanisms empower monetization teams to choose the users who will view different types of ads, when, and from which ad partners. In so doing, apps can optimize average revenue per daily active user (ARPDAU) while minimizing churn or cannibalization.  

Why Mediation Is Important 

Ad mediation can deliver optimal ad revenue for app publishers while respecting all other publisher KPIs and commitments. Moreover, it can do this while saving monetization teams countless hours each week, allowing them to focus on more meaningful projects. 

Mediation offers a more dynamic approach to optimization for publishers still reliant on ad monetization waterfalls.

Depending on the mediation solution chosen —, this can work across all demand source types, creating a more competitive, and thus more lucrative, revenue ecosystem for the app. As more publishers begin to spin up their ad sales teams, the ability for demand diversity in ad mediation is more important than ever.

When mediation systems are transparent, flexible, and neutral, app publishers can truly maximize ad revenue. 

For publishers concerned about cannibalizing their users — particularly those with the highest lifetime value (LTV) — the user segmentation options within mediation tools can provide a powerful and much-needed degree of control. By dynamically cohorting users based on parameters set at the mediation layer, monetization teams can automatically optimize advertising ARPDAU without exposing high-value users to competitors’ ads. 

App publishers can maximize ad revenue when mediation systems are transparent, flexible, and neutral.

What Publishers Need 

Ad mediation is best when it empowers the app publisher and values the user experience at its core. To this end, publishers must seek several key elements from their mediation tech solution, whether they build it themselves, rely on a third-party managed solution, or leverage a customizable mediation-as-a-service solution (like InMobi’s Meson). 

First, publishers need absolute transparency in the mediation process. No auction dynamics should be obfuscated, and pricing must be upfront and clear. This allows the monetization team to make informed decisions on monetization settings and fairly assess business costs with each partner.

Moreover, without transparency, publishers cannot verify that the mediation tech is working in the publishers best interest. Thus, it’s no surprise that in a recent Advertising Perceptions study, the lack of transparency offered by many mediation companies was a top concern for 22% of publishers. 

Second, publishers need unmitigated control. Every app is unique, and maximizing monetization for many user types requires granular control mechanisms.

Indeed, 76% of publishers report that they would rather pay for greater control over their mediation than rely on a free tool with limited options. In this pursuit, publishers should ensure that their mediation solution allows for user segmentation based on user behavior, context, demographics, and other custom parameters. 

Third, publishers need flexibility. Demand sources and preferences vary by app, and mediation solutions must be able to accommodate them. To this end, publishers should verify that their mediation tech allows them to choose which demand partners and third-party vendors they work with.

While some vendors may have native integrations with the mediation tech, it’s equally important that the publisher create their own adapters and connect any other demand source of their choice. 

What’s Next in Mediation 

To attain the control, flexibility, and transparency needed for ad monetization, many publishers are revisiting their approach to mediation. Indeed, during a recent webinar on the future of monetization, predictions emphasized the importance of ad relevance, publisher control, and building trust with ad tech vendors.    

This aligns with a recent Advertiser Perceptions study of over 100 top mobile publishers, wherein a majority of publishers (55%) expressed concern about the lack of control provided by their current mediation solution, and half (50%) were frustrated by an overall lack of transparency. 

 Given the complexity of building mediation from scratch and the need for transparency and control, we expect to see the rise of mediation-as-a-service solutions like Meson. Indeed, among publishers without their own mediation platform, 73% would prefer to manage their mediation in-house, provided an outside tech company handled the infrastructure.  

No matter how monetization teams  integrate ad meditation into their tech stack, one thing is sure: publishers can make growth happen in 2023 if they allow transparency, flexibility, and control to empower them.

The post What App Publishers Need to Know About Mediation appeared first on AdMonsters.

At the end of 2015, we were still having a lot of conversations about what header bidding is, how it works and who it’s good for. Meanwhile, publishers were scrambling to douse the fires of ad blocking and viewability. A year later, many publishers have come to a sort of detante with ad blockers (and some have noted the adoption of ad blocking software hasn’t spread quite as widely as they’d feared), the viewability discussion has reached a standstill, and header bidding has noticeably re-arranged the lay of the land throughout the industry. For a period, AdMonsters couldn’t stop publishing articles about header bidding, and that’s because you in the audience couldn’t stop talking about header bidding. And all of that talk drove results–the industry is in a pretty different place, and it’s conferred some quantifiable revenue advantages to publishers.

In the spirit of that reflective end-of-the-year impulse, we’re taking a moment to highlight some of the most comprehensive and informative articles AdMonsters has published in 2016. Not coincidentally, many of these are also among our most-read articles of the year. Here’s a guide to help remember how we got this point, and we’ll catch you again in 2017.

Rethinking the Ad Server: At some point this year, one industry insider told AdMonsters that the continuing evolution of header bidding would bring “the death of the ad server.” That sounds heavy, but this article points out the ad server’s role right now is quite different from what it was a few years ago. If a header integration allows an SSP or other entity to become essentially a mediation platform for demand, does that make the mediation platform an ad server? Is the designated ad server done for, if header bidding and server-to-server connections allow so many players to act as mediation platforms? In this piece, we have a quick summary of the development of header bidding thus far, plus a rumination on what the next generation ad server might look like. Maybe the ad server itself isn’t on the way out, but the closed ad server model has to be.

The Server-to-Server Way: One of the juiciest developments of 2016 was the wider adoption of using server-to-server connections to manage demand. We’d been hearing a ton of questions about what the next step in header bidding was going to be, and S2S is one of the clearest answers so far. That said, in this interview, Tony Katsur, President of Sonobi, explains that S2S is not actually “header bidding,” because it doesn’t rely on the page header. The promise of S2S is faster page load time, more data brought into the transaction, and efficient management of more demand sources. But there are obstacles: Not all tech vendors can support S2S right out of the gate, various partners need to be able to trust each other, and there are some types of demand that might be better managed in the header. That said, this interview makes the case that S2S is, overall, the solution publishers had been hoping for back when they started doing header integrations.

Unwrapping Wrappers: A Conversation on Header Bidding with Index Exchange: As header bidding went mainstream, a lot of pubs realized they didn’t have the internal resources to handle quite as many demand sources as they wanted. Accordingly, the industry saw a flurry of header wrappers (or containers, or frameworks, depending on your terminology of choice) hit the marketplace. Each individual header integration requires additional dev work, but with a wrapper, the pub needs to handle just that one integration, and the wrapper provider plugs demand sources in as the pub wishes. But wrapper functionality isn’t uniform–there are wrappers as mediation platforms, there are open-source wrappers, and wrapper integration differs from one publisher ad stack to another. In this interview, Index’s Steve Sullivan and Jourdain Casale talk about the pretty complicated things wrapper providers have to do in order to take that integration work off of pubs’ shoulders.

One Order to Rule Them All: Inside Gannett’s Massive Workflow Centralization Mission: When we caught up with Gannett’s team around the beginning of this year, the huge and complex media company was in the midst of standardizing and centralizing sales and workflow across 92 properties, going on 106. Gannett has been spending years on making these processes more efficient–a decade ago, it acted more like a holding company, with a whole spectrum of disparate owned and operated sites. Now, they have a single-entry system and a standardized rate card (adjusted slightly per the idiosyncrasies of certain markets). This interview is a wide-ranging discussion of the technical, cultural and market challenges of making this workflow centralization happen, and of how it’s affected Gannett’s business.

All or Nothing: The Ramifications of GroupM’s Quest for 100% Viewability: GroupM has been insisting for a couple years that it’ll only pay for viewable ad impressions, and by the end of 2016, publishers and industry advisory groups are still insisting a 100% viewability standard is simply not possible. GroupM and some other big-time buyers have the clout to put their foot down. Other buyers don’t. There are a lot of incongruities publishers need to negotiate here. In this piece, Will Rand argues that as complicated as managing campaigns is with the spectre of viewability in the picture, pubs are going to have to play ball, and to work with buyers and third parties to measure and improve viewability. And by rewarding publishers who provide viewable inventory and pushing accountability across the board, that sticky “100% viewable” figure might ultimately be a positive development for everyone.

Programmatic Video in Bloom: Talking VPAID, VAST 4.0 and More With VertaMedia’s Alex Volker:  Programmatic video continued to blow up throughout 2016, and the more complicated ramifications of buyers’ appetite for it became clearer as the year progressed. This interview covers a lot of ground, in terms of publishers’ concerns with programmatic video–VPAID errors and what might be done to mitigate them, the promise of VAST 4.0, the viability selling video inventory of the open marketplace, and growth in connected TV and mobile (with all that growth entails).

Gotta Stay On the Page: Index’s Alex Gardner Opens Up on Header and Server-to-Server Integrations: There’s been a ton of chatter this year about how server-to-server integrations might be the answer to the question of what to do about latency, the scourge of header bidding. But not everyone is eager to board the S2S train–in this interview, Alex Gardner explains the value in staying on the page with a header integration, how the header tag provides a view of demand that he says S2S doesn’t. There’s also been a lot of chatter about what Google’s launch of exchange bidding in Dynamic Allocation will do to the header bidding landscape. According to Alex, whatever Google ends up doing with that offering, it doesn’t spell the end of header bidding. As a companion piece, check out Gavin Dunaway’s intro to exchange bidding, Header Bidding Is Not Dead… Yet, where he determines that if header bidding is a party for managing demand, Google’s arrival is no reason to kick out the guests yet.

Bidding Without a Header: OpenX Explains Their Take on In-App Bidding: After seeing what header bidding did for their revenues in traditional web display, publishers began looking ravenously at the in-app and video spaces. And it took a while, but vendors started rolling out solutions in both of those realms this year. Apps presented an interesting challenge, because there’s no page header in-app. Instead, demand is managed via SDK and API solutions. OpenX was one of the first vendors to market with an in-app bidding offering, and in this interview, Justin Re and Maggie Mesa from their team explained just how different in-app bidding is from web-based header bidding, and why different scenarios on the publisher’s end might call for different strategies. (Oh, and as for header video–that’s complicated, too, in its own way, in no small part because the page and the video player are separate entities. Jourdain Casale spoke again with Gavin Dunaway to explain those challenges.) 

The Dawn of Real-Time Guaranteed: An Interview With OpenX’s Dmitri Kazanski: Real-time guaranteed offers, in theory, a best-of-both-worlds scenario: guaranteed display buys transacted in a real-time buying environment. While there’s been some talk for a little while about the potential of RTG, there’s also been some uncertainty about how to make it work at scale. However, the scale issue might be changing, as RTG solutions start to hit the marketplace. In this interview, we get into how RTG resolves some of the most annoying problems publishers have right now with private marketplaces, to the extent that RTG could stand to replace private marketplaces as we know them.

AdMonsters Playbook: User Experience:  AdMonsters has written at length in the past about how ad ops are the gatekeepers of advertising for digital publishers, but minding the gates has become incredibly complicated. Publishers are trying all sorts of new and unfamiliar strategies to monetize, with risks from malware and undesirable ad creative seemingly around every corner. Meanwhile, users are increasingly averse to bad ad experiences. These concerns have led ops teams to work closely with sales, IT and legal, and in essence it makes UX  more and more of a day-to-day concern. To that end, it was time for AdMonsters to develop a user experience playbook. In it, we explore a wide range of issues ops teams now have to address in their expanding role within publisher orgs.

The post Best of AdMonsters 2016 appeared first on AdMonsters.

Some of these new implementations push the limits of what we’d normally consider header bidding, per se—server-to-server implementations, header for video, bidding for apps. In the app, there isn’t even a header.

But of course, major industry players wouldn’t let something so trivial as the absence of a page header get in the way of applying the header bidding concept to the booming app space. In-app bidding is a thing now. But at this early stage, there’s no industry consensus about the “right” way to do in-app bidding, and publishers need answers to a lot of questions about what sort of strategy they should take, and why.

AdMonsters Staff Writer Brian LaRue called up OpenX’s Director of Product Management, Justin Re, and the company’s VP of Business Development, Maggie Mesa, for a full introductory briefing. Justin and Maggie explained how in-app bidding differs from header bidding in a web browser environment, what resources publishers need to get started, what goes into different implementations, and how the practice dovetails with what publishers may already be doing.

BRIAN LaRUE: How does in-app bidding work, particularly compared to web-based header bidding?

JUSTIN RE: While there is no header in-app, the concept is ultimately the same as the technology powering header bidding on desktop. A key difference is that there are currently two ways to approach the in app implementation.

The first relies on a full SDK that is implemented along side a publisher’s primary monetization SDK. It takes complete control of the impression by intercepting the initial request, sending it out to the exchange or server-side mediation, returning the price as a key value into the primary SDK and finally rendering the ad-view if the bidder is successful. The second approach, considered a lighter more flexible version, involves code that sits directly inside a publisher’s primary SDK that is controlled via an API. That code fires off a request to the mediation partner or exchange and they send back a price as a key value in the same way as the other implementation.

The main difference between the two relates to control. With the lighter implementation a publisher can control all aspects of the bidder via an API. For example, they have control over when the exchange is called and how the ad is eventually rendered. As a result of having control over when the exchange is called, they also have control over how they cache the response.

So far we’ve seen a strong gravitation towards what we consider a lighter implementation. Importantly, both options deliver publishers the desired benefits of header bidding — increased competition and more revenue.

BRIAN: What are the benefits of either implementation, and what kind of publishers do you see reaching for each?

JUSTIN: A publisher’s level of sophistication is largely responsible for the divide between adoption of the different implementation types. At OpenX we work directly with our publisher partners to find the best fit for them. Even though each type of implementation can benefit publishers, as the technology becomes more widely adopted we expect more publishers to benefit from the lighter implementation.

Because MoPub’s SDK is open source, a lot of the larger, more sophisticated publishers have already customized their own versions of it and are, in turn, more comfortable incorporating the lighter implementation into their existing SDK. Emerging publishers often don’t have the insight, engineering resources, or comfort level to do that.

MAGGIE: To that point, the decision to go with one method of implementation over another depends on several other factors beyond size. Ultimately, publishers are interested in maximizing competition on an ad request or impression-level basis, but there is still a need to validate “header bidding” technology as a big market on the mobile side like we’ve done with desktop.

Mobile publishers are eager to test new partners and ideas, however they must also be sensitive to the size of their app. There are certain SDKs they have to work with, for tracking, attribution, a variety of things, and they have to balance those needs with new partnerships. This is where having a lighter version benefits publishers, it provides a way to introduce another partner without adding too much weight to the app.

Publishers that choose to adopt the out-of-the-box SDK, or standard implementation, are usually more focused on the content and less focused around the monetization effort. Alternately, the lion’s share of larger apps we work with have a very robust and mature strategy around mobile in-app monetization. When MoPub launched, they didn’t have support for some formats like rewarded video and native that a lot of publishers were already utilizing in their monetization strategies. Those publishers were already tweaking MoPub’s SDK for reasons outside of header bidder graphs.

BRIAN: On the publisher side, how is the integration different from a web-based header integration?

MAGGIE: Learnings from desktop helped speed up the integration process in-app, with the understanding that it is going to be slightly different on mobile. I’ve been selling mobile SDKs for so long that it’s kind of a running joke: “Integrate our SDK with three easy steps.” But that’s really more set around the primary SDK. Pieces of code that get added to specific libraries aren’t a full-blown SDK. Our solution is an adapter.

JUSTIN: At the start of integration, publishers receive a one-page integration doc and a package of code, and access to the bidder manager API. They also benefit from OpenX’s automation script that helps them create all the new line items required for each price bucket. With up to 90 of these recommended, this can save them a ton of time. Publisher’s can get up and running and testing within a couple of hours.

It’s also important to keep in mind that if you’re adding anything into the app, an app store update is required. So, most of the time it isn’t about how long it takes to integrate the code, rather it is about fitting into the app developers’ version life cycle. Code can be sitting inside a number of apps for months waiting for that new version to go up.

MAGGIE: I actually know folks on iOS that update only once a year. From a pure integration standpoint, that is different for mobile in-app versus desktop.

BRIAN: How might in-app bidding help sellers manage varied demand sources and all the different ad formats in the app space?

MAGGIE: The rise of this kind of technology is a reflection of where the mobile ecosystem is going in general. Four years ago, 99.9% if not 100% of the demand flowing through the mobile programmatic marketplace came from app install campaigns from gaming advertisers, or oftentimes the publisher’s competition. As the market matured, players like Uber and Lyft, travel and leisure apps like HotelTonight and Expedia, emerged. Now amazing new verticals, like fantasy sports, and shopping apps such as Wish, are being really aggressive with their programmatic strategies.

Publishers are asking: How do we access brand demand, gaming demand, rewardable video, native, plus inventory we wouldn’t see from existing SDK partners? Gaining access to differentiated demand without having to integrate a full-stack SDK with multiple libraries, complements their existing strategy without adding a lot of weight to their app. This is one area where working with players like OpenX, who have existing relationships with several of the leading brand advertisers, can add incremental value.

BRIAN: That said, is it possible to leverage a wrapper in-app the way that publishers are doing with web?

JUSTIN: Yes, but there’s one main difference: Publishers have been creating their own containers in mobile app for a really long time. An app monetization SDK’s job is to manage multiple mediation partners. A lot of the sophisticated app publishers have already had the ability to call multiple different server-side partners and have them bid into their mediation stacks—so they’ve inherently created their own containers, they’re just not necessarily containers for bidders.

A container concept within the bidder-specific side of mediation in-app is probably going to happen. But it’s probably not going to be productized in the same way that it has been in desktop. Our bidder API is technically a wrapper, except it only controls our bidder for the moment. Eventually as the market matures we will likely add the ability for our Bidder API to manager other bidders as well.

BRIAN: I’m curious what you’ve been hearing from publishers about latency.

JUSTIN: We haven’t heard about any concerns at all—almost to the contrary. Latency concerns have been taken right out of the conversation in mobile by pre-loading or pre-caching ads. Every time the SDK needs a new ad, there is already one ready to go and in the chamber, so to speak, for that next call as it comes up. The publisher has complete control over the timing of this via the Bidder API.

Initiatives to create a better, faster experience for the user, like what we’ve seen so far with AMP, will potentially lead to more innovation on the desktop side. Google AMP allows Google to deliver pages at super speed, because they’ve cached the whole page upfront in their CDM. They load the content first and the ad second, which is where the whole Internet is eventually going to go. And they’ve now just released AMP for Ads, which pre-caches an ad inside AMP pages. I think that tech will become standard long-term.

The post Bidding Without a Header: OpenX Explains Their Take on In-App Bidding appeared first on AdMonsters.