I’ve seen a lot of AdMob [admob.com] ads in iPhone applications over the past two years. But recently I downloaded two free — i.e. ad supported — applications that appear to use a Google ad server (of course Google purchased AdMob but I don’t think it’s just a re-branding I think it’s a different service.)
I noticed this for two reasons. First; for the past few years I have been working in the mobile advertising space, so this stuff stands out. Second; the ads were odd.
Why odd? Well, as I mentioned these were ads in iPhone applications. Keep that in mind and take a look at the ads:
The issue, I think, with these ads is they are all for competitors. I can excuse the SingTel ad, I’m a Starhub customer but this is an add for enterprise services and the ad was served while I was on a WiFi network, so there is not much chance that Google could have determined my operator.
However, the ad for Android and the two ads for the Ovi store — which sells applications that work on Nokia handsets are not useful to me as a consumer and most likely a waste of the advertisers money. The odds that I am going to patronize either of these services from my iPhone is next to zero.
And there is little excuse for this. When I was working on requirements for a mobile advertising system the product team was adamant that it include basic relevance filtering. Now relevance filtering is complex and the simple business rule “the advertisement should be relevant and useful to the consumer” actually breaks down to a lot of technical requirements. The technical requirements of significance here are:
- Requirement 1
- The system shall attempt to retrieve the
User-Agent
header from the HTTP request. The header should be used to reduce the pool of relevant banners by removing banners that:- have a User-Agent whitelist that does not include the User-Agent retrieved from the HTTP request
- have a User-Agent blacklist that does include the User-Agent retrieved from the HTTP request
- Requirement 2
- They system shall allow buyers to construct a whitelist or a blacklist of User-Agent strings which for specific campaigns or banners in a campaign.
- Requirement 3
- User-Agent lists (white- or black-) should be constructed of strings entered by buyers by selecting full User-Agents or pre-coded regular expression from a list or entering an arbitrary regular expression.
(Obviously there are a lot more details and other requirements that need to be clarified before you can actually implement this.) Here’s a use case that would prevent the issue of the Ovi banners being shown to me on my iPhone.
- Use Case:
- Setting up a campaign level whitelist, to filter out non-Nokia handsets.
- Pre-Condition:
- The buyer has created a campaign
- The buyer selects Relevance Filtering from the interface
- Post-Condition:
- A new filter is added to the campaign level whitelist for the selected campaign
- Scenario:
-
- The Buyer selects Create/Edit Whitelist from the Relevance Filtering menu.
- The System loads the Relevance Whitelist interface
- The Buyer selects the Filter Campaign checkbox
- The Buyer clicks on the Add Filter button
- The Buyer selects the Manual Filter filtering method
- The Buyer enters
*nokia*
in the Manual Filter textbox and clicks the Case Insensitive checkbox - The Buyer clicks on the Test Filter button
- The System displays a list of all matching User-Agent Strings, highlighting the match(s)
- The Buyer clicks on Confirm Filter button
- The System adds the filter to the campaign level whitelist in the Database for the selected campaign
So now the Buyer (in this case Nokia or an agent acting on Nokia’s behalf to setup the ad campaign) has created a campaign level whitelist (i.e. all banners in the campaign will be filtered by this whitelist) which includes a filter of *nokia*
that is case insensitive. This means that, based on the requirements enumerated above, that no ad request that includes a User-Agent string that does not includes the word nokia
in it will be served any banner from this campaign. The effect? Ovi store ads will only be shown to users who are using Nokia handsets (or who’s requesting user agent does not include a User-Agent string or is using an incorrect User-Agent string that includes the word nokia
.
Lets look at two use cases for requesting an ad. One where the requesting handset is Nokia N95 and one where it is an iPhone 3GS.
- Use Case:
- A Apple iPhone 3GS makes an Ad Request from an application running the Ad Server SDK.
- Pre-Condition:
- The application is using the provided Ad Server SDK
- The application makes an ad request
- Post-Condition:
- A banner is served
- Scenario:
-
- The application sends a well-formed HTTP GET Request to the Ad Request Handler URL including an Ad Request payload and the Device User-Agent Header (
Mozilla/5.0 (iPhone; U; CPU iPhone OS 3_0 like Mac OS X; en-us) AppleWebKit/528.11 (KHTML, like Gecko) Version/3.1.1 Mobile/7A238j Safari/525.20
) - The Ad Request Handler Thread retrieves the Ad Request Payload and the HTTP User-Agent Header constructs an Ad Request, sets it’s state to
New
and pushes the Ad Request onto the Inbound Ad Request Queue - The Ad Request Handler Thread registers with the Ad Dispatcher to wait for it’s Ad.
- The Ad Request Processing Thread pops the next Ad Request off of the Inbound Ad Request Queue
- The Ad Request Processing Thread checks the Ad Request state
- The Ad Request Processing Thread finds the Ad Request state is
New
- The Ad Request Processing Thread pushes all ads in its Recycle Ad Queue onto the Active Ad Queue
- The Ad Request Processing Thread sets the Ad Request state to
Unfulfilled
- The Ad Request Processing Thread pops the first add off the Active Ad Queue
- The Ad Request Processing Thread checks the selected ad for White- and Black- lists
- The Ad Request Processing Thread finds an active Campaign Level User-Agent Whitelist
- The Ad Request Processing Thread attempts to match each string in the Campaign Level User-Agent Whitelist against the Device User-Agent String in the Ad Request
- The Ad Request Processing Thread finds no match for the string
*nokia*
(case insensitive) in the Device User-Agent String;Mozilla/5.0 (iPhone; U; CPU iPhone OS 3_0 like Mac OS X; en-us) AppleWebKit/528.11 (KHTML, like Gecko) Version/3.1.1 Mobile/7A238j Safari/525.20
- The Ad Request Processing Thread rejects the ad for this request placing it on the Recycle Ad Queue
- The Ad Request Processing Thread pushes the Ad Request back on the Inbound Ad Request Queue
- The Ad Request Processing Thread monitors the Ad Request Queue
- The Ad Request Processing Thread pops the next Ad Request off of the Inbound Ad Request Queue
- The Ad Request Processing Thread checks the Ad Request state
- The Ad Request Processing Thread finds the Ad Request state is
Unfulfilled
- The Ad Request Processing Thread pops the first add off the Active Ad Queue
- The Ad Request Processing Thread checks the selected ad for White- and Black- lists
- The Ad Request Processing Thread finds no active White- or Black- lists for the ad
- The Ad Request Processing Thread selects the Ad for this Ad Request attaches the Ad to the Ad Request and updates the Ad Request state to Pending
- The Ad Request Processing Thread pushes the Ad Request onto the Outbound Ad Request Queue
- The Ad Request Processing Thread pushes all ads in its Recycle Ad Queue onto the Active Ad Queue
- The Ad Request Processing Thread Monitors the Ad Request Queue
- The Ad Dispatcher pops the Ad Request off the Outbound Ad Request Queue
- The Ad Dispatcher reads the Ad Handler Thread Id from the Ad Request and passes the Ad Request to the corresponding Ad Handler Thread
- The Ad Dispatcher Monitors the Outbound Ad Request Queue
- The Ad Handler Thread parses the Ad Request and retrieves the ad
- The Ad Handler Thread constructs an HTTP Response with the Ad Response Payload including the Ad
- The Ad Handle Thread sends the HTTP Response to the requesting application
- The application sends a well-formed HTTP GET Request to the Ad Request Handler URL including an Ad Request payload and the Device User-Agent Header (
A few explanations/notes:
The looping nature of the Ad Request Processing Thread makes it hard to write an efficient and clear Use Case but I’m not getting paid to do this (any more) so I’m not going to spend the time to do the work to make it clearer.
This use case leaves out details of filters other than the Whilelist filter, such as Logged In/Logged Out Ad Queue selection, Ad Unit size, etc. for simplicity.
There would be multiple Ad Request Processors/Threads running, so when the first thread that retrieved the Ad Request and found the request was in the New
state it pushed all the ads in it’s internal Recycle Ad Queue back onto the Active Ad Queue because those banners still need to be served and may be suitable for this Ad Request. The second time the Ad Request Processing Thread finds the Ad Request in the Unfulfilled
state it does not empty it’s Recycle Ad Queue to avoid endlessly looping over the same unsuitable ad. (Writing this I think I need to think more about this—there could be a condition where a thread only ever sees Ad Requests in the Unfulfilled
state and would therefore never empty its Recycle Ad Queue…)
I’ve included a lot of stuff that would actually go to other use cases and just be referenced as Include X Use Case, again I hope this makes it clearer (at least to the techies) what is happening.
Anyway… Here is what would happen when an Nokia N95 made a request:
- Use Case:
- A Nokia N95 makes an Ad Request from an application running the Ad Server SDK.
- Pre-Condition:
- The application is using the provided Ad Server SDK
- The application makes an ad request
- Post-Condition:
- A banner is served
- Scenario:
-
- The application sends a well-formed HTTP GET Request to the Ad Request Handler URL including an Ad Request payload and the Device User-Agent Header (
Mozilla/5.0 (SymbianOS/9.2; U; Series60/3.1 NokiaN95/10.0.018; Profile/MIDP-2.0 Configuration/CLDC-1.1 ) AppleWebKit/413 (KHTML, like Gecko) Safari/413
) - The Ad Request Handler Thread retrieves the Ad Request Payload and the HTTP User-Agent Header constructs an Ad Request, sets it’s state to
New
and pushes the Ad Request onto the Inbound Ad Request Queue - The Ad Request Handler Thread registers with the Ad Dispatcher to wait for it’s Ad.
- The Ad Request Processing Thread pops the next Ad Request off of the Inbound Ad Request Queue
- The Ad Request Processing Thread checks the Ad Request state
- The Ad Request Processing Thread finds the Ad Request state is
New
- The Ad Request Processing Thread pushes all ads in its Recycle Ad Queue onto the Active Ad Queue
- The Ad Request Processing Thread sets the Ad Request state to
Unfulfilled
- The Ad Request Processing Thread pops the first add off the Active Ad Queue
- The Ad Request Processing Thread checks the selected ad for White- and Black- lists
- The Ad Request Processing Thread finds an active Campaign Level User-Agent Whitelist
- The Ad Request Processing Thread attempts to match each string in the Campaign Level User-Agent Whitelist against the Device User-Agent String in the Ad Request
- The Ad Request Processing Thread finds a match for the string
*nokia*
(case insensitive) in the Device User-Agent String;Mozilla/5.0 (SymbianOS/9.2; U; Series60/3.1 NokiaN95/10.0.018; Profile/MIDP-2.0 Configuration/CLDC-1.1 ) AppleWebKit/413 (KHTML, like Gecko) Safari/413
- The Ad Request Processing Thread selects the Ad for this Ad Request attaches the Ad to the Ad Request and updates the Ad Request state to
Pending
- The Ad Request Processing Thread pushes the Ad Request onto the Outbound Ad Request Queue
- The Ad Request Processing Thread pushes all ads in its Recycle Ad Queue onto the Active Ad Queue
- The Ad Request Processing Thread Monitors the Inbound Ad Request Queue
- The Ad Dispatcher pops the Ad Request off the Outbound Ad Request Queue
- The Ad Dispatcher reads the Ad Handler Thread Id from the Ad Request and passes the Ad Request to the corresponding Ad Handler Thread
- The Ad Dispatcher Monitors the Outbound Ad Request Queue
- The Ad Handler Thread parses the Ad Request and retrieves the ad
- The Ad Handler Thread constructs an HTTP Response with the Ad Response Payload including the Ad
- The Ad Handle Thread sends the HTTP Response to the requesting application
- The application sends a well-formed HTTP GET Request to the Ad Request Handler URL including an Ad Request payload and the Device User-Agent Header (
This type of White- and Black- list filtering would prevent me from seeing ads for the Ovi store on my iPhone (assuming the people provisioning the ads or campaigns used, and used correctly, the filtering options mentioned above — but that’s a business problem not a technical one.)
The ad serving space is complicated but have been surprised to see a number of examples like this on my phone over the past few days. In fact most of the ads I receive in the applications that use the Google system over the AdMob system seem to fall into this category. I have notices a lack of relevant ads in general for Singapore in the Google Web system. On some sites I see very relevant ads; global companies doing brand building or selling online. But on a lot of sites, and I mean a lot I see the same ads for the same service—a Singapore specific company so at least the location filtering is working. Or I see public service ads (invariably for Kiva [kiva.org].) So either there are not enough relevant ads for Singapore or these local guys are spending a lot of money to spam everyone.
The people at Google are a lot smarter than me, so I wonder if there is something I am missing in all this? Were my product people wrong? Are the users who are creating the campaigns not using some feature of the Google system that would filter these ads from me? Am I completely nuts? Do I have too much time on my hands?