Header bidding today is built as a “hack” for Google’s DFP ad server with 100s or thousands of line Items housed in DFP and activated once a winning bid is sent to DFP from the buyer of a publishers page. EBDA is the much awaited reaction from Google as a way to allow publishers to switch on their favorite SSPs and exchanges at once within AdX to compete in real time towards Google’s demand. According to AdAge: “Although header bidding has seen huge adoption by publishers, but it surely, it still consists of the attractiveness of a hacky workaround to DoubleClick. That modified last week after Facebook backed the tech, saying it should work with Index Exchange, Sonobi, Amazon, AppNexus, Sortable and Media. net to bring demand from its Audience Network to publishers using header bidding.
” In header bidding, A writer commonly will work with anyplace from 3 15 header companions with 3 5 client side and another 3 5 server side S2S. Most publishers use some sort of prebid. js, the most regular open source header bidding wrapper with over 70 demand associate adapters. With EBDA, a writer can simply activate partners server side who’re built-in into the platform to bid on their stock along of Google AdX Google’s DemandMajor ad exchanges who work with publishers who insist on using EBDA, could have little choice and be forced to integrate into EBDA and take part in a server side auction. While from a latency and efficiency perspective, server side bidding has it’s benefits for publishers they can combine as many companions as they need in theory to participate in the public sale, From the demand side, exchanges could have issues cookie matching and wont be able to see their code on a live writer page client side.
Overall, there are lots of pros and cons.