DPSE Michelle Raubenheimer 2.22.17
•Als PPTX, PDF herunterladen•
1 gefällt mir•361 views
This document discusses header bidding and the two main types: client-to-server which runs auctions on the client-side before making requests to the ad server, and server-to-server which runs auctions directly on the server-side. It asks questions to consider when deciding which type is best for a business, such as the number of domains, importance of cookies, and key performance indicators. Both types are aimed at improving monetization and yield, with server-to-server solving issues like transparency and client-to-server being better for multi-domain sites. PulsePoint can provide clarity to help choose the right solution.
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Mehr von Digiday
Mehr von Digiday (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
DPSE Michelle Raubenheimer 2.22.17
- 1. DEMYSTIFYING SERVER SIDE HEADER BIDDING Michelle Raubenheimer Director, Publisher Development
- 2. WHAT DO YOU WANT? MONETISATION & YIELD
- 3. CLIENT-TO-SERVER SERVER-TO-SERVER AUCTION IN SERVERAUCTION ON WEBPAGE TWO FLAVOURS OF HEADER BIDDING
- 4. TAG DFP AD 1 2 3 4 HOW DOES CLIENT-TO-SERVER WORK? AUCTIONS
- 5. 3 TAG AUCTION 1 AD SERVER 2 AD HOW DOES SERVER-TO-SERVER WORK?
- 6. WHAT DOES EACH SOLVE? CLIENT-TO-SERVER SERVER-TO-SERVER = €€
- 7. How many domains do you have? How important are cookie matching capabilities? How important is auction transparency? Who are your partners? What are your KPIs? HOW DO YOU DECIDE WHICH IS RIGHT FOR YOUR BUSINESS?
- 9. PULSEPOINT PROVIDES CLARITY TO MAKE BETTER DECISIONS
Hinweis der Redaktion
- Aside from being aware of the Appnexus and Index collaboration on their own S2S integrations, there still remains a lot of unecplained questions over server-side header bidding – show of hands as to who understands it from audience and of those, who knows how to use it? We, as an ad tech community must start doing a better job of working together to help publishers get to grips with this fast moving technology in a more simplified manner to help support your bottom line goals: MONETISATION AND YIELD
- Most important thing to most of you in the room today – has been and will continue to be So how does HB help you do this? Let’s first take a look at the header bidding options: in browser and in server:
- With Client-side: Add more bidders to the unified auction – fast setup and more liquidity (Problem it solves: Liquidity) Server Side: Not all bidders submit bids before timeout which means $ left on table. We can collect ALL bids at once and then submit them to the wrapper. Minimises chances for lost revenue. How?
- Because header bidding places a special wrapper into the web browser that lives and executes in the client environment stuffing in as many third-party scripts as possible. What most web users and sites want to avoid is lots and lots of third-party scripts running in the client server; because it wrecks the user experience by slowing the loading of pages through latency. And when ads take ages to load, users go elsewhere. Server side header bidding promises to improve latency, scalability, and auction logic issues seen in traditional header bidding by moving communication with exchanges away from the browser and into servers. The process is essentially the same way SSPs and DSPs integrated for years, except this time the SSPs are integrating with each other. Server side header bidding works essentially the same way as regular header bidding from the publisher perspective, there’s just less implementation work to do. A publisher still has to put some JavaScript code in their header in order to trigger a request to an exchange before their ad call, but instead of one script per partner, there’s just one script overall that’s needed. On the ad server side, there’s really no change; publishers can decide to setup one set of line items across all partners, or a set of line items per partner. The real difference is on the exchange side, especially for the exchange that has the ‘tag-on-page’ position and is the platform that calls out to all other platforms server side. server side header bidding, at least one platform has to keep a traditional or client side setup with the publisher. Only AdX maintains a 100% server side connection with the ad server, though it does offer 3rd party exchanges a degree of server side access through its Exchange Bidding Dynamic Allocation (EBDA) product. For the server with tag on page however, they also need to manage integrations with all other SSPs the publisher wants bidding on their inventory. This integration works much like the OpenRTB integration between SSPs and DSPs in that bidders (whether they are DSPs or server side SSPs) submit their true bid and not the close price of their auction. This allows the tag on page exchange to run a true, unified auction across all server side connections on behalf of the publisher.
- Because header bidding places a special wrapper into the web browser that lives and executes in the client environment stuffing in as many third-party scripts as possible. What most web users and sites want to avoid is lots and lots of third-party scripts running in the client server; because it wrecks the user experience by slowing the loading of pages through latency. And when ads take ages to load, users go elsewhere. Server side header bidding promises to improve latency, scalability, and auction logic issues seen in traditional header bidding by moving communication with exchanges away from the browser and into servers. The process is essentially the same way SSPs and DSPs integrated for years, except this time the SSPs are integrating with each other. Server side header bidding works essentially the same way as regular header bidding from the publisher perspective, there’s just less implementation work to do. A publisher still has to put some JavaScript code in their header in order to trigger a request to an exchange before their ad call, but instead of one script per partner, there’s just one script overall that’s needed. On the ad server side, there’s really no change; publishers can decide to setup one set of line items across all partners, or a set of line items per partner. The real difference is on the exchange side, especially for the exchange that has the ‘tag-on-page’ position and is the platform that calls out to all other platforms server side. server side header bidding, at least one platform has to keep a traditional or client side setup with the publisher. Only AdX maintains a 100% server side connection with the ad server, though it does offer 3rd party exchanges a degree of server side access through its Exchange Bidding Dynamic Allocation (EBDA) product. For the server with tag on page however, they also need to manage integrations with all other SSPs the publisher wants bidding on their inventory. This integration works much like the OpenRTB integration between SSPs and DSPs in that bidders (whether they are DSPs or server side SSPs) submit their true bid and not the close price of their auction. This allows the tag on page exchange to run a true, unified auction across all server side connections on behalf of the publisher.
- Walk through How SS auctions work
- How many domains do I have: Publishers with multiple domains are likely to see server-side solutions in a bid to reduce bidder latency and sustain user experience. 1 Domain publishers may opt for client side for faster implementation and liquidity of partners Agnostic and collaborative partners - publishers will most likely want to work with multiple bidder partners as they have the option to do on client side. It’s becoming more pertinent that subsidiaryy demand partners will have to maintain agnostic and open to all S2S integration types across multiple ad servers From Ad-server perspective: publishers can decide to setup one set of line items across all partners, or a set of line items per partner. Because there are often hundreds to thousands of line items required per partner and as mentioned before, a key benefit with server side header bidding is being able to add many more partners, it’s more likely for publishers to pick the former option and consolidate the ad server setup into a single set. Auction transparency: Remains at the forefront of all server side integrations. If publishers are to trust one partners to mediate auctions across multiple bidders, the demand for an open source, fair and transparent auction model must be maintained across all/any bidder partners Cookie matching - S2S partners will need to have advanced cookie matching capabilities to ensure user matching is sustained and fair across all connected demand sources. S2S could harm monetization through poor cookie match rates. This happens because the SSPs that move from a client side setup to a server side setup lose access to the end user and can’t assign or read their cookie any longer. With traditional header bidding every user calls every exchange on every page, which might be lousy from a latency perspective but is fantastic from a user sync perspective. Each exchange can constantly and directly identify each user’s anonymous cookie.
- Problem it solves: Latency Transparency in auction mechanics across partners (promote higher CPMs) Collaboration between exchange partners to manage an accurate unified auction Server-to-server brings back more control to publishers, who have been on the back foot since the rise of programmatic advertising. (Trinity Mirror: publisher itself can now manipulate bids depending on who it has commercial partnerships with, and it can see who, how and when buyers are bidding, and has found ways to package up that capability to take to advertisers directly.) Danny Spears, Guardian: “Server-to-server technology will deliver huge benefit for publishers if it allows them to execute a true, unified second-price auction which they control, as this enhances transparency for buyer and seller,” http://digiday.com/publishers/winners-losers-server-server-programmatic-bidding-arms-race/
- We think beyond Header Bidding – we want to provide publisher’s with a platform to manage all their digital advertising revenue: PMP, Guarenteed, Audience Extension, even unique demand (Health) · For Header Bidding - We remain agnostic to all partnerships and ad-servers · Transparency is our game! · We’re about understanding our publisher’s revenue needs and providing solutions that fit every publisher – it’s about monetisation and higher yield at the end of the day, not walled-gardens or closed circle tech partnerships.