Bidlink

Owned by Ted Nieuwsma
Last updated: Mar 14, 2023 by Julien Monbillard
2 min read

Bidlink Bid allows publishers to utilize SpringServe’s demand and have it compete on price within another ad server. Let’s say you want to make use of all of SpringServe’s features but you don’t want to move off of your primary ad server, Total Connect+ Bid allows you to stay on your existing ad server but have the SpringServe demand bid dynamically within that ecosystem.

As far as the actual integration goes, there are 3 different routes you can take:

  1. RTB -- This is a standard OpenRTB integration (based on OpenRTB 2.5) where users POST to a SpringServe /bid endpoint via OpenRTB format, and we respond with JSON (also in OpenRTB format) that contains the bid(s) and ad content.

    1. The flow here is: POST to SpringServe /bid endpoint --> SpringServe conducts auction --> SpringServe returns OpenRTB 2.5 response.

  2. Inline -- In this integration, users make a GET request to the SpringServe /tci endpoint and include a "tc_inline_url" (the ad server url they want us to redirect the bids to) within that endpoint. SpringServe conducts the SSP auction, caches the bids using a pre-determined and agreed upon configuration, and then calls the "tc_inline_url" and includes the appropriate key values in the querystring of that url.

    1. The flow here is: GET to SpringServe /tci endpoint --> SpringServe conducts auction, constructs key-value pairs, and caches bids --> SpringServe calls 3rd party ad server via tc_inline_url and passes the constructed key-value pairs --> 3rd party ad server makes final ad decisioning (if a SpringServe bid is chosen, the ad server calls the "tccallbackurl" which is a call to our cache to fetch the VAST document for a given key-value pair)

  3. KVJ (key-value json) -- In this integration, users make a GET request to the SpringServe /kvj endpoint. This is similar to the "Inline" integration in that SpringServe will cache bids and build key-value pairs based on a specified configuration, however rather than pushing those bids to a 3rd party ad server, SpringServe simply displays all the key-values/cache information via a JSON response. This means that some sort of proxy needs to then take this JSON and use it for final ad decisioning.

    1. The flow here is: GET to SpringServe /kvj endpoint --> SpringServe conducts auction, constructs key-value pairs, and caches bids --> SpringServe displays JSON response with key-values and caching information.