I wrote about the basics of how DSPs, SSPs, and Ad Exchanges work from a high level and the value they add to the marketplace in my last post – for this piece we’re going to dig into the nitty gritty of how RTB ad serving works from a technical perspective.
In my explanation of third-party ad serving, I outlined a 12-step process to get from publisher ad call to marketer ad creative. In an Exchange environment the process is basically the same, but with three new parties involved: the SSP, the DSP, and the Ad Exchange itself, which all act as the ad selector, instead of the publisher’s ad server.
You can view a diagram of the RTB ad serving process at the top of this post – the numbers in the text refer to the steps labeled in the diagram.
When a browser navigates to a publisher website (1), the publisher’s web server sends back a bunch of HTML code (2) that tells the browser where to get the content (3) and how to format it. Part of the HTML code returned to the browser (4) will include a coded link known as an ad tag. That part is the same as in regular third-party ad serving. But instead of returning a DFA or Atlas tag, the Publisher Ad server will return a tag that points to a RTB-enabled SSP, typically through a dynamic Javascript tag that passes information like the publisher’s ID, the site ID, and ad slot dimensions.
From there, the user calls the SSP server (5) where the SSP reads that user’s SSP cookie ID, likely already on their machine. Assuming the user already has that SSP’s cookie on their machine (and most users will, given that the largest SSPs boast 80 – 90% reach rates to the US internet population), the SSP starts the auction by requesting bids from a host of demand sources, the DSPs (6). If the user does not have an SSP cookie on their machine, their ad inventory can technically still be auctioned, but since nothing is know about that user, the price will be very low and more related to the site context than the user’s attributes. For the DSPs to truly value the impression though, they need to know something about the user that is going to see it. This is where the SSP cookie ID comes in – packaged with the bid request is the SSP’s cookie ID, along with the url the impression will deliver on, and what the current user’s frequency is on the site.
All these factors help the DSP value the impression. First, through a rather complex cookie-syncing process, DSPs are able to match the SSP’s cookie ID to their own cookie on that user, which is tied to a huge cache of marketer data and 3rd party data. What kind of 3rd party data? Using the cookie ID, the DSP will be able to know if that user recently priced out a car, is flying to Paris in the next 90 days, was recently shopping for shoes, and even more general demographic information about the user such as their age, gender, income range, credit score, and much, much more. I’ll cover how that all works in a later post. But suffice to say, rich data is far and away the driver of higher bids, and the cookie ID is the mechanism through which data is associated to a user.
In addition to the cookie though, where the ad will appear, the URL, is also important. Many brands don’t want their ads to appear on just any site, even if they want that user. If the user is on a site with PG-13 content, for example, the advertiser might bid a lower amount or not at all. Similarly, the frequency of that user to the site they are on is also important to valuation. Advertisers are willing to pay a premium to reach users on their first or second pageview on a site vs. their 50th pageview for the simple fact that users are less engaged with site content and more likely to respond to an ad during their first few pageviews.
Using those pieces of data, the DSPs all value that impression and submit a bid back to the SSP (7) as well an ad redirect to send the user should their bid win the auction. The SSP picks the winning bid and passes the DSP’s redirect back to the user (8). From here the process is basically the same as third party ad serving – The user calls the DSP (9), the DSP sends the user the marketer’s ad server redirect (10), and user calls the marketer’s ad server (11) and the marketer serves the user the final ad (12). The RTB ad serving process is complete – whew!
How are the workings of a mobile ad exchange (e.g. mobclix, adfonic, Opera) different than that of online described by you in your above post?
Hi Bob,
It’s a good question, but unfortunately I’m less well versed in the mobile space. My understanding is that Mobclix would work very much the same way I’ve outlined in the redirect path for RTB exchanges since it is also an exchange. Adfonic looks to be more of a traditional network however, so I would expect them to have more of blunt approach to ad pricing that is less related to impression by impression valuation due to audience characteristics, and more related to content adjacency.
Do you have any links to empirical evidence or hard data to support your claim that users are more likely to respond to an ad during their first few pageviews as opposed to 40th or 50th pageviews?
Hi Dan,
I think the best article I’ve seen on this topic is something Mike Nolet, the CTO of Appnexus, wrote about on his blog, MikeOnAds.com, way back in 2007 called Maximizing Network Revenue. While the graphs and data points he cites are technically fictitious, I can tell you from my own experience that they absolutely hold true and buyers will usually be pretty transparent with you that they will pay more for the first impression, regardless if they are buying on RTB, or directly via roadblocks or first-impression products that command a premium. You can also look at Slide 12 of this AdMeld presentation, which has a graph of fill rate on their system by frequency for further evidence that there are more buyers and thus a higher value to the first impression a user sees on a site.
Hope this helps,
Ben
Great Article Ben,
Very curious to know about how the SSP cookie gets matched to other cookies that the DSP has. You mention cookie ID/stamp?
Great if you could provide some insight into how this works, especially keeping in mind re-targeting campaigns where an existing cookie pool is leveraged to target the user on different sites.
Also it helps of you can put into perspective the Exchange / SSP / RTB platforms , are these all the same thing? Is that then saying RMX is similar to pubmatic in some way?
Thanks Sid,
Great question – the answer is a bit long for comments, so I’ve published the answer under a new post. You can read it here: http://www.adopsinsider.com/ad-exchanges/ssp-to-dsp-cookie-synching-explained/
As to your second question, the Exchange provides the liquidity to RTB auctions. Right Media Exchange (RMX) is an ad exchange. SSPs like Pubmatic optimize the demand that comes through an exchange and bids in RTB with other sources of demand, such as that from an Ad Network that may not bid in real-time, or even direct-to-publisher remnant deals. Think of an SSP as an Exchange-Plus, and as a service for Publishers only, vs. Advertisers and Publishers, which many see as a conflict of interest with both parties. Publishers can load in competing sources of demand and have an SSP run those sources against a real time auction to maximize the amount of revenue from every impression. SSPs also provide better reporting and analytics than you would find from an Exchange.
Hope that helps,
Ben
Ben. Loving these posts. Never seen anyone to go into as much detail as yourself. Nice work.
Thanks Ciaran, appreciate the positive feedback!
Great post:)
hi,
can you explain briefly about how the cookie synching happend?
or give some useful links to learn about cookie synching.
Hi Jagan,
I actually wrote a separate post about cookie syncing – you can read it here.
Ben
Excellent Ben. Thank you for the clarification above…invaluable.
You segmented above into some discussion around SSP reach rates and the lack of value in the auction in absence of SSP cookies. I would very appreciate some color on this process or directions to research around this issue. We are trying to compile real reach rates of SSP’s, facts and figures around this weaker inventory, and what the resulting process looks like when these impressions gets auctioned or routed through the DSPs.
Best,
Oren
Hi Oren,
That’s correct – without a cookie match of some sort, it is difficult for bidders to value the impression. Based on what I’ve seen, a synced cookie tends to monetize at 25 – 100% higher than a non-synced cookie, depending on the DSP. In terms of reach, I would challenge you to consider that metric in a few different ways. When most people talk about reach, they mean unique users. Every SSP will tell you they can reach 90%% of the US population, about 180MM cookies in the US, and about 400MM cookies worldwide. This is the same number the DSPs and the Ad Exchanges will give you. In essence, everybody says they can reach everybody, and actually, that’s probably true since all the major DSPs are connected to all the major SSPs in a symbiotic relationship to accomplish the same goal – make it as easy as possible to retarget cookies. The numbers can vary somewhat depending on the press release you read, but at that scale, the answer amounts to ‘everyone’.
From my perspective that means reach isn’t really a point of differentiation – inventory quality and frequency are what truly matter. Frequency is likely fairly easy to measure, but you’d have to ask the SSPs individually to get the information – you can get a bit of a sneak peak at Rubicon Project however, they actually tag their entire network via Quantcast. Some advertise the number of impressions they serve per month, but realize that they most likely don’t reach all 400MM users each month, so you can’t just divide total imps served / 400MM – that’s just how big their cookie database is. In fact, most DSPs and SSPs probably see less than 50% of their total cookies in any given month. Even if you could get the true imps served in the month and the uniques seen in a month, there’s likely to be a huge range of average frequency per user, so you really want the mean and median. And generally speaking, the higher the frequency you find, the lower quality the inventory is likely to be.
As I’ve circulated in a few posts on Twitter, I believe 90%+ of the inventory available on exchanges today is what most would consider low-quality. By that I mean it is on no-name publishers, torrent sites, below the fold, adjacent to user generated content, on social media sites, community forums, or other places most advertisers would not place a direct to publisher buy. That means that the SSPs have to have quite a bit of those sites as clients and they’re unlikely to volunteer that information. Brand publishers on the other hand you can get a sampling of on each vendor’s website. Anecdotally, I believe Rubicon is the largest from an absolute impression standpoint, Admeld after that, and Pubmatic to be the smallest. From a quality standpoint it is very difficult to say, each SSP has a handful of very high quality clients, and also likely a long-tail of lesser quality clients.
Hope that sheds some additional light on things –
Ben
Thank you so much for the quick reply Ben. For some reason I was not notified that a response came back into the forum…very nice surprise when I came back around!
It was like coming home in the 90’s to a full answering machine…
In terms of the valuation of an impression, we are certainly trying to understand that very observation of 25% – 100% delta. There is much fodder there to discover. Your comments about reach is helping us think about our problems with better depth to the term. That is always good, thank you. I will go back and dig up some of those old twitter comments as well.
My concern is how “real” that reach translates into creating targeted audiences vs what end up as low quality impressions because of the lack of data points in sync failure . It’s a salient problem, exacerbated by the 90% figure you noted, because you drop lower down the tool set, past contextualized value, and into the bottom of the barrel. I will keep you updated if I think I find something worth sharing.
Thank you again for participating in the discussion. It is a great thing your doing here.
Best,
Oren
Hi Ben,
In the Key you refer to Cookie Stamps / Requests with a Grey Line but this is not visible in the Diagram. Please can you clarify?
Thanks,
Dharmesh
Hi Dharmesh,
You’re right, I missed that – I’ll have to correct later, but that path would be parallel to Step 5, and run between the user and a longer list of DSPs, some of which might be taking place in the auction, and some that might not. If you view the source on each script I reference at the bottom of my post on DSP to SSP cookie syncing, you’ll see that some scripts call out to 15 or more 3rd parties, and I can tell you from experience that there is almost never that kind of bid density on any impression out in the marketplace.
Hope that clarifies, and thanks for alerting me to the error.
Ben
Hi Ben
Great overview of the technical and architectural aspects of SSP/DSP/AdExch/RTB. Thanks! Does your expertise extend to how DSPs assign value to arrive at an appropriate RTB for a given (single) user impression. If yes, can you please shed some light on this aspect of this process. If not, can you point me to a reference which explains the pricing? Many thanks.
Hi Stuart,
Thanks – in terms of pricing mechanisms, there are basically two methods. The first is where advertisers simply enter a flat price they are willing to pay, and the DSP submits that as the bid price for every impression. That’s pretty easy to understand. The second is an optimized method, where each impression is evaluated and valued on a host of factors. Within optimized bidding, most DSPs allow you to pick the metric for which a campaign is optimized. For example, you might what to optimize for CPM (the lowest cost per impression) for some campaigns, but CPC, or CPA (the lowest cost per click or conversion) for others. For either goal, the DSP will conduct a sampling period that varies in length to reach some statistical significance against a variety of factors so it can then predict future performance and bid more aggressively against impressions with the predicted ideal qualities for that campaign. Those factors might be inventory quality, time of day, geography, operating system, frequency, or include other pieces of available data. Each DSP will have its own special sauce to reach a decision, but MediaMath, one of the leading DSPs, actually exposes a bit of their process to clients in the UI. They have an interesting video up on their site that gives you a peek into what factors their system evaluates, and how they reach a decision. Interesting stuff: http://www.mediamath.com/products/ and click on “Brain Visualization”.
Hope that helps,
Ben
Ben,
Thanks a bunch for this, it’s definitely helpful. I have a quick question, how does it work when the publisher sets a floor price and that floor price isn’t met? Does the ssp/exchange redirect the user back to the publisher ad server and tell them that the floor price wasn’t met? Or does the ssp/exchange somehow know which reservation or house ad to show if the floor price wasn’t met?
thanks!
–Gabe
Hi Gabe,
Every SSP or exchange will require some sort of ad of last resort, often called a ‘default ad’ even if there isn’t a set price floor. That ad of last resort could be a house ad, or it could be a call back to the publisher, allowing them to re-decision the ad call with their own ad server, and host those final assets themselves. The best solution is usually for the publisher to hand over the default ad assets to the SSP / Exchange vs. getting called a second time. There are a few reasons for this – first, typically the publisher is using the SSP / Exchange as the ad tag of last resort anyway, meaning there is nothing more valuable to serve at that time from a direct sale, so unless they are hosting many house ads or changing them out on a very regular basis, having to decision the ad twice is redundant. Second, all ad serving carries a cost, even if it is a nominal cost – receiving that call again costs the publisher money. Third, decisioning an ad twice creates duplicative reporting in the publisher’s ad server, inflating inventory figures. The user might only receive one ad, but the ad server counts it as two – once as a redirect to the SSP / Exchange, and a second when the SSP / Exchange calls them back. Finally, if the publisher isn’t careful, they create the potential for an infinite loop – where the publisher ad server calls the SSP / Exchange, which calls them back, which calls out again to the SSP / Exchange, which calls them back, and so on until the ad just fails or the user abandons the page.
Hope that clarifies!
Ben
This is great stuff Ben, many of us are in sink or swim positions on a very fast moving river, thanks for your time answering our questions.
This may be a more basic question, but I am a bit of newbie working largely in the mobile ad space right now.
How do the cookie values find their way into a std OpenRTB object?
Without cookies in mobile I presume this means all requests are treated as those without a sync, this places much more dependence on the app, device and segment object, how are these populated?
Thanks Mark, appreciate your comments.
As to your question, I’m a mobile newbie myself, but I’ll try to give you as much information as I can. While many mobile devices actually do accept cookies, you’re correct in the sense that 3rd party tracking cookies like you may be familiar with in a desktop setting don’t really exist at scale in a mobile environment. Instead, device ID tends to be the user-level tracking standard for mobile environments. Typically publishers or content owners can pull or request this ID from a device with a bit of action script (see this site for more detail: http://www.pocketmagic.net/?p=1662), and then pass the information in a URL string to 3rd parties. Google actually started doing this for their AdMob network in April – http://www.clickz.com/clickz/news/2044496/google-readies-behavioral-ads-mobile-apps A best practice is typically to hash this ID to anonymize it before trying to pass it to any 3rd party, as the device ID is actually considered personally identifiable information because it can be tied back to a real person and is not delete-able by the user. On AdMob, Google anonymizes the device ID. In an app environment, I believe you would simply need to run this action script and then use a software development kit (SDK) to connect with a 3rd party system’s API. You might read over the AdMob SDK Developer’s guide, which details how to pass device ID in the spec – http://code.google.com/mobile/ads/docs/
I would also suggest you read up on the OpenRTB Mobile Specifications here – http://code.google.com/p/openrtb/downloads/detail?name=OpenRTB%20Mobile%20RTB%20API%20-%201.0.pdf You’ll see that the specs show that no device / user IDs are required by the exchange, but are optional values. At the same time, the specs allow those types of values to be passed when available, and can get pretty specific. Generally speaking though, from what I’ve heard there isn’t very much user level targeting on the mobile web right now – it tends to be focused on location, which you can get from the GPS coordinates on the phone, which again, you can call with action script from a phone, and pass to 3rd parties using a URL string on the web, or through an SDK in an app.
If you have any mobile network / technology partners, ask to speak to their developers for more information, who can help you dig in.
Hope that was somewhat helpful, if you find any other sources of information please send them over, I’d love to understand this better myself!
Ben
Thanks for the reply Ben, I am digging into it and will share whatever I find.
Hi Ben ,this post is very helpfull!
I have a technical question. In the RTB scenario where many players interact between them, how is it possible that the RTB communication work quickly?
I mean, we know that the response time to show an ad is critical to optimize inventory in the sites, because the user could spend a short time in the page and this time may not be enough to show an ad.
Could you please explain a little more about how this communication work? or give me a sort of links so I can get more information about this?
Thanks !
Hi Hernan,
Glad you found it useful – as to your question, I’m not entirely sure what you’re asking, but it seems like it could refer to a few things.
First, the bidding process may involve multiple demand side parties – lots of people are bidding on the same impression – but the bid request and bid response process happens concurrently between parties. The SSP doesn’t send a request for a bid to one DSP and then request another bid once it receives the first, it asks all the DSPs at the same time, and gives them the same short window of time (20 – 120ms) to respond. The decision process and ad serving process doesn’t take too long – perhaps 20ms per leg. All told, you want to aim for about 120ms in latency or better through the entire process, though you might expect as much as 400ms in some cases. As you might expect, 3rd party discrepancies – the amount of impressions you track on your local ad server and what your RTB partner reports as served impressions can be different by 10 – 15% as users drop out of the process before it can finish.
Secondly, each bidder already has all the information it needs in order to value the impression, even if it is using 3rd party data to inform that bid, because any 3rd party information on the cookie viewing the impression is already synched to the DSP cookie in advance, in a server to server data pass which I talked a bit about here: Syncing Your Online Data to a DMP. That’s specific to a DMP, but the process is exactly the same, but with the DSP acting as the DMP client in this case, and the 3rd parties acting as the data sources, so in place of the order management system for example.
Hope one of those answers your question – if not, feel free to write back with more specifics.
Thanks,
Ben
Hi Ben, first of all, thank you for the quick response, and for sharing all your knowledge. You were very clear in your response, but I want to go a bit more deeply than that.
When you said that the SSP sends a request to lots of DSPs, is that communication a Server-to-Server connection or simply a query through the web? Also, I assume that the SSP ensures a fast response with the timeout that you mentioned, right?
On the other hand, once we have the value of the impression, you said that the bidders have the necessary information to value the impression. I assume the information is standardized in order to get the same valuation between all DSPs. Also, I imagine that some information would be the age of user, location, etc, do you have a paper that talks about this valuation more deeply?
Thanks Ben!
Hi Hernan,
The SSP to DSP communication works through an API connection, so server to server. The reason being is that each party needs to pass certain variables to the other, so there needs to be a standard framework for how each party sends to and digests data from the other party. Each DSP and SSP operate slightly different, so there is a bit of a manual implementation process required. And yes, the SSP controls the time limit around the bid responses – if a DSP can’t respond in time, the SSP will simply conduct the auction without a bid from that DSP.
In terms of valuing the impression, not much is really standardized. In fact, given the exact same data, I would be surprised if two different DSPs returned the same bid response. On the 3rd party data side, there’s no requirements around data quality – one data provider might return different demographic information on an individual cookie as another data provider. Each data provider sources their information from different publishers, and then segments and qualifies that data into end products slightly differently.
For more information on how DSPs use data to bid at the impression level however, I’ve found this Media Math presentation helpful – http://www.mediamath.com/products/ and click on “Brain Visualization”.
Hope that helps,
Ben
Hi Ben,
This post is amazing! I’m a newbie to this industry and this post helps me a lot. Thank you very much.
I have several questions to understand ad mechanism more.
1. If no SSPs or DSPs are used and only Ad Network is used, is it correct to change the above diagram as follows?
– change “SSP / Exchange” to “Ad Network”
– delete “SSP / Exchange RTB Auction”, “DSP1-3”, “Ad Network”
2. In mobile ad space, especially in smartphone apps space, are there many cases that there are no “Publisher Ad Server” と “Marketer Ad Server”?
If that’s the case, does “Ad Network” solely handle ad information?
3. Is Akamai’s Content Distribution Network working as an image file delivery infrastructure in mobile ad space as well ?
4. I understand that Anonymized device IDs are generally used in mobile ad space. Is this same in smartphone ad space?
5. How can anonymized deveice IDs are matched between SSP and DSP? Is it same as cookie-synching you wrote in the following post?
SSP to DSP Cookie-Synching Explained
http://www.adopsinsider.com/ad-exchanges/ssp-to-dsp-cookie-synching-explained/
Great article, and good drawing. Couldn’t find step (6) in your 12-step process description?
Hi Tom,
Hm, it looks like I excluded that for some reason, thanks for letting me know. Practically speaking, step 6 and step 5 are effectively the same thing. The browser gets redirected to the SSP, which conducts the ad auction process through one of the ad exchanges, which just provides liquidity to the process. If you had a specific question around any part of the process let me know and I’ll try to clarify.
Ben
Hi Jun,
Thanks for writing in! Let me see if I can help answer some of your questions –
1. Not necessarily – you can still use an SSP to optimize revenue between ad networks only, in fact, that’s how all the SSPs originally came to be. They were all founded to optimize ad network demand, before RTB existed. The idea is that the SSP will get the publisher the most money from any combination of DSPs and Ad Networks. Many publishers will have 20 – 30 DSPs bidding on their inventory and a handful of ad networks, all optimized through an SSP platform. That said, the ad network may be optimizing various advertisers itself for its own benefit, but since the ad network doesn’t bid, the SSP usually just ends up optimizing on a blended, effective rate. The benefit to an SSP with a network however is that it can better predict the value of a given impression by ad network , and easily transition from one network to another once a network starts to pass back impressions and etc.
2. I’m not sure about this – in my experience there is always a publisher ad server of some type, even if it isn’t specifically a mobile ad server. Typically, an SDK is in place to allow a 3rd party, like a publisher ad server, or a marketer to control an iFrame in the app, but those ad serving systems are still in place to decision the ad. If the publisher is only working with one network, I suppose they could simply hardcode the call to the network, but I don’t think this is standard for most major content publishers, since most will want to work with more than just one network, and have to have a system to manage that process. Perhaps smaller app developers work this way, however.
3. Yes, Akamai was serving as a CDN for mobile as early as July 2010.
4. I don’t have a great answer for this – some parties have been using device ID (UDID) or the IMEI number as a unique ID for smartphones, but Apple is starting to mask those values in OS5, and there are clear privacy concerns about utilizing a value that the user cannot opt-out of, or control. Cookies aren’t really a suitable option on mobile phones, even if most smart phones can technically accept them, because the cookies are entirely wiped between sessions, which defeats their use altogether. So there isn’t a clear path forward here, at least on mobile web. In the app environment, publishers can force users to register, and use that registration as a way to re-identify the user, and the data they have about that user. This is useful to a degree, but still doesn’t solve the problem of allowing marketers to match the data they might have to that user. The value that cookie-syncing creates in the desktop environment really doesn’t exist, at least not yet, on mobile. Most impressions are instead valued based on CTR, and geo-location.
5. Yes, that’s it exactly – cookie syncing is how that happens.
Hope that helps!
Ben
Hi Ben,
Thank you very much for your reply and detailed/clear description.
For my understanding, I have created a diagram of non-RTB ad networks version.
https://picasaweb.google.com/lh/photo/h6r1d7pR5xAZr_VjzreePA?feat=directlink
I’m afraid this is in Japanese..but I guess you understand easily..
Thank you again!
Jun
Hi Ben,
Your posts are very insightful!! thanks for writing them.
I have a question about the usage of 3rd party data in the real-time bidding process. You mentioned in the post that DSPs have access to 3rd party data which they use to evaluate the user.
“… DSPs are able to match the SSP’s cookie ID to their own cookie on that user, which is tied to a huge cache of marketer data and 3rd party data. What kind of 3rd party data? Using the cookie ID, the DSP will be able to know if that user recently priced out a car, is flying to Paris in the next 90 days, ….”
I have also read on a different post that Ad Exchange supplies the user profile information to DSPs which is originally provided by Data Exchange to Ad Exchange
http://www.krux.com/pro/broadcasts/krux_blog/cookie_synching/
“…The Ad Exchange also looks up the user profile information supplied by the Data Exchange (either through a real-time call to the Data Exchange or in the offline user profile database that is provided by the Data Exchange) and includes that in the bid request also…”
The question is really how DSPs get access to third party data: through Ad Exchange or directly working with those 3rd parties?
Thanks
Hi Ashish,
Thanks – to answer your question, it could technically work either way I suppose, but it makes far more sense for a DSP to work directly with the 3rd party data supplier. First, from a latency point of view, you don’t want a system like the Ad Exchange to have to reach out to a data exchange during the bid process, because it introduces a new party in the system. Secondly, it’s not clear to me how the Ad Exchange would know which data segments to expose for a given user in the bid requests it sends out because a user could qualify for so many. Finally, I don’t know how the data supplier could agree to really work this way in practice, because if their data attributes are being exposed to all bidders, or even a subset of bidders, how would the supplier know if its data was actually utilized?
It seems far more logical for a DSP to work directly with the data suppliers – that way, both parties can agree on pricing and payment structure, the protection of their data with audit rights to monitor or enforce necessary, and the DSP can create a server to server integration with the supplier and just host all the relevant audience attributes for a cookie locally on their server. For me, I don’t see why data suppliers would agree to work in the former scenario, and not the latter.
Hope that helps –
Ben
Hi Ben
As everyone else has said, this is a really useful post, thanks for sharing your knowledge with us all.
Based on the diagram and the way you describe the process, it seems you are saying that Ad Exchanges and SSPs are the same thing? Would you put Right Media or Google Exchange in the same group as Pubmatic or Rubicon? Or is there a difference I am missing.
Thank you,
Amrit S.
Hi Amrit,
Thanks – Ad Exchanges aren’t really the same thing as SSPs, they’re more symbiotic players. Ad Exchanges provide market liquidity between RTB enabled buyers and sellers, they’re simply a marketplace to transact, usually with a basic level of tools. Ad Exchanges are also designed to be more or less agnostic between buyers and sellers. SSPs on the other hand are specifically aligned with the publisher, or the sell side of the business. They provide more advanced tools, and technology that aggregates demand from bidders on the Ad Exchanges as well as non-RTB demand like ad networks. SSPs are technology companies that come with lots of client service support, while Ad Exchanges are really primarily technology companies, designed more for self service, or API connections.
The reason I grouped both together in these diagrams is because a publisher doesn’t have to work with an SSP to get their inventory available to RTB bidders. The SSP is a service layer that works on top of the Ad Exchange, but it’s an option for publishers, not a requirement. I wrote a specific explanation of SSPs here which might also help clarify: http://www.adopsinsider.com/ad-exchanges/supply-side-platforms/
Hope that helps –
Ben
Hi Ben,
Your posts have single handedly helped me understand the complex world of Ad-Ops since joining the industry a year ago. Thanks a lot for them!
For now, I am stuck, trying to figure out 3 questions:
1) What’s the connection between DSPs and Trading Desks. How do trading desks interact with DSPs? And how are they able to “pre-buy” inventory when they still have to bid for it?
2) A SSP is essentially a layer above the Ad Exchange, which helps the Publisher get the maximum yield for itself How does the SSP actually manage to do this?
3) Where does the Adserver figure in this process? Does this make DFA redundant or is its usability reduced to counting clicks only?
Have been scratching my head trying to get a clear picture of the whole ecosystem. Your posts have helped me get a a very fair overview of it. Just trying to fill in the gaps now.
Many Thanks.
Ash
Hi Ashish,
Thanks very much – let me see if I can answer your questions.
1. The trading desks are typically just a service arm within an agency that licenses, operates, and potentially builds on top of a DSP technology. In other words, the trading desks operate one or many DSPs on behalf of their clients, rather than the client working directly with the DSP. The trading desk rarely owns the core bidding technology internally, they license it from a DSP. To the next element of your question, neither DSPs or ATDs can really pre-buy inventory in the typical sense, although that may change in the future with a concept known as guaranteed RTB, but we’re really just talking about business terms. Pre-buy is really just another word for guaranteed placement, which is just a matter of entering budget, and targeting into the DSP system, and allowing the machine to recognize qualified impressions, and buy and serve an ad against those impressions. Whether the technology has a contractual right or guarantee against the inventory or not doesn’t change the technical execution, just the business arrangement between the buyer and seller.
2. The SSP increases publisher yield by auctioning inventory from more demand sources than a single ad exchange can provide. For example, an SSP facilitates an auction across the demand sources from multiple ad exchanges, as well as Non-RTB sources, such as ad networks. By having more bidders compete for the same inventory, the SSP is able to identify the source willing to pay the most for any given impression, regardless of how or where they are buying.
3. The Ad Server is still serving, tracking, and reporting the ad, even in an exchange environment, so it’s the last stop in the path. At the end of the day, the final redirect in the Exchange path is typically to an ad server, which may host an ad tag that can serve on exchange inventory, as well as direct to publisher inventory, or ad network inventory, all simultaneously. The ad server can also track clicks, conversions, etc. It isn’t necessarily redundant, but it can be, depending on the parties involved. Many DSPs can host ads and provide the services of an ad server, but a client may not want to use those services in order to keep their impression tracking centralized in one place.
Hopefully that clears some things up –
Ben
Hi Ben,
I really enjoy your articles and posts which are very helpful to understand the complicated nature of online advertising. I have a question for you and hope you still follow the posts of this article.
You said earlier in your post that “generally speaking, the higher the frequency you find, the lower quality the inventory is likely to be”. Do you mean if you have high frequency cap on your display ads, they are likely to be shown in the lower quality publisher pages? Is there any correlation to these two factors? Please enlighten me.
Mogino
Hi Ben,
Great site and content.
I am putting together an RFP for DSP vendors. Do you happen to have any standard RFP questions or do you have advise on some questions would differentiate the top players from the average vendors?
Thanks,
Rich
Hi Mogino,
I think there may be some confusion, let me try to clear it up. What I mean when I say, “generally speaking, the higher the frequency you find, the lower quality the inventory is likely to be,” I’m speaking about how an ad performs based on the depth of a user’s session. So to put it in plain English, the more pages a user consumes on a website, the less they tend to pay attention to the advertising, so those first few impressions tend to be more valuable to advertisers than the last ones a user might see. In an RTB environment, bidders keep track of how many times they’ve seen the same cookie ID on the same domain, so they know if a user is on their first, fifth, or fiftieth page of their visit, and they also know the more they bid on those first few impressions in a visit, the better those ads will perform from a click rate perspective.
That said, the issue of session depth that I described above is really separate from site quality – the tenth impression on a high quality publisher may still perform much better, and therefore be worth more, than the first pageview on a low quality publisher. Frequency caps don’t really impact where ads are shown, just how many times they can be shown to any given user, usually regardless of how many sites contribute toward the cap, though this isn’t always the case. Tight or low frequency caps tend to drive performance to some degree for campaigns with direct response goals because they control cost, but if you aren’t careful, efficiency can come at the price of scale. Perhaps you can drive a 300% ROI with a very tight frequency cap, but that only allows you to drive a handful of conversions. If however you increased your cap, your ROI might fall to 50%, but you could drive 20x as many conversions, so experimentation is key.
If you are interested in learning more about frequency caps, I’d point you toward another article I wrote on the subject here: http://runofnetwork.adzerk.com/adops/is-frequency-capping-the-best-kept-secret-in-ad-tech/
In any case, I hope that sheds more light on the issue – best of luck!
Ben
Thanks Rich –
When it comes to DSPs, a lot depends on what you need to do with the technology. So as a first step, I would clearly outline your goals – do you simply want to advertise for yourself, or are you serving a broad base of clients? Do you need cross platform support to access mobile and / or video supply, or will display banners do? Do you need to retarget users, or integrate any of your own data, either online or offline into the bidding platform? What about service – do you plan to turn the knobs and dials of the system yourself, or do you expect to have a managed service arrangement?
My point is that you might find that expertise in bringing offline data into the system differentiates systems, but is completely irrelevant to your needs. So nail down what you need first, and go from there. To answer your question though, I’ve found that pricing methodologies, simplicity of the user interface, and client service tend to separate the men from the boys. At minimum, you should insist on meeting the client service team that will support you once you sign a contract, as those folks will be who you really interact with, not the sales people. Second, you should insist on getting access to a demo account, so you can mess around in the system on your own and see how easy or not easy it is to use. Finally, doing a handful of client references is always a good idea, so you can ask pointed questions about any concerns you might have and get an honest answer. What I wouldn’t do is get caught up in the technical arms race – in most cases, things like the queries per second a system can handle, or the number of data supplier integrations the company has completed will have little practical impact on you, so focus on qualitative aspects rather than a quantitative scorecard.
Hope that helps!
Ben
Hi Ben,
Thank you very much for the clarification! Now I understood what you meant and I will study the link you sent me.
Looking forward to your new posts!!
Mogino
Thanks for all the comments Ben. Question: How does an advertiser choose what ad exchange to work with on a mobile campaign? Say for instance an advertiser has a certain demographic/set of criteria they want to reach, and they have a certain budget of 100k. Do they have any say as to whether they will work with AdMob/IAd/Millennial by determining and allocating (say 33% of total spend to each exchange)? Is there a way for these exchanges to attract a greater percent of the spend (i.e. says they will take a lower share of the revs, and hence can bid higher and win better impressions?) Thanks, def confused about the advertiser/exchange interaction.
Hi Ben, excellent articles. I am working of creating analytics to measure web advertisements (both PC and Mobile). This site as really helped me understand the advertisement ecosystem. I have few questions regarding identifying Ad impressions in this whole Ad Exchange process. How do the players on different sides count these Ad Impressions? I believe its done differently by say the publisher and the ad networks, SSPs etc. Is there any way to generalize this measurement for different ad exchanges? I’m interested in getting the CTRs as accurate as possible from captured HTTP headers.
Do you know how companies like Comscore or Nielsen do this?
Saurav
Hi Ben,
Very nice article and other similar posts. Your notes are an incredible source of insight not just for technical but for business issues. Thanks for explaining this ecosystem at this level of detail.
I was hoping to understand how the 3rd party data providers get paid when they integrate with DSPs. I understand that 3rd party data is bought by advertisers on CPM from these providers (eXelate, BlueKai etc). Which means that to raise invoice, eXelate and BlueKai need to know how many impressions were bought against the data. Does this mean that these data providers are completely dependent on reports generated by advertisers or does the DSP create some reporting layer here?
It raises another question if you would answer – how do these data providers then integrate with ad networks to get the impression counts?
Regards
Nitin
Hi Ben!
I enjoy very much your articles.
Can you suggest a DSPs ranking for small companies like us?
Which are the DPSs we should contact with based on their business approach and customer service?
We are looking for transparent access to display inventory and to develop our own purchase algorithms.
Thanks Ben!
Hi Nitin,
Typically the data providers cut contracts with the DSPs that requires the DSPs to measure and pay them. It’s effectively all done on a trust. That said, usually the data providers have an audit right in the contract so that if they suspect foul play, they have some kind of recourse to look at the back end of the DSP to validate their reporting. If things get to that point, the relationship is usually lost though – I’ve only heard of it happening once, and the provider promptly pulled their data from that DSP. The alternative methodology is for the data provider to require any campaign that utilizes that segment to add a tracking pixel from the data provider that calls them every time an ad loads to one of the provider’s audiences. It’s a nice thought, but difficult to scale for most advertisers, so it just creates a barrier for a marketer to use that provider, so most don’t require it.
In terms of integrations, remember the integration happens at a platform level, not a client level. So the data provider integrates with the DSP, which advertisers using the DSP can then access. The DSP controls and can track how their system is used though, and at the end of the day has complete technical control over how the data is used. Similarly, ad networks likely use a platform, or a DMP, which actually does the integration, and provides the network access. You can read more about how that integration / cookie syncing process works here: http://www.adopsinsider.com/online-ad-measurement-tracking/data-management-platforms/syncing-online-data-to-a-data-management-platform/ For your example, you can simply replace Email / Analytics / or Order Management DBs with a data supplier, as the process is basically the same to sync one cookie-based piece of data into another system – for example from a data provider to a DMP or DSP.
Hope that makes sense –
Ben
Hi Saurav,
Well, the article above tries to explain when and how each system counts an impression – each system basically counts an impression when it receives a call. The reason the impression counts might differ between systems over thousands of calls is due to latency between systems, perhaps lack of cache-busting, a user abandoning a page before it can fully render every call, and other things like that. In fact, here’s an article on what can cause discrepancies between ad serving parties: http://www.adopsinsider.com/online-ad-measurement-tracking/resolving-3rd-party-discrepancies/
Comscore and Nielsen use the same methodology, and are victims of the same technical limitations – system discrepancies are just a fact of life. That said, the counts from the last system in the chain, usually the advertiser, are typically the most accurate to the real-life user experience, assuming that things are correctly implemented and there isn’t a cache-busting issue or something like that. In terms of measuring CTR though, think of it this way – whatever system you use, as long as everything was implemented correctly, you should be reliably off, meaning you probably won’t make bad decisions because the discrepancy of the system on a single flight outweighs the true performance of the unit. While I suppose you can say it will be directional vs and exact figure, the ‘right’ number is really a function of how you define what the right system of record is for impression counts. Publisher argue they are, advertisers will argue they are, and networks and exchanges will say they’re the right system, too. The advertiser usually gets their way since they’re the ones paying though.
Hope that helps –
Ben
Hi Guillermo,
It depends how small you are – unless you’re planning to do thousands of dollars a month though, you’re probably better off using an easy self-service tool like Google AdWords for display. If you think you’ll be doing more like $10K+ per month, you could start to look at tools like Appnexus, Turn, MediaMath, Triggit, X+1, Invite Media, etc. Appnexus and Turn will likely let you bring your own code to the party in some way, and the others may too, I’m just not as familiar with them. Seriously though, unless you are spending some real money on a regular basis, it’s probably a waste of time to go through the effort of trying to build on top of an existing platform. You won’t get the support to integrate it properly, and you won’t extract any meaningful efficiencies from your code. These companies have brilliant programmers that are singularly focused on building smart optimization tech; unless you have similar resources or very specialized KPIs, you’ll likely just get in the way of the core algorithm.
Best of luck!
Ben
Sure – chances are an advertiser doesn’t work with an exchange directly, regardless of the channel, but relies on a network or DSP to buy on their behalf. They likely spread budget among multiple supply sources depending on their needs and how much they want to spend, and then the network or DSP figures out which impressions to buy via the exchanges or in mobile, more likely with publishers directly at this point. Don’t get caught up in the exchange, it’s just a gateway player that facilitates liquidity and transactions. It’s kind of like asking what the relationship between an investor and the NYSE is; changes are, not much because they buy through a broker like E*Trade or something, and same thing with the seller. The exchange is almost invisible to the user; it’s the technology platforms like the DSPs, SSPs, and Networks (the E*Trades in this case) that have to worry about the exchange.
In terms of getting more money, it’s all about performance and relationships on the buy side service provider front. For the exchange, it’s usually about how much scale they bring to the table. I don’t believe the prices are meaningfully different for any of the exchanges.
Hope that helps –
Ben
Hi Ben,
Thanks for the detailed explanation and the quote on the one failed relationship. Fully understood your views.
Regards
Nitin
Hey Ben – This was an awesome read. I have been reading bits and pieces at various places but never got such a good grasp of the process before reading this. Thanks a ton.
Thanks Rohit, I’m glad you found it helpful!
I have AdBlock on my browser, so does RTB matter to me?
Well, as someone who makes their living from digital ads, of course I have to encourage you to reconsider your use of AdBlock. Many of the services you enjoy online keep their business running only through the revenue they make off ads, so if everyone used AdBlock, a lot would go out of business. But, stepping off my soapbox to answer your question – the answer is probably it doesn’t. My understanding is that AdBlock prevents 3rd party cookie dropping, so it likely prevents most of the data collection you might otherwise encounter, as well as the actual ad creative you might see that leverages your prior shopping or browsing history.
In general, AdBlock is kind of a fascinating topic in the advertising world; fortunately not many people use it, but I do think it says something about the crumby experience to which we as an industry have subjected consumers. Annoying ad creative and misleading ad placements to generate clicks are saying the industry is setup to measure value by explicit actions, and that creates an incentive for ads to work a certain way. I think most large publishers are pretty responsible in finding a balance, but many of the small publishers in exchange networks are compelled to choose between user experience and revenue. Most of the shakeup happening in RTB is actually forcing large publishers to think more like smaller publishers because the cost to click ratio is hard to ignore when most marketers remain so obsessed with click through rates. In a way, it’s kind of embarrassing that I have to ask you not to use AdBlock at all, but probably not an experience that will change without better ad experiences.
But I digress…
Does anyone know of an online resource diagramming the mobile rtb process similar to this?
Hi Adam,
I know you wrote in a long time ago, but I thought you had a great question, and since I couldn’t find the answer either, I decided to write it up myself. I posted the article about a week ago: http://www.adopsinsider.com/ad-serving/how-ad-serving-works-mobile-vs-web-environments/
Hope you find it interesting, even if it’s probably too late for your purpose at the time.
Regards,
Ben
Hi Ben,
I found this very informative! Any plans to release a similar a technical explanation of how things work for mobile RTB?
Ethan
Hi Ethan,
Glad you found it helpful – I actually just recently published an article that describes this process in mobile at a high level, and contrasts it with desktop: http://www.adopsinsider.com/ad-serving/how-ad-serving-works-mobile-vs-web-environments/ Hope you find it similarly helpful.
Regards,
Ben
Hello Ben, thank you for your post – really helpful! Where does an advertiser DMP (bluekai et. al.) chimes in? Is it connected to the DSP? And how does it talk to the advertisers adserver? Thank you. Dirk.
Hi Dirk,
Perhaps a bit of a complicated answer for you – DMPs serve both publishers and advertisers, so they could theoretically fit in a few different places on this diagram. First, if a publisher was using a DMP, it might be connected to the publisher’s ad server, where the publisher might choose to pass various audience variables to the SSP or Ad Exchange. That’s probably a rare use case in the industry for now, but it could happen. Similarly, an SSP may choose to work with a DMP; either in partnership with a publisher, or independent of a publisher to do the same thing – add value to an impression by enriching it with audience data.
I think what you’re more interested in though, is the advertiser side of this. And in that case, yes, a DMP would most likely be connected to a DSP. That’s actually the most likely use case of a DMP in the RTB ecosystem in my opinion. In that case, an advertiser would work with a DMP to house audience data, create proprietary data segments, and then sync those segments from their DMP platform to the DSP’s platform so that they could bid on media against those audiences specifically. In rarer cases (though it’s a popular use case of the Adobe Audience Manager platform), the DSP would bid on an audience and then the advertiser’s ad server would then select or create a specific piece of creative in a dynamic fashion for that user by leveraging what it knows about the user, according to the DMP. Meaning, once the DSP decides to buy the impression on the advertiser’s behalf and gives the user the redirect to the advertiser’s ad server, the advertiser’s ad server may query the DMP, and decide to serve a blue ad vs. a red ad based on the data known about that user specifically.
For example, a hotel company might be bidding on an audience segment that just bought an air ticket in the last few days. But for the people it knows bought a ticket to a tropical destination, it wants to serve a beach ad, whereas for the people it knows bought a ticket to a snowy destination, it wants to show a ski themed ad, and it could leverage the intelligence in the DMP to do this.
Hope that makes sense – you might also be interested in these posts on my site, specifically about DMPs: http://www.adopsinsider.com/online-ad-measurement-tracking/data-management-platforms/what-are-data-management-platforms/ and http://www.adopsinsider.com/online-ad-measurement-tracking/data-management-platforms/data-management-centralize-and-synchronize-your-user-data/
Kind regards,
Ben
Hi Ben! Thank you for this. By far the best explanation on the subject online. I had one question regarding your comment above to Dirk.. Do you know of any service that a hotel can use to target people who have bought flight tickets online? E.g. a user buys flight ticket on XYZ.com – and then when the user visits ABC.come he/she sees the relevant display ad from my client(hotel). Would be great if you can let me know.. Thank you!
Hi Arjun,
Sure, this is pretty much exactly what the major data brokers offer in their Travel category, though you may not be able to get as specific as you’d like. BlueKai, Lotame, Exelate, and others would likely have segments you could buy integrated into the major DSPs. BlueKai for example notes on their site that their travel catalog includes options based on “departure/destination city, length of stay, air travel, hotel, rental cars and brand”. Sounds like that would be a good starting place for you – good luck!
Ben
Thanks Ben for this great post. Just to confirm, does the bidding process actually occur between different servers, or is it done automatically inside the exchange (like the automatic bidding in eBay)?
To clarify, if I’m an advertising willing to pay x dollars per male user aged 20-30, what actually happens when such a user visits the website? Does my DSP send a separate bid to the server each time this occurs, or does the DSP just send my bidding policy every time I update it, with the actual bidding conducted entirely on the exchange server?
Hi Jonas,
The DSP would send a separate bid for each unique impression that user would create on a given website. Think of it this way, websites broadcast inventory opportunities via an SSP and the DSPs sit back and listen to this endless stream of opportunities. When they find one that matches a customer’s criteria (like men 20 -30 on your campaign), they send a bid back to the SSP.
The SSPs actually never know how many campaigns are running at any given time with any DSP, and they never know why a DSP bids on one impression or the other. Meaning, if there is a male user 20 – 30 in New York State on example.com at 2pm on a Tuesday, the SSP doesn’t know if you’re looking for Men in New York, example.com inventory, 20 – 30 year olds in the afternoons, or any other permutation you can think of, they just know that DSP A will pay X for this impression. Actually, a fair bit of the optimization algorithms on the SSP side try to figure out what it is that makes an impression valuable or not to a buyer, since it isn’t declared to them.
Not the caveat to this would be in the case of private exchange deals, where the buyer would be more upfront with a seller about what they want to buy, but that’s not really a technical item; it’s more something the buyer tells the seller over the phone so the seller can just send what’s relevant to the buyer.
Hope that helps –
Ben
Hi Ben, thanks for this article! I pulled a report from a campaign running on a DSP, and i’m categorizing by device type. Most impressions are labeled in PC, mobile, tablets, and an option that covers all other devices called media center. I am getting a number of impressions that are not within any of these categories, in which device type is simply blank. Would you know what causes this to happen?
Thanks!
Hi Gaspar,
It’s hard to say without knowing a bit more information – I imagine your DSP would be better suited to answer this question, though, since the data comes from their system. If I had to guess, I’d think media center aligns to either video on demand (so served to a TV), or some other video player where the devicetype cannot be read in the header request because the call comes from the software and not the user. But that’s just a wild guess – I’d see what your DSP says.
Ben
Hi Ben,
This is an amazing article. My understanding is publishers sell their inventory with an SSP. Buyers can bid on that inventory via a DSP. Where I’m confused is the role of ad exchanges. Also what is the difference between RTB and ad exchanges and what are their roles in this process? If there is any video which can explain this process? Also, is there any source where I can get the list of SSP, DSP, Ad exchange and RTB and their connections, like which SSPs work with which ad exchanges?
Hi Ketan,
You are correct that publishers sell inventory via SSPs, and buyers can bid on that inventory through DSPs. What you should understand though is that SSPs and DSPs are optional parties in the RTB process. That is, they optimize selling or buying, but they aren’t required for the auction process to happen. In fact, buyers and sellers can just work directly with an exchange to buy or sell inventory – Google’s AdX is a good example of where this happens on a large scale with many buyers and sellers not using an SSP or DSP.
This is a confusing space, because you can think of SSPs as exchanges as well – an exchange is simply a party that clears a transaction by connecting buyers and sellers. That is the exchange’s role in the RTB process. You might think of it like a stock exchange – the NYSE exists to bring buyers and sellers together, but does not represent either side. It just provides a forum for transactions to happen, and provides liquidity to the market. Now if the exchange helps optimize that transaction on behalf of a seller, the exchange can also be considered a SSP. DSPs only bid, they do not aggregate supply, so an ad exchange can sometimes be an SSP, but it cannot be a DSP. In terms of a video, Google made a pretty good one that you can watch here: https://www.youtube.com/watch?v=NoGgLxky1FE
To my knowledge there is not an exhaustive list of SSPs, DSPs, Ad Exchanges, and who’s connected to who, but the Lumascape would be a pretty good place to start, and will identify the largest players for you: http://www.slideshare.net/tkawaja/luma-display-ad-tech-landscape-2010-1231
Good luck!
Ben
Hi Ben,
With the ad landscape moving to a programmatic environment instead of the traditional IO media buying process, how do you see the traditional Ad Ops role transforming and what skill-sets should that person start learning now to stay relevant?
Thanks,
Sean
Sean, this is a really great question, and something I’ve been thinking about quite a lot lately. In fact, I’m planning to do a whole post on this topic very soon. But to give you a sneak preview, I think in the mid-term, the most valuable people in Ad Ops are going to be those who have experience implementing and integrating many different systems, and that’s true for the publisher or advertiser side of the business. If you want to run a modern enterprise you’re going to be dependent on a lot of systems and partners, and if you have a strong POV on who to work with, why, and what the end value and use cases are for these systems, you’ll be in much better shape than many. I think about the future of ad ops as being technical strategy + project management.
In the short term, people who understand how to make ads work in mobile and video are going to be really important, but like display, I don’t think that will seem too special for much longer. If all you can do is traffic ads and run the day to day operations, you need to find opportunities that let you explore some of the tough challenges facing our industry right now – viewability, programmatic direct, holistic ad serving, responsive design, these are problems people will pay for help to solve in the next 12 – 36 months. Get those right and you’ll be well positioned to tackle whatever happens after that.
Just my two cents –
Ben
Thanks Ben. That all makes sense.
Hey Ben,
As a follow up to your answer, are there any free to use platforms or systems where one can learn those aforementioned skills? I’m in agreement with what you outlined to ensure a future in adops, however some of us may not be so lucky to get a chance for first-hand experience in our current workplaces.
Thank you,
Hi Sean,
So I don’t think there are going to be any well organized ways to learn those skills – in other words there’s no course I’m aware of or Codecademy like sandbox. But, most vendors in the space have public documentation and test tags, and if you were willing to setup your own site (which is a piece of cake these days), you could mess around with it a bit. At the very least you should read the IAB specs that are out there on things like Video (http://www.iab.net/guidelines/508676/digitalvideo/vsuite) where you can often find test tags, or at least see how the code is supposed to function. The hard part about any sort of test tags is that they’re going to be dead simple and definitely work. As you probably know, the ability to troubleshoot errors makes a big difference and I don’t expect you’ll get much in the way of debugging skills, but at least you’ll understand how they are supposed to work. But that’s why these skills are going to be so valuable; the only way to get them is hard won experience at an early mover company. You may not work at the most cutting edge place around, but I’d bet you aren’t stuck in 2005 – volunteer to work on the new projects, tell your boss you want to be the subject matter expert on a vendor. Almost no one is going to be a jack of all trades, so having experience on any of the topics I mentioned will be valuable to you.
Good luck!
Ben
Hi Ben. Great post. Super useful.
I was just wondering how DSPs get data and how targeting works within them? You have probably answered it within the text but I couldn’t quite grasp it yet.
Hi David,
DSPs can have data about users in many different ways – sometimes their customers, the marketers and agencies, will provide it to them directly by hosting a DSP tracking pixel on their site. For example, the shopping cart page and thank you page tends to be a popular place to put a DSP pixel, because the users who get to the cart page but never make it to the thank you page are a good segment for retargeting. Other data might come from 3rd party data suppliers, like BlueKai or Lotame, which compile behavioral datasets from their own network of partners. Those might be general segments like age / income / education level, and so forth. Publishers might pass data directly to the DSP in the bid request – for example, what kind of content the user is reading. And finally, the DSP itself may be able to know certain pieces of information about a user, just from its position in the market. For example, user frequency is a valuable bit of data that the DSP knows because it sees bid requests across publishers for the same user, and it can understand how ads bought on the same publisher for other campaigns have performed.
Hope this helps –
Ben
Hi Ben
Such a great post, a lot of useful information. I have one question, let me know if you could help me with that:
We’re having a lot of discrepancies with one of ours partners (a rich media mobile app vendor) and they’re saying the problem is because they count the ad as servable when our DSP send the bid info (among with the ad) to the exchange. I’m fairly sure this is a wrong counting way because there’s a possibility to not win the auction and then don’t serve the ad, but not a 100%.
Do you have any comments about it or some extra info?
Thanks a lot,
Hi Brian,
Hm, not sure I follow, but it sounds like you’re saying the partner counts an impression when your DSP bids (vs. strictly when they bid, win, and deliver the ad)? Industry guidelines (MRC ad server certification, for example) would certainly say that you should only count an impression when the ad is delivered to the user. I would think the discrepancy would be enormous if they really did this and seems hard to believe. If you can provide additional details or context I can try to advise more.
Ben
I am new to the RTB world. Had a question on the data exchanges. Where or who maintains the data exchanges of user profiles that the RTB process draws upon to target their customers?
Hi Chris,
Different companies host what are called ‘match tables’ which is a database of cookie IDs between two systems. This isn’t a particularly structured thing though; different companies who want to work with each other simply agree for one or the other (or sometimes both) to serve as the match table host. Typically the one who hosts the match table charges the other company to share the hardware cost for the service. That said, there are some companies that have especially large match tables – LiveRamp comes to mind in particular. Many companies work with LiveRamp as a kind of identity gateway that can help move a user segment from between any major ad tech company because of their large match table.
Hope that helps –
Ben
This is one of the best article…. Thank you so much!
I am learning AdTech ecosystem and this is super useful and easy to understand…
I have few question which are more about Video Ads….
1) Do I understand that the RTB flow which is explained here works the same way for video ads as well?
2) I read about different ad types (VAST – pre-mid-post / skippable / companion etc.). So who in this workflow decides if an ad will be a pre-mid or post, whether it can be skipped or not etc.?
3) Can publisher decide this (#2) for website’s video ad units / placement?
4) What kind of information we receive from a video player request?
Thanks again!
PJ
Thanks PJ!
Here are answers to your questions –
1. Yes, there are some other technologies working below this layer, like a video player for example, but it’s basically the same high level partners.
2. The publisher would decide where in the content an ad would play and if the ad is skippable or not.
3. Yes
4. I’d look at the most current OpenRTB spec; as of today the draft version of 2.5 is out on the IAB’s website here: http://www.iab.com/wp-content/uploads/2016/11/OpenRTB-API-Specification-Version-2-5-DRAFT_2016-11.pdf Look at 3.2.7 on page 16 specifically. There are perhaps 15 – 20 variables unique to video that are proposed. There are other relevant sections as well, like 3.2.16 which apply but aren’t necessarily unique / specific to video.
Hope that helps –
Ben
after the advertiser wins. from where the ad comes and displayed on the publisher website