In our last post we quickly sketched the basic mechanism by which most mobile content and service providers fetch ads from AdMob using our server-to-server ad request API. We also mentioned that we support ad requests made directly from mobile browsers via Javascript, a mechanism that should be immediately familiar to those with experience running ads online. We didn’t go into details about this second way of requesting AdMob ads, not because we don’t love Javascript ad requests or the more-capable handsets that support them. Quite the contrary. If we had our way, every handset in the world, right now, would be as capable as the iPhone and its brethren.

The big question that we didn’t resolve last post is “Why do you need a server-to-server ad request API in the first place?” A fine question indeed, and one with a multi-faceted answer. Before we dive into the answer though, let’s start by throwing out a non-factor.

Our server-to-server ad request API isn’t a technological differentiator. Our ad business is all about optimally connecting advertisers and mobile consumers. How the ad gets requested is more-or-less immaterial. We have a couple of ad request mechanisms now. We will surely add more in the future. For instance, if the mobile ecosystem collectively switched over to browsers whose primary scripting language was Haskell and used VRML for content markup, we would probably ship a Haskell ad request API and VRML-tailored ad units. Proud as we might be of such a request API written for the programming tool of choice to discriminating hackers, it still wouldn’t be a technological differentiator.

Now back to the question: why do we currently need a server-to-server API for mobile ad serving?

First and foremost, the vast majority of handsets on our mobile network don’t support Javascript. Javascript-capable handsets are growing in popularity. But the price points of these devices right now place a rate limiter on their world-wide adoption. Within a scant few years Moore’s Law will result in mobile devices that are even more powerful than today’s überhandsets and that are at the same time cheap enough for most of the world’s population to afford. That promise is one of the reasons we’re so excited about mobile. Today, however, we still need a server-to-server ad request mechanism.

Second, but still crucial, today’s mobile data networks are nowhere near as fast and reliable as the broadband networks most of us use for our day-to-day Internet activities. The last hop on these networks–the wireless one out to the handset–is typically the slowest and least reliable link. Consequently, we need to use this resource very carefully. With Javascript ad requests originating from the phone, we essentially have an extra round trip over this last hop. Because of this ads may load slower or might get dropped altogether. That can in turn slow down rendering of a site’s main content or even leave rendered pages in an unreadable state. Neither is an awesome experience for the user.

On the other hand, with server-to-server ad requests for text ads, there is no ad request round trip over the wireless hop to the handset. The ad is already bundled with the content payload. Ad retrieval takes place over the Internet, typically over networks whose slowest link is substantially faster than residential broadband. This saves the handset from having to make a DNS lookup, and opening and subsequently closing a TCP connection to the ad server for retrieving the ad. Over a slow wireless network, eliminating these things can be a huge performance win and results in a superior user experience.

–Kevin Scott, VP of Engineering