IPONWEB’S Derek O’Neil Discusses BidSwitch And How It Will Help Solve Global Programmatic Supply And Demand Fragmentation
IPONWEB launches its BidSwitch today at DMEXCO. With the number of bidders and customised solutions exploding, BidSwitch is seen as an attempt to solve the fragmentation problem in global programmatic supply and demand. Here Derek O’Neil, Chief Business Development Officer at IPONWEB, discusses the new solution and how it will fit into current eco-system.
What is BidSwitch, and why are you building out the solution? What problems are you solving for the industry?
Put simply, for any RTB trading system, BidSwitch makes it incredibly easy to get connected to other trading partners in the ecosystem.
To give that some perspective, consider that by our count there are somewhere in the order of 300 RTB enabled players globally and this number is growing by something like 20 more every quarter.
So, if you want to get global coverage of trading partners across all media, you have a lot of commercial conversations and technical integrations to take on, which really challenges the scaling capability of most systems. Even if you are playing in a single geographic market, the number of trading partners is large when you consider the growth in mobile and video as well.
Instead of reaching out to each company that you want to trade with one by one, and establishing commercial and technical integrations individually, you are able to establish a single commercial agreement with IPONWEB and do a single technical integration to the BidSwitch. Then through the BidSwitch be trading with a significant number of RTB enabled counter-parties straight away and manage that centrally and holistically.
Mechanically, how the BidSwitch works is that through the single integration, a participating Supply Platform sends a bid offer to the BidSwitch, and the BidSwitch relays that bid offer on to all integrated Demand Platforms that are in agreement to buy from that Supply Platform.
The Demand Platforms in turn send their bid responses back to the BidSwitch, and the BidSwitch aggregates these bids and sends them all back to the Supply Platform in a single response.
The key benefit that manifests here, is that each time a new Supply Platform or a new Demand Platform becomes available through the BidSwitch, all the other already integrated participants can immediately start trading with the newcomer. No commercial or technical efforts required. For the newcomer, the BidSwitch in full momentum will offer near instant scale and reach.
So, back to the original question, this problem, of getting access to the RTB eco-system as efficiently as possible, is the problem that the BidSwitch solves.
Is this a case that IPONWEB is trying to ensure greater interoperability between supply and demand in the current eco-system?
Yes, certainly. Given we build a large number of platforms in the space we are looking at this from a holistic perspective and trying to do our part to help ease some of the major pain points as the industry continues to grow and scale.
The BidSwitch concept is focused on solving this in a number of key technical ways:
1. Normalisation of bid protocols. Many of the Supply Platforms out there have variations in their protocols, though more and more are becoming OpenRTB based. The BidSwitch remaps all protocols as they pass through the BidSwitch into OpenRTB, providing protocol consistency across all Supply Platforms.
2. Single UUID sync location. A Demand Platform needs only sync a user once with the BidSwitch, and the BidSwitch in turn maintains the sync of that user with all relevant Supply Platforms. As a bid comes through from a Supply Platform, the UUID is remapped to the Demand Platforms UUID. Again, very efficient.
3. Unified traffic profile and QPS controls across all Supply Platforms. With the BidSwitch as a central pass-through point, we have been able to introduce traffic shaping and QPS controls (both bid QPS and UUID syncing QPS) as a centralized control, allowing the Demand Platforms to manage all Supply Platforms in one config, rather than maintain controls across each Supply Platform individually.
4. We are also mapping other things such as Deal ID’s and IAB categories in a unified way to help simplify other technical interactions as well and there are more in the pipeline
So, the long answer there is yes, the BidSwitch aims to help bring better inter-operability to the RTB space.
There are clearly issues around integrations – and the associated costs – within the programmatic space. How does BidSwitch address this problem?
If you take the case of a typical demand platform, lets assume that there are close to 80 different Supply Platforms around the world across the different media channels.
With the BidSwitch, we have started with a focus on display, and there are currently 20+ Supply Platforms participating in the BidSwitch program, and approx. one additional display Supply Partner being added per week right now. We’ve also started inviting video supply platforms as well.
So from the Demand Platform perspective, in connecting directly to Supply Platforms, its not uncommon for a Supply Platform integration to take in the order of 3 or 4 weeks for a team that is well honed at the task, maybe longer if you take into account the time for commercial discussion and contract negotiation.
If you want to enable your Demand Platform to buy from 20 Supply Platforms, you can do a single integration with the BidSwitch, and in one month be up and running on buying from 20 different Supply Platforms. Compare this to doing these integrations each individually directly, which could take a couple of years to achieve the same outcome and tie up a significant team of engineers in doing so, not to mention roadblock more value-added features from being delivered.
So in this way, the BidSwitch makes the task faster and cheaper, achieves trading scale very quickly, and frees up a Demand Platform’s engineering team for other roadmap deliverables other than RTB integrations.
People will wonder if this is another exchange proposition? How will this differentiate from that existing model? And why is it so different particularly on neutrality and price transparency?
The BidSwitch is a trading facilitation tool, and not an exchange. We are very much focused on providing a thin infrastructure only layer here. The difference is very important for us and there are a number of key principles that support this.
The first key principle is that the BidSwitch avoids imposing its own bias, whether it be in selection of auction wins, interference in pricing, or imposition of variable margins based on the participant.
For example, where possible, we do not run an auction in the BidSwitch, but merely pass the bids through. If the Supply Platform is capable of handling multi-bid response, we will pass through all bids up to the limit of the multi-bid response. So if the Supply Platform can handle 15 bids back in a single bid, we will choose up to 15 of the highest bids from all Demand Platforms, and send all of those to the Supply Platform to run their auction.
Of course if a platform cannot handle multi-bids, we will decision it in order to choose a winner. However we encourage Supply Platforms to adopt multi-bid response handling. Additionally, we can also make aggregated reports of the bid depth available for any bids that had to be excluded from the realtime signaling process.
A second key principle is to provide complete transparency about all the interactions of the participants; from the Supply and Demand counter-parties, who is available to trade with, what the original bid values were, and what the cleared auction price was.
In that spirit of transparency, the BidSwitch fees, being a low flat service fee charged based on the value of media traded, is also clearly illustrated to the respective trading parties. This allows the trading parties to do the maths on when the cost of the BidSwitch no longer makes economic sense for them, and it might be more cost efficient to move to doing a direct integration.
That spirit of ‘use the BidSwitch if its good for you, and trade directly if that works better’ probably best defines why its not just another exchange, and how we encourage folks to think of the BidSwitch as a trading facilitation tool.
BidSwitch is not a standalone P&L play that needs to stand on its own two feet commercially, instead it aims to foster trust amongst everyone so that we can solve this connectivity problem at a global level.
Finally, another key principle, if you are not an RTB enabled system, you cannot participate in the BidSwitch. We won’t accept publishers directly (there is no ad tag capability), nor provide a campaign management tool for advertisers to directly buy in the BidSwitch. In this way the BidSwitch maintains its position of being a bid routing tool for sending RTB bids between RTB enabled media trading systems.
Is BidSwitch a real opportunity for those smaller players in the market to access inventory required to compete? And how can it help in regional markets where integrations could be costly and time consuming?
BidSwitch definitely accelerates time to market for new-comers in RTB trading, and in the same way BidSwitch also accelerates new geographic market penetration or expansion into another media channel for established players.
For regional expansions, discovering who are the supply players in a new market has all the joys of language, commercial and technical integration challenges. The BidSwitch makes this much simpler. Simply talk to us about your new market, and after spinning up a new geo-datacentre endpoint with the BidSwitch, the BidSwitch will start routing traffic from that geo-location from the Supply Platforms of interest.
To that extent, we currently have a very healthy depth of Supply Platforms in the USA, Europe, and Asia.
You want BidSwitch to be a facilitator play rather than another attempt to build a closed eco-system? What do you mean by that?
IPONWEB’s core business, our u-Platform business, is the building of sophisticated custom media trading systems and is driven by an open and easily accelerated RTB eco-system.
This is one of the reasons why we have built the BidSwitch, to remove the obstacles of integration friction that was a growing challenge for our core business.
However, the BidSwitch only works if any and all participants in the eco-system are able to make use of it, not just IPONWEB based media trading systems.
To achieve this we need to solve the integration challenge and plan to open up access to the BidSwitch to anyone who wants to make use of it. The BidSwitch helps independent technology stacks, and in turn that re-inforces the utility of the BidSwitch, which then becomes increasingly important to our regular u-Platform clients as well.
We see it as a win-win for all concerned, and so hence BidSwitch is an open-access tool.
In terms of market roll-out we are currently in late closed beta, bringing on board new participants in a selective manner while we bed in final features of the product and service offering, and soon will open it up to anyone.
