The Secrets Of Demand-Side Platforms
Technology is evolving in ways in which online adverts are being bought and sold. So here are some few tips which you need to know about the Demand-Side Platforms (DSPs).
What is Demand-Side Platform?
A Demand-side platform is a set of technical components that allows advertising to access digital inventory through several ad exchanges or ad networks. This digital inventory is given by publishers on SSPs (Supply-Side Platforms). This is not detectable from the users’ perspective when it lands on the publisher’s page and sees a banner that displays the advertisers’ message. Publishers are in a search for more inventory than the usual to make-up for the lost advert dollar in difficult economic ecosystems and that’s the reason why they have to sell their inventory of the ad exchange market through Real-Time Bidding.
Demand-Side Platforms are very unique and rare because they take in many of the facets previously offered by the ad networks, like the wide access to inventory and vertical and partial targeting, RTB on ads, with the ability to serve ads, track the ads, and optimize. All these are kept within a single interface which creates a good opportunity for advertisers to truly control and expand the impact of these ads.
Demand-Side Platforms are mostly used for retargeting. The aim is that an advertiser can see a large amount of inventory in order to be able to recognize a user he is trying to reach.
The whole bid, decision, buying and banner display process should be able to issue in less than 100 milliseconds or in the blink of an eye. Real-time bidding takes place within the ad exchange for online advertising and by using a DSP marketer you can manage their bids for the banners and price data that lays to target their audiences.
Why is DSP so important?
According to history, human ad buyer and sales people sold and bought digital ads which made it expensive and unreliable. The introduction of DSP to the advertising market has helped make that process easier and more efficient by removing the humans from some parts of the process, and also the need to manual fax ad insertion and negotiation of ad rates. Demand side platforms comprise of various components that need to be properly delivered.
What do Users do on DSP?
One biggest challenge of creating a DSP is to have the opportunity to communicate with different users on the internet. There are two ways of having data; from both DSP marketers and SSPs who are the publishers and from the advertiser’s websites (this is complex).
What does it mean to Interact with a lot of Users on Digital Advertising?
In order to know and retarget the user on the right segments of the demand-side platform, you need to gather information about these users like what they have viewed, what they have added to the basket, what they have bought, what they have clicked on. As soon as you have all this data then you can begin to navigate these users and worth the time to even bother to bid and display your banner. But before you can win a bid and display your advert banners you need to pass through some few steps to guide you to your destination.
For you to be able to collect this data you need something known as “tag server”. Tag servers are web servers that generate data for user’s specifics. This tag server integrates into the customer’s websites or a third party partner. Not just that alone, the tag server is also used to collect data about your banners like which banner the user has viewed, what banner this user clicked on. All this data will be stored in real time to form what is called Data management Platforms (DMP).
DMP (Data Management Platforms) is a warehouse for data and a piece software that takes in and houses any form of information and modify it, bringing it out in a way that useful for publishers, marketers and different kind of businesses. It’s more of a database. These data can be collected by the use of some specific parameters in tag server URL. For the advertisers, the tag server is inserted directly into the webpage and for the publishers side, the tag server is inserted into the banner. When a particular user tries to perform a specific action on this website that bares your banners, the user’s browser will generate an interaction with our tag servers with redirections (ex: 302). This process will involve the direct call of the user’s browser calling out to the tag servers from server to server. This call will allow the DSPs to obtain more information than just the parameters given in the URL and the data that are not collected through the URL parameters are obtained from the User Agent or the server specifics such as the user’s IP address, the kind of device this user is using on the internet, the details of the users browser, the users location (users latitude and longitude), and a lot more. Before we go into more details about this, let’s take a little bit more details on the types of data you are going to collect and how this data is being collected.
Pre- advertising data (User Navigation)
Pre-advertising data is the kind of data you manage to get from users before they get attached to a specific banner display process. For instance, you have a customer who is called Nike. Nike wants you to deliver some advertising campaign to his customers and to be able to execute this process easily you will have to give him your tag server URL to insert on his website allowing you to get data from him, navigating users. If a user decided to see a specific product (ex: Running sneakers- Flyknit Racer Oreo- size: 9), then this website will then call on your tag server URL with the product’s specifics in the parameters: https://dspserver.com/n?p1=0101&p2=099&p3=9&id=1 considering the fact that each of those parameter codes have a specific match on your end.
This is quite simple!. The table explains the matching between the URL parameters and what exactly these parameters mean. All matching are directly inserted in the URL for security issues and fraud so it is best to keep a matching table. But there are also some data in each of this tag server call that is not available in the URL directly.
Right from the tag server, this call is generated by the user’s browser which means that the tag server gets in contact with the user’s browser directly. This will then allow you to collect as much data on the user’s as possible like the device the users is on with specifics about that device, the user’s browsers specifics, the user identifier(UID), the users IP address and most time the users exact geo-located position. By collecting data from the customer website, this is what is called Pre-advertising data (user navigation).
Advertising Data (banner impacts on user)
Once you have the data you need about each of these users. Potentially, we can now know if you want to display a banner or not and then pay for it. Looking at the fact that you already have your DSP (demand-side platform), as soon as you deliver some banners, the tag server will also send you data about the exact banners that’s been displayed, to which user identifier, for which campaign. This process is what is called Advertising Data. Anytime a banner is has to be displayed on a publisher’s website for a specific user, the tag server will be called with these parameters allowing it to recognize the campaign (ex: Nike), the banner (ex: banner 23) and so on.
Segments
All these data are what the marketing world would call “segments”. Market Segments strategies used generally to indicate and define target customers and make available data to support the marketing plan elements like positioning to attain a particular objective in the marketing plan. In marketing a segment is a user attribute, targeting a user in marketing is based on its segments. Sometimes the customers of a Demand-Side Platform (DSP) company would like to target only people based on their physical position.
A segment can be a position, a banner clicked, a banner viewed, a product viewed, and an IP address range. In the Demand-side platform (DSP) all the campaigns advertisers are composed of a set of segments (ex : Nike + Flyknit Racer + 43). Based on these segments when the DSP bidder is going to receive a bid request, he will have to compare the segments existing in the user’s profile and the campaigns that are eligible to this set of segments.
Profiling Versus Logs. What is a Profile?
I am sure you are wondering what profile is all about in DSP. Once you receive the tag server call there are several ways to collect them depending on what exactly you want to do. At first, you need to set up some reports about the user’s navigation and for this, you need to generate some logs (Flume, Kafka or Cloudera). These logs will allow you to give a report on the data science analysis, banner’s delivery, and also do the delivery forecast for products. On the other hand, these tag server call would be used to give your DSP an opportunity to arbitrate the segmentation according to each user’s specifics.
In order to do this, you need each user’s segment (event) updated in real time. To do this a profiling system will be used in other to cache the systems memory this is known has MEMCACHED. Each profile has to be unique and with this uniqueness, it will allow the DSP to gather navigation data about a specific USER IDENTIFIER (UID). Each of these profiles will be incremented with segments based on the USER IDENTIFIER (UID) and must be lower than 2ko.
The Real-Time Bid (RTB) will gain access to this Memcached in order to define if you want to display a banner to a user or not. This decision is based on the segmentation algorithm which you will see later.
Banner Generator (HTML5)
Banner generators are perfect alternatives to do work with design agencies or creative or freelance designers. The requirement to test and iterate small scale businesses that have a quick need to display advertisement campaigns might serve as a hindrance to creating banners using this software.
Looking at the Real-Time Bidding market today, it has become more complicated than ever to have a proper hit rate with Flash banners and it is still becoming more complicated. The browsers are less compatible than ever with the Flash banner and this circle still continue delivering campaigns with HTML5 banner because it is very essential.
Moreover, the Flash banners are reality static so if we would have a dynamic banner based on the products for which you can go back and target the user, you would need HTML5 banners. In Demand-Side Platforms (DSP), it is not compulsory or mandatory to have a banner generator but it worth talking about. For the main parts of DSPs, the advertisers directly provide HTML5 banners but if you have a huge amount of adverts, it is best to make them produce their own banners on your own banner generator. The complexity with HTML5 banners is based on the compatibility with the browser but each browser does not react the same way with this HTML5 banners. Once there is an update on every browser and a newer version is released it is really difficult to adapt to all the HTML5 banners that have being created for customers use. So in order to cope with this difficulty, you need to make the banners think in a way that if there is an update, this updates would be done on only a template correcting the entire banner portfolio. These templates are the easiest solutions to managing these kinds of bulk corrections. You have to also note that each of the banners created needs to be audited or check out by the ad exchange before it can be able to deliver some hit.
Dynamic Product Banners
Dynamic Product Banners as you read previously is the banner generator that will also allow you to generate design basic template and generate its banner contents like the size, the products, and the colors according to exactly what the customers have seen. In order to do this, you need to get customer’s catalog with all the product specifics giving the Real Time Bidding server (RTB) and the banner generator an opportunity to do the mapping between the segments and the catalog products. Dynamic Product Banner allows a visitor who visits your website from a product detailed page to see relevant products in a centrally located banner, the dynamic banner ensures that the product in the banner is related to the visitor’s original search intent so the visitor is likely to remain on your website to complete a purchase. This dynamic product Banner enables you to advertise to other people who previously visited your website.
The risk of doing a dynamic product backlog is for you to be able to use the customer’s content again directly from the customer’s server. When a banner is displayed massively on the publishers, this banner generates just one server call per image and also per displayed banner. This will have DDOS effects on the customer’s website so the best way to cope with this, is to use an ETL the replicate and synchronize the content on DSP side. In order to manage this banner audit for dynamic product banners, it is important to provide a generic banner per brand and deliver the campaign hits with the dynamic product for the same banner for a specific brand.
Ad Server
The ad serving system allows publishers (SSP), advertisers and ad networks to serve adverts on websites, in video players, in apps and collect all detailed statistics about the impressions clicks conversions through the use of the tag server. Ad servers make a full description of the technology and services that are used to insert this advertisement on websites.
Once the banners have been created and the bids are won, you need to display the server and also display the banner. The Real-Time Bidding (RTB) mechanism must be quick and for this the bid to be responded, they must be sent by the Real-Time Bid (RTB) server and has to be really light. If you send an HTML5 banner in the bid responses, the process would be extremely too slow to work with because of its volume (images, code, etc.) so avoid the attachment of an HTML5 banner in the bid response.
Basically, the ad server is allowed to handle the volume and the bandwidth required to deliver its content as heavy as the image files. In order to cope with this, you host the banners on your side with an ad server and you send this banner’s URL to the ad exchange in the bid response. The images are stored on a Content Delivery Network (CDN) and the Ad Server will then compute the banner to be displayed. The URL provided by the Ad Server for each banner will be called by the Ad Tag. This makes a little more sense with the RTB server.
RTB Server (Real Time Bidding)
Real-time bidding is a type of programmatic advertising, but not all programmatic advertising uses RTB. Some “programmatic” platforms or technology driven platforms allows publishers sell inventories in advance for a fixed price, as opposed to auctioning it off. This is process is referred to as a programmatic guaranteed or programmatic direct.
Typical the transaction starts with a user visiting a website. This then triggers a bid request that can include different kind pieces of data like the user’s demographic information, location, browsing history, the page being loaded and the ad exchange unique identifier. This request moves from the publisher to an ad exchange, which then will submit it and accompanying data to multiple advertisers who can submit the bids in real-time to place their ads. The bidding happens automatically and advertisers set their maximum bids and budgets for an ad campaign.
The standard for bidding on a particular kind of consumer can be very tricky and complex, taking everything into account from a very detailed behavioral profile down to a conversion data. Derived using probability models can be used to determine the probability for a click or conversion given the user’s history data. This probability can also be used to know the right amount to bid for and the respective ad slot.
Real-time bidding (RTB) has to do with the practice of selling and buying displayed ad impressions through ad exchanges in real-time and going through one impression at a time. The impression goes to the highest bidder and their ad is served on the page. This process is done repeatedly for every ad-slot on the page. Real-time bidding transactions basically happen within a 100 milliseconds from the moment the ad exchange receives the request. The buyers who are the advertiser, agencies, and some other networks are normally connected to the ad exchange by the DSP (demand-side platforms). The DSP (demand-side platforms) automatically makes the decision to buy according to various parameters entered by the advertiser (price, target, ad unit, etc.).The sellers are the publishers and some other networks are regularly connected to the ad exchange through a supply-side platform (SSP) upon which they provide ad impression inventories and set floor prices.
Real-time bidding (RTB) was initially used for selling remnant, small publishers’ inventories or second tier inventories on ad exchanges but now Real-Time Bidding (RTB) is expanding to every part of digital advertising domains like premium inventories and native advertising. Sometimes, real-time bidding for premium inventory can be done on private ad exchanges. Looking at various studies, Real-Time Bidding (RTB) in the past was making approximately 30% to 40% of its total display advertising at the end of 2015. Business insider intelligence says that ad revenue has topped fifteen billion dollars RTB, mobile in particular and RTB video has lead way for this growth. Business insider intelligence also said that the Real time bidding revenue will go pass $26 billion by the end of the year 2020. This definitely surpasses 8.7 billion this year.
For the advert market, Real-Time Bidding is a way that you can reach the market balance and reduce its costs and its processing times. You can do this through the algorithms used on ad exchange and DSPs, it is a way to increase campaign effectiveness as considered by buyers. It may be noted that, if Real-Time Bidding (RTB) refers mostly to display its advertising trade, the first method of the use of RTB has been made on Pay per Click (PPC) search engine platforms. And very soon RTBs will be used on TV with programmatic TV. Pay per Click (PPC) is a kind of internet marketing that the advertisers pay a certain amount of money anytime their ads is been clicked. In essence, it is a way of paying for a visit to your website instead of earning from those visits.
The RTB server is the server (set of servers) that will be in direct line with the ad exchange. Basically, the ad exchange sends a bid request. This bid requests can be considered as suer proposition. The Ad exchange is going to propose to you if you are interested in this user or not but there is a huge difference between responding a bid on RTB market for a simple display campaign and responding a bid on RTB market for a user you recognize (retargeting). The steps below will explain how you can be able to get this done.
SSP Mapping and Cookies Synchronization
The SSP mapping is a process by which when a user is been identified by a certain system either the DSP system or the partners SSP system the system with automatically generate a very unique User identification (UID) but this UID will only be unique in the system. For instance, if you generate a User Identification on your side of the DSP, for the same user the User identification can be the same on the side of the SSP but 99.9% of cases says that the User identification will not be the same on the SSP because the User Identifications are generated separately in each system both in the DSP and the SSP. So for you to be sure that the SSP is only sending a proposal of some users you know, you will have to call their server every time you identify a user. If the tag server doesn’t recognize, the SSP will create it and callback your tag server with the User’s identification that has been created and send it through the HTTP method but if the user already exists in the network then your tag server will just be called back with the User identification key. Now it is possible to keep track of the user’s activities. Once this mapping is in place, then it is also necessary to do a cookie syncing for this user.
The process of matching the SSP cookie ID to the DSP’s goes through a process that’s parallel to serving ads which are called Cookie Syncing. Cookies are naturally useful in the identification of what or which advertisement the user has viewed and had an interaction with by clicking on it. Cookie synchronization is not negligible because it has some security standard process, a web server that can only request for cookies that a set for a particular domain. SSP is between the end-user and all other bidder of the DSP in an RTB auction but the DSP has to have a way of identifying the user it is in search for. When ad exchange sends a bid request, it provides you with the User identification of its user. The issue is that the User Identification is only unique when it is in the system. This means that for an already existing user, the ad exchange will have its User Identification provided by the Supply Side Platform (SSP) and you will equally have the same on the Demand Side Platform (DSP). In order to find it easier to define if the user is interested in you based on the SSP User identification, we need to hold a mapping table in our database with the SSP’s User Identification your own User Identification (DSP). Then it will be possible to define you would like to bid for a user since we can recognize him on our servers.
Network connector
There are different kinds of communication protocols with the ad exchanges. The Network connector is the way to communicate with the ad exchange to get the bid requests and send the bid responses. Each RTB connector is specific to each ad exchange but usually, they try to respect a norm which is called Open RTB. Basically, the bid response is a JSON with all the response parameters as shown in the below example.
Open RTB has just a mission and that is to spur greater growth in the RTB advertising market by making an available standard for communication between a buyer that’s advertising and a seller that’s publishing inventory. The Open RTB was made public in 2010 by a team of 6 companies in advertising online space and also represents both the selling and buying sides.
Limiters
The limiters’ is a database module aiming to analyze the real-time consolidation based on the logs delivered by the tag server. The limiters module is a campaign focused and updated every two minutes. According to this consolidation, the limiters module will have to check the expected delivery trends per campaign and it will be easy to know if you are making an over delivering or not for each single campaigns. Once the decision is set for each of the campaigns, the ad serving status for each of this campaign will be updated (true or false)
- True = it can deliver
- False = it can’t deliver
Filters
As soon as we receive the bid request, the filters module is the first to take action. The filters are the RTB module aiming at deciding if you would like to bid for a user or you just want to send ‘an ignore bidding request’ for this user. The filters must make the decision process as fast as possible by defining quickly if you are interested or not interested. Looking more into details, this module will then filter the candidate campaigns for this bid request. On the other hand, to make this decision, the module would have to compare the bid request specifics with the campaigns specifics like the Zone versus Blacklist, Whitelist, Retargeting delay, User capping, Media capping, Campaign capping, Floor price, and Ad serving status based on limiters update either true or false. Once this module has been given its decision and the bid request has gone through, you can then go through what is called the segmentation algorithm.
Segmentation
The segmentation algorithm is the Real-time bidding (RTB) server module that allows the users to define as fast as possible which campaign will have to be the candidate and will be displayed by the banner.
Basically, this algorithm is going to define as fast as possible which campaign will win the bid request. Once this is action has taken place, then you are free to go through the pricing algorithm.
Pricing
Taking a search for the best campaign for a specific user is extremely important. But hoping to get a good price to bid is a real challenge in the RTB market. A bid request is sent to several DSP until at least two of them respond with a price.
This is just a reminder; here are some basic rules of the real time bidding market. Actually, most part of the ad exchanges are managing bids thanks to the Generalized second-price auction model contrary to the Vickey-Clarke-Groves auction model used by Facebook Audience:
- The ad exchange gets the first DSP price.
- He waits for a second DSP price. Once it has both prices, the highest wins but pays the prices offers by the loser.
- In order to have a better portfolio ROI, it is important to have a performance pricing algorithm. This will determine its success in the RTB world.
- At the beginning of the DSP story, we can start by bidding with a fixed price. But it is important to move forward to bid with dynamic prices. Once we are able to respond a price, we are able to win the bid.
- When the first bid has been won, your ad server will then be called, your banner should be on display, your tag server will collect the data and generate the report, and this is the beginning of a DSP platform.
- The publishers who are able to provide these audiences and engage them will also be successful in the RTB world.
- Check the entire available inventory against each bid and select the highest bidder ultimately serving the advertisement.
In conclusion, the great news for advertisers is that it offers the ability to increase their performance and reduce wastage by identifying which segments, websites, creative and ecosystem works the hardest for their budgets. This also requires some more management and increased level of sophisticated data and technology, so the payments are higher than the levels displayed online. The improved performance should be more compensating for this difference, I suggest you go through this tips extensively if you are an advertiser.
Thank you for reading.
