The impact of header bidding on desktop-based advertising has been well documented, giving an increased level of fairness within ad auctions which was not present under waterfall systems. However, a number of barriers, such as a lack of SDK development and poor adoption of first-price auctions, have until now prevented header bidding from being as effective a system on mobile environments.

Following on from vibrant discussion at ATS Singapore, Freddy Friedman, chief product officer at Smaato, discusses with ExchangeWire on why these barriers are no longer in place, thus allowing true in-app header bidding.

What has changed, or what technologies have been developed, to enable true in-app header bidding, rather than the compromise of mediated auctions?

I think it's an accumulation of a couple of points. I think the de-facto standards in the in-app industry of using prebid.org are a good benchmark for how in-app header bidding can work, and they have definitely helped to advance our industry. On that front, I think a lot of developments that have been done on the SDK-level have been to leverage a hybrid model in which the client-side, namely the SDK inside the app, is not handling the full header bidding flow but only pinging prices, caching, and rendering ads. This has eased the burden of integrating a true header bidding solution into apps. So that and the adoption rate of first-price auctions, which is a key prerequisite, accumulated to lead us into a phase where true in-app header bidding can make sense end-to-end.

Why are first-price auctions required for header bidding?

Freddy Friedman, chief product officer, Smaato

There is a very direct link between first-price auctions and header bidding. A lot of interested parties say "oh, we love header bidding, we want to do it on second price" or ask "can we do header bidding on second price?" Beyond the fact that first-price auctions are a part of the prebid.org de-facto standard, the main reason why first-price auctions are needed is that header bidding is about transparency. It's about full visibility end-to-end. With the first-price auction, there's no hiding. If you bid for a certain price and you win at that price, then the ad is served and you pay that price.

As soon as the entire industry adopts first-price auctions, then header bidding adoption will also increase and vice versa. First-price auctions allow more transparency, so buyers actually know what they are paying for. And, of course, suppliers can be confident that a larger chunk of the advertising budget would come to their pockets rather than going to the mediators in between. So again, we see header bidding and first-price auctions going very tightly hand-in-hand for these reasons.

What more should ad tech providers be doing to enhance bidding transparency, ensuring publishers are fully aware of bid prices on their inventory?

I think the first-price auction is critical for that element because on second-price auctions a lot of fees can be hidden between the supply and demand side. SPO (Supply Path Optimisation) mechanics, are taking centre stage more than ever before because of demand-side concerns about the cost of traffic and infrastructure, so this is something that ad tech providers definitely need to be working on. And of course from the supply side, mainly it's about new SDK integrations, which need to support first-price auctions, as well as viewability metrics like Open Measurement.

What lessons can be learned from the adoption of header bidding in desktop environments when introducing it to the mobile ecosystem?

The main logical rationale behind header bidding was to override the monopoly of some key, industry-wide primary ad servers, which were orchestrating the decision tree and the waterfall with their own demand, as well as some other affiliated or preferred demand. Header bidding was all about flattening that waterfall and allowing everyone at the table to have the same glimpse into the first impression at the same time. So copying this into in-app environments makes sense. Now I think header bidding on the web was adopted very quickly because, as its name suggests, the bidding is done on the actual header of the web page. This makes it very easy just to place a tag on a website and then run that.

However, if you look at how header bidding evolved on the web, I think we can see a couple of points of concern. If the same companies who were the primary ad servers are orchestrating in-app header bidding, they're not opening it up for other competition by allowing all demand sources to compete on the same level. This is why one of the key features of Smaato’s Unified Bidding is 'bring your own demand', which means that publishers utilising Smaato’s header bidding solution do not necessarily need to utilise our own marketplace as a sole source for header bidding demand. They can upload and integrate their own direct demand sources with their own contract and reconciliation so that they know for sure that open, transparent competition takes place. We hope that the other players in the in-app header bidding market will follow suit and do the same.

How can ad tech work with app developers and platforms to progress towards a unified auction model?

The best advice would be to benchmark a couple of solutions, trial them, POC them, see how they work, and how they respond. When there are data points and facts on the table to compare a couple of solutions, only then can you make a call on how to, in the live environment, roll out header bidding solutions. On paper, header bidding solutions look the same, but there are still a lot of differences. After running them in a live traffic environment, publishers will realise the differences and be able to identify which header bidding solution is more in line with their approach.

Each and every SDK has its pros and cons when it comes to the technical details, such as multiple bids, caching versus pre-rendering, and a lot of other considerations. This is why each and every publisher within the in-app domain which is eyeing header bidding should consider integrating into a couple of test apps, running some traffic, seeing how it really looks in a live setting, and then make a final decision.

How would the hypothetical removal of Apple’s IDFA, or further privacy restrictions, affect header bidding solutions, along with in-app advertising as a whole?

Right now, we see a very big trend, which I think is obvious to everyone in the market, that cookies and web identifiers are going to be fading away very quickly. I think that is a huge concern for the main players on the web and mobile web environment, namely buyers with the budgets to run on both the web and mobile web. But since Smaato is predominantly an in-app player, we do not see it as a threat but rather as an opportunity.

The identifiers currently running on Android or iOS are an essential part of the industry. They are transient, they are encryption-based, and there's nothing that could actually connect them to real life PII (Personally Identifiable Information). To be removed from that, there would still need to be some kind of a transient, coded, and encrypted identifier for apps or devices, so that more careful and accurate targeting could be made. But on the in-app front, what we see going on in the cookie-based web world is more an opportunity for us than a risk.

What is the future for header bidding in APAC and on a global level, is education still required for publishers to fully embrace header solutions?

There was a lot of interesting post-keynote discussions at ATS Singapore. A lot of publishers came in from all over the region and they were asking how they could test Smaato’s Unified Bidding — and how it really works within the in-app ecosystem. So it seems that there is a lot of room for education on what header bidding really is, how it can work with apps, and what the best solution is.

There definitely needs to be further adjustments, patience, and advancement with in-app header bidding. But given the number of publishers who have already lined up to join our Unified Bidding journey, it seems that it is a solution which is addressing a lot of APAC publisher concerns. We have very high hopes for our new product, as it will be addressing a lot of publisher needs and requirements. But education is definitely part of that route.