Checklist: Choosing the Right Header Bidding Container

It’s been said that for every problem, there’s a solution. While that’s hardly the case, it’s still a bedrock truism for those who make their living by way of invention. There’s a common belief held among tech workers that logistical hurdles can be surmounted by technological means, provided enough time and some A/B testing.

But what happens when the tables turn, or the technologies grow obsolete, or the market shifts, as so often it does? What happens when a technological “solution” that tens of thousands of people rely upon becomes, itself, a problem to overcome?

Such is the case with header bidding containers. Originally meant to give publishers a workaround for the challenges posed by “closed-system” ad servers – closed in the sense of both their pricing and functionality – header-bidding containers have become something of a problem themselves, lately.

 

Here’s how it should work: a header-bidding container or wrapper ought to provide a publisher with a way of implementing several header bidding solutions all at once, without having to painstakingly install each solution, one by one, and manage them as individual line items. What’s more, it ought to provide publishers with the same kinds of transparent pricing, ease of installation and freedom to choose whichever bidding partners they want to work with. That, after all, was the whole concept behind header bidding to begin with.

But there are many instances where that’s no longer the case. Taking advantage of the relative “newness” of header-bidding containers, a whole generation of point-solution header-bidding companies has sprouted up. By charging publishers fees that aren’t oftentimes fully disclosed; by operating containers that prevent publishers from seeing which ad exchanges and networks are competing for their inventory; and by requiring lots of hand holding and pricey “tech support” when the technology breaks down, these new companies present, pretty much, more of the same-old same old: What once was a means of enabling publishers has developed into a means of hobbling them.

And so we’re back at square one. Or are we, really?

For all the fog and mystery that surround “closed-system” header-bidding solutions, there are open-source header-bidding solutions, too. Running on open-source javascript like AppNexus’ own prebid.js, these types of solutions continue to “keep it real” and transparent when it comes to how they function.

Basically, it all boils down to this: Know your partner! Learn how your vendor’s container operates and how much it costs, if anything. Learn whether it has any further benefits to it, like the ability to forecast new inventory – or provide your company with 24-hour tech support service if things go wrong.

 

To spell it all out, here’s an easy checklist of the most important questions you ought to be asking your container partner:

 

  1. Do you know if they are charging you anything for the technology they provide? If so, they’d better have a good reason, since there are plenty of open-source header-bidding containers out on the market that are transparent about fees and additional costs related to the service – not the tech.
  2. Are they charging you a service fee – and if so, then for what services? If they’re any good at what they’re doing, they should be available and on call whenever you need them, since digital advertising – and the ad serving that comes along with it – never, ever sleeps.
  3. Is your partner bringing anything else to the table in terms of improving the yield of your container? Are they ready to run the extra mile and provide you with optimization strategies tailored for your business’s specific needs? And if not, then why not? Aren’t they supposed to be experts in their field?
  4. Is the script that their container runs open-sourced or proprietary? If it’s proprietary, then that might pose a problem for your business over the long run. Because there will eventually come the day when you’ll want to know how to fix bugs and/or make container updates yourself – and not have to rely on another party to help you. More importantly, you’d also lose everything if you ever leave your partnership since they own the solution, so you’re tied into staying with them. But if the script’s open-source, then odds are you’ll be better off, since the code your container runs on is readily available for all eyes to see.
  5. This one’s pretty important… Is your container giving you transparent access to whichever demand sources you’re looking to do business with? If they’re not, then that’s a big problem. Because that means they’re repeating the same issue header bidding was meant to fix in the first place: the issue of transparency. If they’re not giving you access to whom you’re working with, how will you even know the true value of your inventory? How are they behaving any better than, well,
  6. How tricky is it to set the container up and s your tech vendor willing to go out of their way to walk you through the implementation process – or even implement your container for you – or are they willing to sit back and let you try and puzzle it all out, yourself? Not that it’s necessarily a bad thing for you to learn how to implement and update the container script that powers your business – but sometimes an extra hand or bit of advice can save the day – not to mention save you many dollars in yield.

 

To learn more how AppNexus header-bidding solutions can help your business grow incremental yield, feel free to contact us anytime! Meanwhile, we hope this primer was useful!

 

For more information regarding choosing the right header bidding solution, download the full whitepaper here.


Tagged | comments (0)

Infographic: Three Header Bidding Myths, Debunked

If you’re a publisher, then you’ve probably heard plenty about header bidding by now. But just in case, here’s a quick recap on why it’s become one of the most popular supply-side tools.

Under the traditional waterfall system of ad serving, every new impression is auctioned off to one ad exchange at a time – priority is determined by how much each exchange has paid historically. It’s not a truly open auction, and it lowers monetization by forcing publishers to accept lower bids.

With a few lines of Javascript, header bidding enables publishers to ditch the waterfall, hold auctions on all of its exchanges at the same time, and get the highest possible price – the true, marketplace value – for every impression.

But there are some misconceptions floating around, holding publishers back from adopting header bidding. In this post, we’re going to lay out three of the biggest header bidding myths and explain the facts behind each one.

 

Myth 1: Header bidding means latency

Some publishers worry that auctioning off impressions to all those demand sources at once will cause latency on their web pages. It’s a legitimate concern – nothing hurts user experience like long load times.

Reality: Header bidding done right doesn’t affect load times

It’s true that some publishers have seen their load times go up after implementing header bidding. But those who have chosen the right header bidding code and implemented it correctly aren’t having those problems.

So what does header bidding done right look like?

For one thing, you’re going to want to make sure you’re efficiently integrating with all of your demand sources. That’s where a header bidding container, or wrapper, comes in. Rather than adding javascript for every single exchange you work with, using a container lets you connect your site to multiple exchanges with a single, manageable piece of code.

You also need to make sure holding asynchronous auctions rather than synchronous ones. The difference is a lot bigger than one letter. The tech behind it is somewhat complex, but basically, if you’re holding synchronous auctions, the highest bids are fetched from each exchange one at a time. But with asynchronous options, all bids come in at the same time, which – you guessed it – reduces latency.

 

Myth 2: Header bidding puts publishers’ data at risk

Publishers are also concerned that header bidding increases the risk of data leakage. Under the traditional programmatic system, the bidding and decision-making process around which ad to serve takes place on the publisher’s own ad server. But with header bidding, publishers send the user data behind each impression – age, location, last site visited, etc. – directly to the demand sources. It feels like they’re putting that data at risk.

Reality: With the right partners, header bidding is no riskier than any other auction

Publishers are right to worry about data leakage if they’re using one of the proprietary, “black box” header bidding solutions offered by many providers. After all, how can your developers find and fix vulnerabilities if they can’t even look at the code?

But with an open source solution like Prebid.js (developed by AppNexus but free and open to all), that’s not a concern. Your developers can get under the hood and make sure the code is optimized for the safe transmission of data – as well as your unique commercial needs. As Linux inventor and father of open source technology Linus Torvalds said, “Given enough eyeballs, all bugs are shallow.” The same goes for data vulnerabilities.

Choosing the right partners also comes down to the exchanges and RTB platforms you work with. Your data is probably safe if you’re working with reputable demand sources who care about user privacy.

Myth 3: Header bidding platforms are biased toward proprietary demand sources

Lots of publishers also believe that whatever header bidding solution they choose will favor bids from ad exchanges also owned by that same provider.

Reality: Demand agnostic platforms put every bidder on an even playing field

Biased auctions have been a concern of publishers’ since programmatic advertising first came on the scene more than a decade ago. But the top publisher platforms have built their reputations on being demand agnostic, proving time and time again that they can run auctions without favoring their own demand platforms.

This is also an issue that open source header bidding solutions solve. Again, if your developers have the ability to edit the code, they can make sure that the auction’s decision logic treats all bids equally.

Want to learn more about header bidding technology? Download our white paper here.


Tagged , | comments (0)

Real-Time Real-Talk: Server-to-Server Header Bidding

20400_ATG_Real-Time_Op-Ed_Banner_V2-01

“Real-Time Real Talk” is an ongoing blog series that seeks to clarify the “what”, “why”, and “how” behind ad-tech innovations.

In 2016, few topics of conversation generated more buzz in the ad-tech world than the one surrounding header bidding. In 12 months, the publisher monetization tool went from relative obscurity to a popular solution that everyone in our industry was expected to understand.

Alas, just when you think you’ve finally learned enough about a new technology to discuss it confidently, ad-tech delivers yet another innovation to wrap your head around. In this case, the latest phrase on everyone’s lips is “server-to-server header bidding,” a tool some people believe could be the future of sell-side technology.

Ready to learn more? You’ve come to the right place.

Okay, so what is “server-to-server” header bidding?

Server-to-server header bidding is a technical fix that allows publishers to include a greater number of demand partners in their header bidding auctions — without damaging the user experience. Like traditional, “client-side” header bidding, server-to-server tools help publishers sell their inventory to the highest bidder by allowing multiple ad exchanges to bid on an impression simultaneously. The difference between server-to-server and client-side setups lies in where the header bidding auction takes place.

As you might recall, the client-side auction happens in the header of a publisher’s web page. In order to execute the auction, publishers send ad calls back and forth between the user’s browser window and each of the participating demand partners. As a result, the publisher creates an additional burden on the user’s browser with every new partner it adds to the client-side auction. The problem with this is that browsers weren’t designed to make so many simultaneous calls, so the extra burden in contacting so many demand partners slows down how quickly the web page loads for the users. If a publisher includes more than six or seven exchanges in its client-side header bidding setup, the auction will drive readers away with long load times and a terrible user experience.

In a server-to-server setup, the publisher page sends a single ad call to a high-powered server created by a third-party technology vendor. From there, the server calls all the different exchange partners itself, taking the load off the user’s browser. With the right technology partner, publishers can add up to 200 exchanges to the auction without increasing latency.

So it’s basically a better version of regular header bidding?

Well, not quite. Server-to-server header bidding is far from perfect, and its flaws might prevent it from ever achieving the popularity that today’s client-side tools enjoy.

The biggest issue is that server-to-server header bidding decreases publishers’ cookie match rate. Since client-side publishers communicate directly with their exchange partners, they’re able to match cookies for just about every user they see, allowing advertisers to identify the human beings they’re paying to reach. But since server-side integrations put an intermediary in the middle, this cookie match rate falls to around 70%. And because cookie-less impressions are basically worthless to advertisers, publishers who adopt server-to-server setups risk seeing a decrease in both the number of bids they receive and the CPMs advertisers are willing to pay.

In addition, server-to-server header bidding is much less transparent than its client-side counterpart. In client-side header bidding, publishers have complete insight into their auction mechanics, since the ad calls are made by a piece of open-source javascript inside the header of their own webpages. But in a server-to-server integration, all of this takes place inside a black box owned by a third party. Without the transparency of the client-side, publishers have no way of knowing whether their technology vendors are taking an unfair cut of their ad revenues or prioritizing certain demand sources over others.

Wait, so all this fuss is over something that might not even be as good as what we had before?

Truthfully, the jury is still out. With the exception of Amazon, the only companies offering server-to-server header bidding right now are smaller players working with experimental publishers. Over the next 6-12 months, publishers will have to decide for themselves whether server-to-server is worth implementing, as well as how many demand partners it makes sense to move from the client-side auction. And each publisher business is different. Server-to-server logic has been around for a while.  Depending on a publisher’s business needs, some prefer client-side solutions, while others prefer server-side solutions.  For example, mobile publishers are often quick adopters of server-side technologies since they often reduce the number of Software Development Kits (SDKs) to implement and internet bandwidth is more important on a mobile device

While it’s early days for server-to-server header bidding, one thing is for sure: we at AppNexus are committed to staying ahead of the market with our header bidding solutions, and educating our customers on all of the latest developments in monetization technology. We’ll be following this trend closely throughout the year, reporting back to you whenever we’ve learned something new. And if you’d like more information about server-to-server right now, please don’t hesitate to reach out to your AppNexus representative.


Tagged | Comments Off on Real-Time Real-Talk: Server-to-Server Header Bidding

AppNexus Calls on President and Congress to Reverse New Immigration Policy

Earlier today, the United States government began disallowing citizens of seven countries – Syria, Iraq, Iran, Libya, Somalia, Sudan, and Yemen – from entering or re-entering the U.S.
 
Though there remains a great deal of uncertainty about the breadth and details of this new policy, reports suggest that the ban may apply to permanent residents holding valid green cards and to non-American citizens who hold dual citizenship in one of the prohibited countries (e.g., a dual citizen of France and Iran).
 
AppNexus strongly opposes this new policy. We respectfully ask that President Trump reverse this measure and that Congress work with him to do so.
 
The policy is ethically offensive and potentially disruptive to global businesses like AppNexus. It violates the open spirit and inclusive ethos of our company. And I personally believe that it betrays the fair-minded and generous values that most Americans share.
 
This is a matter that transcends partisan politics. It is about holding true to our core values. We hope that the president and Congress will work for a swift resolution.

Comments Off on AppNexus Calls on President and Congress to Reverse New Immigration Policy

In support of Governor Cuomo’s agenda to invest in Computer Science education and grow New York’s tech workforce

The advent of the tech economy has fundamentally shaped the democratic world. We have today, literally at our fingertips, more access to conversation and information than ever before. There is massive potential in this unprecedented interconnectivity: to provide social services, prepare for emergencies, improve infrastructure and grow industry.

Our mandate now is to properly equip our children and communities to participate in the digital economy. The last few months have starkly elucidated the insecurity felt by much of the country’s workforce, as technology advances at a rapid pace, but national technical knowledge and skills lag behind.

This month, New York’s Governor Andrew Cuomo, in his State of the State address, doubled down on his commitment to growing New York’s digital workforce and advancing the tech industry, ensuring the state’s businesses and workers thrive in a competitive 21st century economy.

The Governor has laid out a comprehensive plan to modernize K-12 education, college curricula, the workforce and economic development initiatives. An investment in K-12 education includes ten new Early College High Schools with pathways to tech jobs, offers professional training and mentorship for Computer Science teachers and expands the teaching of Computer Science in schools. The creation of a Tech Workforce Training Fund will equip New Yorkers for jobs in lucrative and fulfilling technical occupations like data science and software engineering across the state.

These initiatives resound personally with us at AppNexus. New York City has been our gracious host and supportive incubator as we have developed and thrived over the last nine years. The palpable vitality of the city – far removed from the digitally-saturated, often vacuously-inventive West Coast – has inspired us in so many ways to identify shortcomings in our market landscape and community and seek solutions which powerfully and ethically advance the internet and the economy.

One of AppNexus’ values is to “see and improve the whole system,” and New York presents economic, political and social challenges – both endemic to the state and pertinent to the nation – that can be addressed and mended with technology. In partnership with Mayor Bill de Blasio, AppNexus takes an active role in building a diverse and robust tech workforce in New York City. Among other on-going commitments with the city, we are a founding member of the NYC Tech Talent Pipeline Advisory Board, comprised of 27 CEOs, CTOs, CIOs, and senior executives, dedicated to defining employer needs and developing and testing training and education solutions to meet the skills gap.

Bolstered by the support of Governor Cuomo and Mayor de Blasio, New York is not just an exciting place to be… it is the place to be in tech right now. The Governor’s announced investments herald real evolution of the state’s economy, and we look forward to lending our support to his administration as it rolls out these initiatives.

Comments Off on In support of Governor Cuomo’s agenda to invest in Computer Science education and grow New York’s tech workforce