The Life and Times of AdMob Engineering

One of the most frequent questions that we get from technical folks is, “How is mobile ad serving different from online ad serving?” There are many things that are different between these two worlds. Each has a different mix of markup languages, different user interface constraints, different browser capabilities, different types of networking infrastructure and protocol quirks, etc. The difference that’s often most surprising to engineers however–especially ones familiar with online ad serving–is the basic mechanism by which ads are requested and delivered.

In the online world the browser is most often responsible for both fetching and rendering ads. The content owner modifies the markup of their content to include placeholders for ads. The placeholders are often called tags and take the form of a bit of Javascript code or a clickable img tag. When the browser loads a document containing ad tags, it executes some Javascript and/or starts an image load in order to fetch each ad.

In the mobile world the browser is most often only responsible for rendering ads. The content owner typically modifies their application servers to request ads from a mobile ad server. The application server copies returned ad(s) into the appropriate place(s) in the content that they’re preparing to send back to the mobile phone. When the phone receives the page that it requested, the document already contains ad markup ready to be rendered.

The diagram below illustrates a single mobile request for a page with ads.

  1. A user navigates to a new page causing the mobile device to send a request to the carrier gateway asking it to retrieve the specified content.
  2. The carrier gateway forwards the request on to the content owner’s application server via HTTP.
  3. If the requested content contains an AdMob ad, the content owner’s application server bundles up some information about the request context and sends an HTTP ad request to AdMob.
  4. AdMob parses the ad request, finds all ads that could possibly match the request, ranks the ads, selects the top ranked ad and sends the ad back in the markup language appropriate to the requesting device.
  5. The content owner’s application server copies the returned ad into the appropriate spot and returns the content + ad(s) to the carrier gateway.
  6. The carrier gateway forwards the content to the user’s mobile device.

This isn’t to say that every mobile ad request uses this request and delivery mechanism. Some mobile ad requests look an awful lot like their online brethren. For instance, AdMob has a special version of our ad request code for the iPhone. The iPhone code is a bit of Javascript that gets installed within content markup and makes the browser responsible for both fetching and rendering the ad.

We’ll continue this article next week with an answer to the obvious follow up question from this post: “Why do you need to do things differently on mobile?

One Response to “Mobile Ad Serving Mechanics – Part 1”

  1. User links about "admob" on iLinkShare

    [...] SereneDarkness 4 days ago2 votesMobile Metrics Report: July Data>> saved by aym35 18 days ago1 votesMobile Ad Serving Mechanics – Part 1>> saved by missay 29 days ago5 votesNobody Cares About Android>> saved by germanmoreno 30 days ago5 [...]

Leave a Reply

You must be logged in to post a comment.

Copyright © The Life and Times of AdMob Engineering. All rights reserved.