Google's AdWords/AdSense system allows businesses to advertise on the web. This service was recently expanded to provide advertisements on mobile phones using XHTML/WAP 2.0, WML/WAP 1.0 and CHTML/iMode, implemented with PHP, CGI Perl or ASP. This is a brief overview of how the Google system is implemented and a demonstration. The differences between the system for desktop and hand held devices is discussed, as is Google's adherence (or lack of) to web standards. The accessibility of the ads, particularly for disabled will also be looked at.

AdWords is Google's service for advertisers. With this small businesses to advertise locally or globally on the web. The corresponding service, Google AdSense, allows small web publishers to earn revenue from advertising on their web sites. Keywords and location data are used to match advertisements to web page content. This service has now been expanded to provide advertisements on mobile phones. This is a brief overview of how Google AdSense places ads on web pages for mobile phones. An example of Google Mobile Ads is included on this page (on a mobile device the advertisement is at the end of the document, on a desktop PC the ad is on the right).

Google's advertising broker accepts advertising and then places it with suitable web sites. The broker is paid by the advertiser and then shares some of the payment with the web site publisher. This process is automated, with the advertiser providing describing the type of web sites they would like to advertise on and this then being matched with suitable sites.

The price of the advertisement is determined by auctioning keywords on your web site (such as "travel and "Paris"). The popularity of the web site to the reader and its relevance to the advertiser determines how is paid. Web advertisements can be used for complex products. As an example in 2007 the author's web site was used to advertise "Landing Helicopter Dock" (LHD) ships (aircraft carriers) and two were subsequently sold to the Australian Government for $3B.

Advertisers select the region they want to advertise in and the language. They then create a headline, brief text description (up to 95 characters total) and the URI of the advertisers web site. The aim of the advertiser is to have readers click on the URI and be forwarded to the advertiser's web site.

Keywords

The advertiser specifies keywords (or phrases). These will be matched with keywords on web pages to place the advertisement on. The assumption is that readers who are interested in web pages featuring those keywords will be interested in the advertisements featuring them.

It helps to keep each of web page to one topic and have words about that topic feature in the web address, the title and the body of the article. As an example many of my technical travelogues are about journeys to computer conferences. This confuses the advertising system as it doesn't know if the web page is about travel or about technology. It would be better to do two web pages: one about the travel and the other about the computer event. This may also help the reader.

Cost per "click"

Unlike print advertising, the Google advertiser is charged not for the advertisement appearing, but for the reader "clicking" on the link in the advertisement and to have their web browser display the advertiser's web page.

Geographic Targeting and Privacy

Google provides Regional and Local Targeting of advertisements. Advertisers can nominate the region or city they want the ads shown in (for some countries).

Google has automated software to check for publishers inflating their advertising revenue by clicking on their own ads. This is generally called "click fraud", or "invalid clicks" by Google. While useful to keep advertisers honest, this and other aspects of the information Google collects has implications for privacy (Clarke 2007).

Unlike print advertising, as the web site provider (publisher) does not directly select the individual advertisements for display. The words in the web site are analyzed by the broker's system to determine the keywords for the page. These keywords are then matched with the advertiser's keywords and advertisements selected (along with region and language).

The publisher does have control over on which web pages and where the advertisements appear. For Google's desktop advertising service, this is done by inserting a small segment of Javascript code (provided by Google) into the web page's HTML at the point the advertisement is to appear. This requests the advertisements from the broker's system be downloaded to the user's browser (client side scripting). If you are using web creation software you paste the Google code into it once and then have the code automatically inserted into appropriate pages.

Google has rules, about the number, size and placement of advertising. Some web sites place advertising so prominently it makes the page content hard to find. There is less incentive to do this with per click payments, as the reader can only click on one advertiser, so devoting more of the page to ads does not necessary increase revenue. Excessive advertising can discourage readers, as can graphics or formatting, as advertising systems, such as Google's are currently largely driven by text.

It should be noted that many PDAs, mobile phones and smartphones, such as the Apple iPhone are already able to display web pages with Google ads. These devices can display web pages using HTML and XHTML and have much larger screens than the average mobile phone. The web designer may need to do some work to ensure the page content and ads display well on the screen. The designer can use smaller and fewer images and less text to create web pages more suitable for a smart phone. They can use Google's smaller ad formats and text based ads. It is possible to create web pages which display on regular desktop computers and on smartphones in this way. However, AdSense for Mobile may be a useful option for other mobile phones.

For Google's AdSense for mobile, a mobile-compliant web page is required. This requires that the existing web site is modified to use a markup language suitable for a mobile phone. To maintain compatibility with desktop web browsers, XHTML (WAP 2.0) can be used (with CSS used to enable features for mobile phones). Some web sites are created specifically just for phones using WML/WAP 1.0, or CHTML/iMode. The web designer can use technologies such as XSLT to convert web pages to a format more suitable for mobile phones. In any case care needs to be taken to see that the design fits within the phone's limitations. As an example see this web page on the.mobi mobile Emulator.

Google provides mobile phone versions of several of its web services, including Search, Maps, Gmail (email), Calendar and News (these can be shown on a PC using the .mobi mobile Emulator):

Google mobile products

Search
Maps
Maps (Download)
Gmail
Gmail (Download)
Calendar
News

*Tip: Bookmark this page for quick access to Google services.

Not in Australia?

Terms of Service
Privacy Policy

However, the interface used does not conform to best practice, failing 10 tests of the W3C Mobile Web Best Practices checker (Beta).

Results of checking Google

This page failed on 10 tests

1. The image at line 3 column 507 has no width set in the markup.

   …s <br/> </div> <div><img class="c1" src="http://www.google.c…

   This test is related to the following Best Practices: IMAGES_SPECIFY_SIZE (techniques) GRAPHICS_FOR_SPACING (techniques) IMAGES_RESIZING (techniques) ...

The page passed 14 tests

1. The markup of the page is well-formed and valid.
2. The page provides caching information.
3. No links are set to open in a separate window. ...

This page raised 7 warnings

1. The page has application/vnd.wap.xhtml+xml as a media type; that media type is not recommended for the Default Delivery Context.
   This test is related to the following Best Practices: CONTENT_FORMAT_SUPPORT (techniques) CONTENT_FORMAT_PREFERRED (techniques) ...

Formats for web on mobile phones is still an area for development, as is research into what users will want from such a service. What is needed in a mobile web page may different from a desktop one and also may case a rethink of what is good web design. As an example my web site was exceeding the download limit set by my web hosting provider. Most of the bytes downloaded were from images, not text. So I reduced the size of images from around VGA size of 640 x 480 pixels to QQQVGA size of 80 x 60 pixels. This reduced the downloads by a third, without making the web site any less popular. It also makes the images more compatible with mobile devices with small screens.

The Australian Interactive Media Industry Association (AIMIA) issued guidelines for advertising on mobile phones in August 2007:

Mobile phone web sites can be created using the same techniques as other web pages. However, mobile phones may not have Javascript, which Google use to insert advertisements. So for Google mobile server-side scripting (such as PHP, CGI Perl or ASP) is used to insert the advertisements. This requires you to have server side scripting on your web server. The change may be as small as changing the file extensions on flies to .php. A small amount of code provided by Google is then inserted. As with desktop AdSense, instead of inserting the code manually into each of your web pages, you can use the features of your server-side scripting to copy it into all pages automatically.

To enable AdSense for Mobile, select "get started" on the Google Reports Overview screen. The AdSense for Mobile wizard will then take you though the steps required. There are some differences in the program policies for regular and mobile ads. Most importantly you can only place one ad unit on any mobile webpage. The Ad unit format is limited to selecting either one or two text ads be unit. The ads are selected for the content of the webpage in the same way as regular Google ads.

The Markup is selected from XHTML (WAP 2.0), WML (WAP 1.0) or CHTML. You are most likely to want XHTML. A similar range of color sections for the text of the ad is provided as for regular Google Ads. However, keep in mind that mobile phones have a limited range of colors available on their screens (or may have no color at all). Google will provide Ad Code in PHP (v4.3.0 or greater), CGI/Perl (v5.8 or greater), JSP (v1.2 or greater) or ASP (v3.0 or greater). This code is then cut and pasted to the web page.

Google's mobile ads are server side includes and so may slightly increase the load on your web server. However, they reduce the amount of data sent to the user's web browser, which is particularly useful for mobile browsers with slower wireless Internet connections and higher charges. Also the text of the advertisement is designed to be able to display on devices with different size screens, unlike regular Google ads which are designed with fixed size boxes.

The mobile ad format uses HTML and so will display on web browsers which do not have JavaScript. Also it will display on specialized devices designed for the disabled, which may not support JavaScript.

One curious aspect of the web code generated by Google's ad system is that it includes in-line styles:

<div style="background-color:#ffffff; margin-top:3px; border-top: 1px #e6e6e6 solid; margin-bottom:3px; border-bottom: 1px #e6e6e6 solid;">

The styles make up about 50% of the content of the ad download, but do not necessary contribute anything to the displayed result.

The version of HTML specified for WAP 2 is XHTML Basic. This dialect of HTML does not include the style element and so the inline styles included in the Google code should be ignored by phone web browsers. The text of the ad should be displayed in the default color scheme and font of the web page. In practice most phones support the Style element, but the web page designer can override Google's colors and font sizes by specifying their pages are in XHTML Basic.

Is it legal?

In July 2007 the ACCC alleged misleading and deceptive conduct in relation to sponsored links that appeared on the Google website. There seemed to be two issues with this:

1. Sponsored links which are not to the advertiser they appear to be, and
2. Advertisements not clearly distinguished from search results.

With the sponsored links, I noticed that when I attempted to place a Google ad for a model of the Thalys European high speed train, the Google system rejected it. The system said "Thalys" was a trademark, so I could not use the word in an ad unless I proved I had the rights to it. So it would seem the system has some level of checking built it.

With advertisements, there would seem to be several ways to determine if they are distinguished from search results:

1. By Analogy With Print Ads: Web ads can be compared with the way newspaper advertisements are made distinguishable from editorial. Text only web ads are probably more easy to recognize as ads, than the average newspaper "advertorial", but then that is not a very high standard to meet.
2. User Testing: It would not be difficult to test if people can tell ads from search results in a human computer interaction (HCI) laboratory. This would involve sitting people down in front of search screens and asking them to pick out the ads. These test facilities are equipped with cameras to record where people are looking and staff trained to interpret the results. ANU and CSIRO have developed a method of testing web search page designs online which might be adapted to this online (Thomas and Hawking 2006).

Saying No to Ads

With normal web page browsing you could not give informed consent to the content of a web page you had not yet seen. But it would be possible to add options to your web browser so it could negotiate on your behalf. The browser would check if the site's privacy and other policies were acceptable to you, before taking you to the page.

Your web browser could block web pages which featured ads. There could then be a service where you could pay an amount to see pages which would otherwise have ads. In that case you would bidding against the advertisers for the advertising space: pay enough and you don't have to look at the ads.

Of course it is not hard to block ads and just see the content. This would break the publishers revenue model and presumably put them out of business to the viewer would no longer be able to see that content (much as is now happening with FTA TV). But there are those, such as Stephen Mayne (Crikey.com founder), who argue that web advertising is not a good way to support quality content anyway.

Do the Disabled Have a Right to Ads?

Poorly designed web pages have the potential to be inaccessible to disabled readers, as happened with the web site for the 2000 Sydney Olympic Games. This can also apply to web advertisements, which use Javascript, fixed formats and images. The features used to provide ads for mobile phones can also make them more accessible to the disabled. Assuming that ads provide a service, it could be argued that the disabled are entitled to the ads under Australian law. If web advertisers do not provide the ads in an accessible format, a complaint could be made against them for unlawful discrimination.

It may seem bizarre to think anyone would complain about not getting ads, but those who are blind are also entitled to know what is on special at the supermarket this week. 1RPH (Radio for the Print Handicapped Canberra), read out supermarket specials on air from ads in the newspapers, as a service to its listeners.