Mobile Advertising: The First One Second
Mobile advertising is a huge and complex industry. But have you ever stared at a banner ad on your phone, and as it animates, existentially ponder the underlying mechanics? Indeed, much of the background work goes unnoticed to most, if not all, of us. See, mobile advertising involves a lot of bits and pieces — frontend, backend, mobile, a market/exchange, and much business decision-making. Not only does the logic need to execute blazingly fast, it has to also scale globally. All of this, from A to Z, need to take place in as much as a few seconds, or the business will miss the opportunity to capitalize. The first one second has more significance attached in that it marks a window where an ad should go on screen. Which is why it’s important to know what happens during this timeframe.
Let’s take a step back. Historically, opening an app and seeing an ad is effortless. That process is at most incidental. You don’t have to do anything, and there goes an animating banner ad. Or a full-screen (interstitial) ad. In fact, mobile users don’t have many choices — an active app subscription is needed to remove ads. You will start to expect that to be the case on most apps. In fact, we have conveniently evolved to stop thinking about how mobile advertising works, so much so that we assume it as all-pervading. That is much akin to other things we take for granted — electricity, water, other utilities, etc. They are everywhere, and yet nowhere. No one has ever asked how water works so that they could use it to wash their hands. Similarly, we walk into rooms, flip a switch, and the lights are on. The background work happens when we don’t think about it, and we expect it to be ready. Mobile advertising? It works the same way. As you use your favorite apps, money is made in the background. And the process needs to start quickly — before the user expects it.
Mobile advertising represents a major paradigm shift in computing. Historically, most of the world was desktop-first, and mobile-second. On desktop, some resources can be wasted at the expense of others, and no one would really nitpick that. On mobile, not so much — every bit counts, and every millisecond matters. While the two most popular mobile operating systems in the world — Android and iOS, have evolved to pack more functionalities at the operating system level, a good segment of global mobile users are still on 2G connections and suboptimal hardware. Smart networks and publishers know how to efficiently target this audience and deliver beautifully-designed ads at the same time. They do that with a head start.
The first second
Start with an ad SDK (Software Development Kit) at 0:0:0.000. SDKs need to be lightweight, often a few hundred KBs once compiled. Modularized SDK works best if only a specific ad format is needed. If the SDK can leverage existing resources already existing on a phone to initialize itself, it will have a head start before it is actually needed. Often, initialization is a warmup process — allocating memory, and instantiating ad objects, among others. It should not create overhead since that negates the benefits of a head start. A silent initialization is best when the user least expects it. Most SDKs have a method call along the line of “SdkName.init()” that sufficiently handles this initialization behind the scenes.
An ad needs a container to house it, and containers need an Android activity/fragment or iOS view controller to host it. 50 milliseconds in, at 0:0:0.051, the latter is created (drawn) when the user launches the app. Now that the hosting activity / view controller is on screen, an ad container (typically a view native to the OS) needs to be allocated — either via a UI or programmatically. This container is actually not quite where the ad sits. Ads are primarily consisted of raw HTML/JS/CSS markup that needs to be rendered in a browser. The lightweight equivalence of a browser that has an API is a WebView. The ultimate view hierarchy chain we need for a basic banner ad is (from the outer layer): activity / view controller → ad view (“container”) → WebView → raw ad markup rendering into an animating banner image. So far, half of the chain has materialized in as minimum as 50 milliseconds. The WebView, though, is not created until further on when we receive an ad response (said markup) from the ad server, which doesn’t happen until we send an ad request.
At 0:0:0.051, the SDK crafts (not sends) an ad request. An ad request is a network ping that goes out over the network, carrying with it information about the device/user it originates from, and asking if the server has an ad. As device information (location, carrier, etc.) is being queried and crafted in the ad request, it takes 5 milliseconds to be gathered. Of course a lot of that depends on how fast and capable the sensors are, it goes back to having an early SDK initialization to cut back on that. At 0:0:0.056, the ad request leaves the phone. At the same time, we register relevant listeners/callbacks and attach them to the ad object, so that we stay informed of the ad’s lifecycle events (load success, load failure, click/expansion, collapse, etc.).
Once the ad request arrives at the ad server, additional backend logic kicks in to leverage ad inventory and supply and determine how best to serve this particular request. Several constraints, including audience targeting criteria, need to be optimized and satisfied. From a developer’s perspective, this can be treated as a blackbox. 213 milliseconds later, at 0:0:0.269, the ad server responds with a valid creative markup. The markup typically is an HTML document. It can optionally has CSS and JS depending on the advertiser’s preferences.
When the ad server responds, the ad SDK parses the ad markup and determines its ad type. For example, if the ad type is an HTML banner, the SDK will invoke its corresponding HTML banner code to render this banner. If the ad type is an MRAID banner, the SDK’s MRAID banner code will be called to do the rendering and tracking. So on and so forth. Several hundred milliseconds later, towards the 1-second mark, the ad’s loaded lifecycle event that is registered earlier will be fired. This notifies publishers that the ad has been loaded into the WebView and is ready for presentation.