Meet the future of programmatic advertising: fast, effective, transparent and profitable.
Learn more about Fusion’s server-side bidding (SSB) technology.
The Signia SSB conducts Real-Time Yield Optimisation by comparing internally sold ad-candidate prices via those of bids received from external buyers. It’s available as an extension module to the Signia Fusion ad business management system, or as a stand-alone service.
The Basic Internal Ad-Selection Process
The website page or app makes a call to the ad server and requests an ad. The page sends along certain metadata: site and page names, optional key values related to the content or known values of the users, plus some user ad- and page-view history.
The ad server selects one ad per ad space on the page. The ads are chosen from a list sold by the publisher’s sales team, or from ads entered into the system by the publisher’s ad management staff (ad candidates).
All ad candidates are ranked according to an assigned priority number, and evaluated in descending order against disqualifying targeting and other conditions such as: media zone (site/page), frequency capping rules, geo-location, or key value (age, gender, content category, etc.) matching.
- If a candidate is disqualified for any reason, it’s set aside for the moment.
- The next ad candidate in the list is evaluated. If this candidate passes the qualification test, it’s then tested against a delivery weighting mechanism which controls how often the ad can be delivered over time.
- If the ad candidate passes both the qualification process and the delivery weigh assessment, it’s selected for delivery. If no ad candidates meet the selection criteria, no ad is selected.
Once an ad is selected, its accompanying payload (the code that renders and controls the ad in the browser or app) is sent back to the user’s browser or app.
The Basic Internal Ad-Selection Processwith a DSP Extension
In some cases the selected ad is not technically an ad, but a booking communicating to a 3rd-party application which has the responsibility of delivering the ad. For example: code that makes a secondary call to a DSP, which then runs through its selection process to deliver a suitable ad.
The payload delivered back to the user’s browser or app contains a set of instructions for requesting an ad from an external source, in this example from an external RTB provider (1).
5. External Selection
The external RTB provider (1) makes a selection, and delivers payload code to the user’s browser or app to display and control the ad.
6. Pass-back Ad-call
If the initial external 3rd-party (1) doesn’t have a qualifying ad to deliver, the payload delivered back to the user’s browser or app contains a set of instructions for requesting a new ad-call to be made from the primary ad server (Fusion).
7. New Selection
The ad server conducts a new internal selection round and selects another ad, which may be another external 3rd party (2). But it excludes the external RTB provider (1) from the ad candidate list.
8. New Response
The payload is then delivered to the user’s browser or app with instructions to call for an ad from the external RTB provider (2).
9. New External Selection
The external RTB provider (2) selects an ad and delivers the payload to the user’s browser or app.
The Basic Internal Ad-Selection Processwith a DSP Extension and Pass-back
If the RTB provider (2) does not have a qualifying ad, it initiates another pass-back, which in turn engages a third—or fourth, or fifth—3rd party. This continues until a qualifying ad is found.
Each of these requests take roughly 50 milliseconds, so the total cycle takes 200 milliseconds for one complete pass-back round over and above the original ad-call time. When stringing together a series of several pass-back cycles, the total time can easily add up to seconds in added latency.
There’s also no guarantee that the best yield is achieved. Because the ordered serial string—sometimes referred to as the “cascading waterfall”—of 3rd parties is predetermined (or randomly created in run-time), the first qualifying ad may not be the highest yielding ad.
The Fusion SSB Direct Process
The key difference between the current process and praxis o is that all the ad request negotiations happen:
- server-side, before any payload is passed back to the client;
- simultaneously in parallel, cutting down on ad call time.
Fusion SSB Direct also extends the publisher’s capability to collect, manage and pass on more user metadata with the ad bid request to entice better bids from 3rd-party partners.
How it works:
- An ad call is made from the client as per current praxis.
- Fusion looks up the user in a user ID and profile database, and adds more known profile information to the ad request.
- Fusion makes a preliminary ad selection as per current praxis.
- Fusion adds this selected ad to a new candidates list.
- If the internally selected ad allows for external competition, Fusion passes on a bid request to the Fusion RTB service.
- The Fusion RTB service then creates a series of RTB bid requests, including the additional metadata obtained from the user ID and profile database—plus a minimum floor price calculated from the selected internal ad’s effective CPM price—and passes this information to the receiving external RTB partners. These bid requests are made to each partner simultaneously, from server to server using fast and pre-established communication ports and protocols.
- If any of the external RTB partners have a qualifying ad, the bids are sent back to the Fusion RTB service.
- Fusion RTB then vets the incoming bids against quality and conformity to the request, selects the highest-yielding ad, and passes this information back to the Fusion final candidate list.
- Assuming there is a higher-paying external ad candidate, this ad is selected and its payload code is delivered to the client.
The full selection and bidding process, both internal and external, is handled on the server-side before responding any payload to the client. This process is much faster and selects the highest-yielding ad for each and every impression. The typical internal processing times for both the Fusion ad Fusion RTB services are less than 1 millisecond each, and the bid request/response process to the external partners can be cut off at a Fusion-controlled time limit. Adding the initial ad call and payload response times of 50 milliseconds, the total cycle is no more than 150-200 milliseconds.
The main advantages of the integrated Fusion RTB Process
Fusion RTB response times are fixed at around 150-200 milliseconds. This time does not grow when you add new external 3rd-party partners.
Every impression carries with it the opportunity to select the highest ad bid.
Fusion RTB also lets you connect with more external RTB partners. Because bids are managed server-side—not client-side—you don’t need to worry about ad call time or restrict the number of partners per loop. Whereas before you could work with a maximum of 2 or 3 partners per loop, now you have the opportunity of connecting hundreds (or even thousands) of RTB bid partners, increasing the pool of buyers.
This also means that the more active bidders in an auction-based ecosystem see better yields, as opportunities for cherry-picking on an impression-by-impression basis are attractive to both advertisers and publishers.