When header bidding was introduced to the web publishing industry, it did truly add so much value that ranges from ad latency to user and bid transparency. It opened up part of the black box in the digital advertising ecosystem that was much appreciated and greatly welcomed by publishers. But what about publishers that don’t just have a web presence but also an app in the Apple Store and/or the Google Play store? Is there an opportunity where publishers can monetize their content across multiple platforms without needing to onboard dozens of ad-tech solutions that are platform specific?
Low user match rate
By moving SSPs from client-side to server side, they won’t be able to gain access to their cookies and other data that further identifies the user or their interests in their systems. Without that user-matching cookie SSPs and advertisers will have less data to go by when bidding and thus lead to an inefficient bid due to insufficient data. Whether the ad call is being made from the web or a mobile app, the user match rates will always be lower than with client-side bidding until the internet comes around and potentially offers a universal user identification platform without actually identifying the user.
What about the ad server? Is it S2S too?
For publishers using DFP, the S2S solution isn’t including the DFP call in that environment. The DFP call is still made on the client-side after the S2S call responds back with the highest bids for each ad unit. This might not be the case for mobile apps, but it’s definitely the case for web publisher using ad server that doesn’t offer server-to-server ad serving capabilities.
Tech ownership and scalability
For publishers willing to migrate from client-side to server-side bidding, they have a few options today. One option is to use the free Prebid Server but the free offering goes through AppNexus’ servers which removes a lot of control and ownership from the publisher. Other SSPs offer S2S services similar to their header bid wrapper services, but you’re still losing a lot of control and ownership over the tech (which perhaps for many publishers isn’t a deal breaker). For publishers to truly own their S2S solution, they would essentially need to build and host their own ad server that is able to make and receive server-side API calls to all the desired SSPs. This is a challenging task since you’re essentially building your own global real-time bidding server which comes with scalability, availability, performance and other challenges which took SSPs years (if not decades) to perfect.
For many publishers today, knowing the restrictions and limitations mentioned above, they decided to run S2S in a hybrid environment: client-side header bidding that includes their highest performing bidders plus server-side bidding for the remaining participants. This is probably an interim solution until the issues above are widely resolved, especially regarding the user-cookie mismatch and tech owenrship.