Mobile Advertising

Considering that mobile handsets are quite probably over 4 billion today, v.s. computers at 800 million pieces, mobile advertising is something of a hot potato.

But mobile advertising is much trickier than regular Web advertising for a number of reasons, most notably:

- Not all mobiles have data access
Mobiles that don't have GPRS/EDGE/3G are restricted to phone and SMS.

- Extremely varied screen sizes
Some motorola handsets have screens of 128x160 pixels. The iPhone has a touchscreen of 320x480 pixels. And there's all sorts of sizes in between and outside that range.

- Random Web support
It is so difficult to know how (if at all) the handsets will display web pages that the .mobi registry has created a specific product called Device Atlas to help developers understand the features and limitations of each device.

- Cost and speed of data access
There are now more and more "all-you-can-eat" data plans thanks to the advent of the iPhone, but this is by no means the majority. Furthermore, roaming data access remains prohibitively expensive. On a recent trip to Canada, over a period of 6 days with relatively little roaming data access, I managed to accrue a Euro 450 bill on my French SFR mobile. Talk about forgetting to acquire a local SIM card and switch my .tel domain to it (I won't make that mistake again)! Also speed is a concern, even with the latest 3G technologies that favor larger files over smaller ones: the cost of initiating a connection is high, which will happen for every ad.

A new paradigm

As we were designing the specifications for advertising on .tel domains, we decided from the start that one of the requirements would be that ads should be available directly inside the domain itself, and not just as an add-on to the web interface. Doing so would allow any native application the ability to display those ads without resorting to HTTP requests.

Beyond the obvious efficiencies in a small and fast DNS query, an additional benefit of storing the ads in the DNS (or providing a DNS interface to an ad server) is that the ads are structured data, much like an XML API for ads. So you can easily determine how you wish to display them in a native application, removing all issues of matching advert size to handset screen size at the server level.

An ad in some.domain.tel domains is a TXT record, generally stored in _ad.some.domain.tel, with the following structure:

TXT ".tad" "Version" "DisplayPreference" "Preference" "Title" "Label" "URI" "Description"

where "URI" and "Description" can be multiple consecutive key/value pairs, ensuring that both can be as long as necessary.
Specific information can be found in the full spec for ad serving in a .tel domain.

I am looking forward to seeing ad servers implement a DNS interface to their ads, and in the process making them even more suited to mobile applications of any type.