Programmatic versus RTB, and you've probably heard both these terms you may have heard them use interchangeably, but there is a difference between the two. So let's break it down. programmatic to start with to automate the decision making process of media buying by targeting specific audiences and demographics. So as I mentioned earlier, programmatic is just an automated way of buying and selling media, anything that automates the process would fall under the programmatic umbrella. RTB or real time bidding is a means by which advertising inventory is bought and sold on a per impression basis via programmatic instant, instantaneous auction, similar to financial markets. So RTB real time bidding is the process by which a programmatic buy is executed.
Programmatic is the umbrella term for the automated process by which that takes place I want to talk about integrations, programmatic integration types connecting supply to demand. First one is RTB in one apologize for tech savvy. There's no real better way to do that, though. RTB, we just talked about our TV. Well, that is actually a type of integration does a server to server integration or an API integration API's Application Programming Interface. Essentially, it allows two servers to talk to each other in real time, server to server connection, which allows the demand partner DSP to efficiently connect to the supply partner SSP via an API connection.
The RTB connection standards are set by the IAB which means anyone who's doing an RTP or server to server connection, any DSP that wants to connect to an SSP through an exchange has to follow the same guidelines. So I tell everyone is able to play nice in the sandbox all connect to each other. They're all yours. Using the same set of standard terms, it does require more upfront work. But that will allow for greater flexibility and faster decision making. Once you have that connection set up, if you want to change it if you want to change the ad size that you'll allow if you want to change where that ad placement is going to run, if you want to change the pricing model that can all be done on the back end, automatically updated through this connection.
No additional engineering work is needed. The second one is tag based. This is using an add tag to connect to a demand partner or check the demand partner to a supply partner. It is quicker, quickest way for a supply partner to add new demand does require little testing to make sure every tag is compatible with an ad server and every tag works. There's more opportunities for a tag to be incorrect or to not work. And there's more limits to it.
So if you do a tag based integration, let's say you have four different ad spaces on your site, you need four things add tags, each identifying the size of the ad unit where it's located, how much you want to get for it with an RTB connection, you would set all that up on the back end, you wouldn't have to do any manual work. And you don't risk a tag not working a tag based situation, you may get four tags, one of them may be broken, you have to test everything and find out what happened. So it's quicker, but it is less efficient. And finally, SDK, which is applicable only for mobile apps, but that is when a mobile app will actually take the software from their SSP or DSP or whoever they're working with, and integrate that into their app, sharing all their data. So it allows the demand partner to collect the most amount of data and allows for sophisticated ad ops developers to customize the programmatic process.
If you have a really good ad ops team, really good engineers, once they actually have the software that does allow them to To create some custom integrations, have couple SDKs talk to each other and work to each other. Things can get very, very complicated from there with the right engineering and the right skill set. It's similar in efficiency to RTB takes more work upfront, but once it's done, it is more efficient.