Feedback for the AIMIA Mobile Ad Guidelines 2009

11 06 2009

On Wednesday AIMIA released it’s latest version of Mobile Advertising Guidelines (see http://www.aimia.com.au/i-cms?page=5948). These guidelines have been endorsed by the Interactive Advertising Bureau (IAB) Australia and uses the following definition:

Mobile advertising is defined as: all expressions offered on the mobile phone and paid for by
advertisers, of which the purpose is to influence the attitude, intention and behaviour of the
receiver, advertising mediums for mobile include, but are not limited to:
  * Mobile Websites
  * Mobile Applications
  * Mobile Messaging
  * Mobile Video

Overall this is a constructive and useful document that will add more clarity for advertisers, creatives and developers. However there are a few points that could be worded more clearly and a few that just seem incorrect. Since we’ve been too busy to attend the AIMIA Mobile Interest Group meetings over the last 6 months and there isn’t another one for a month I thought I’d provide the feedback in an open post so anyone else can join in the discussion and provide their own feedback. So feel free to post a comment here or send a twitter message to @nambor.

Related links

MMA Mobile Advertising Guidelines (2008)

MMA Mobile Application Guidelines (2008)

ADMA M-Marketing Code of Practice (2003!)

ADMA Code of Practice (2006!)

ACMA SPAM Act Case Studies

Feedback

A) Text guidelines (pg 4)

i) Maximum 25 characters in length (including spaces)

Surely this is dependent upon or should refer to the assumed text size.

iii) Include an Ad identifier. We recommend that the ad is clearly identified as such,
however that is up to each publisher to determine. If an ad indicator is used, it
should be provided as part of the creative.

How does this relate to i). e.g. Should the Ad identifier be included within the 25 characters? Also, especially if this is the case, shouldn’t these guidelines recommend a standard Ad identifier?

D) Creative guidelines (pg 8 )

D) Clear border and white space Include a 1-2 pixel white border surrounding the
image so it is clear when the banner/web link is highlighted

This is very very broad and doesn’t take into account that the colour of the link can often be controlled by CSS (e.g. on a dark background the host site may have set the link colour to white). This is also very prescriptive in terms of creative.

iii) Screen resolutions vary between handsets so you may need to prepare two
versions of the creative - lighter and darker versions.

Not quite sure how “screen resolutions” directly relate to contrast or “lighter and darker”? Perhaps this was meant to be “colour depths” instead of “screen resolutions”? Even then this statement is a little confusing.

iv) Test, test and test. It is important to test the creative and particularly any
associated interactions/campaigns on all phones

Now I’m a big fan of testing and in fact we even run our own Mobile Testing Lab (contact @alexmyoung on twitter if you want more info), but the statement “on all phones” seems waaaay too broad! I think it’s really important that advertisers match their target device profiles to their target audience profiles or at least the usage context. All our data shows that people who use the Mobile Web and even more so people who response to Mobile Advertising are more likely to have selected a higher end device. Forcing the creative and the campaign site to support all phones can be a massive and unnecessary budget drain for advertisers and can scare people away from Mobile Advertising in general. Also, you can often choose to only serve a campaign to specific device profiles ensuring that the creative is only delivered if the device is relevant.

Technical guidelines (pg 9)

vi) Enable easy direction from website to mobile site - with regard to browsers
this information comes from the userAgent string in the http headers

I “think” this is talking about site “switchers”, as in making it easy to change mode from the PC website to the Mobile website. However this sentence is quite confusing. The description of the User Agent HTTP Header should be clarified and the caveats should also be listed. For example, many devices have poorly configured or even blank User Agents. In fact Mobile User Agents are highly un-reliable (see my post on the alternative “Not-Device Detection” strategy). Mobile transcoding sites like Google’s and proxies can also play havoc with User Agents. As far as the “switchers” go – we are currently working on a Creative Commons and Open Source set of resources for a common switcher strategy to promote the “oneWEBaddress” concept – more on that soon.

ix) Handset detection capacity is highly desirable. It is advisable to test on
actual phones or use other companies which have an extended handset library
rather than using an emulator.

mmm…testing of handset detection should not be based upon an “emulator” but instead should be based upon an automated script or agent that is able to send arbitrary User Agent Headers based upon a library of known devices. The resulting pages or creative served should then be matched against the expected result for that device’s User Agent Header. No devices at all are required for this type of testing. Again, this is something we commonly do in our Mobile Testing Lab.

x) Advertiser/merchant infrastructure. Advertisers will keep up with traffic
demands and are responsible for all costs, communications, hosting, hardware
and software associated with the advertising campaign.

This sentence is just a little confusing and surely it is heavily impacted by the agreement the advertiser has, especially in the case of “zero rated” campaigns or sites that are hosted by a Telco who is running the campaign on the portal for example.

Downloadable and on-device applications (pg 9)

mmm – not quite sure what the difference between those two thing are?!

xi) Offline/not connected/unaware or sometimes referred to as off portal.

This seems like a very confusing statement. “Off portal” is a very different concept to “on-device” or “downloaded”.

xii) Online/connected/aware/ or on portal – These applications are normally
intermittently aware and can be refreshed through synchronisation with the ad
server.

Again, the concept of “portal” and “on-device” or “downloaded” seem to have been related in a way that just doesn’t make sense to me. This is taking the traditional Telco terminology and extending it beyond it’s applicable context. Also, “online” or “connected” applications may not be “refreshed through synchronisation with the ad server” – they may just be dynamically calling the ads in realtime just like a Mobile Website. The advantage here is that they may be supplying other targeting information such as location.

(4) ...or clicking through to a banner.

I think this is meant to be “clicking through FROM a banner”. Also, with the iPhone now reportedly accounting for 43% of Mobile Web traffic according to AdMob the term “tapping” may be more accurate than the term “clicking”.

These statistics show that it is now the dominant Mobile paradigm and with the Palm Pre’s sell-out release it seems that this touch screen User Experience model will become even more common.

BlackBerry guidelines (pg 10)

As the AdMob Mobile Web usage statistics show the BlackBerry represents only 17% of Mobile Web traffic. I am surprised that BlackBerry were singled out yet Nokia and perhaps even Windows Mobile were not mentioned at all.

iPhone guidelines (pg 10)

1) There are two different orientations - landscape and portrait. iPhone specific
websites will use the one size creative for landscape and portrait mode.

The statement that iPhone specific websites ” will use the one size creative for landscape and portrait mode” is not necessarily true. It is completely technically feasible to switch graphics, css and therefore complete layouts when the user rotates their iPhone. In fact this type of creative approach should be encouraged.

2) White space around banner for landscape, justified left

Based on the point above this guideline is a possibly redundant. And the prescription of “justified left” (which I think should be “left aligned” is highly subjective. Centered or right aligned layouts are just as valid and may even work more effectively with some site designs. I just don’t think guidelines need to be specified at this level.

3) Enable automatic redirection to WAP site

You’ll have to forgive me here…but the term WAP really rubs a nerve with me. The iPhone has a fully standards compliant Web Browser. WAP is a dead technology and should not be used to refer to the modern Mobile Web. In fact in our company meetings people get fined if they use that term!

4) As Flash is not supported there are no special effects the ads will have.

While it’s correct that the iPhone doesn’t currently support Flash, this does not mean that “no special effects” that can be supported. In fact the iPhone supports rich Javascript and CSS functionality including SVG canvas support so DHTML ads on the iPhone can be very dynamic and richly interactive. This highlights that this whole category of embedded DHTML Mobile Ads is not mentioned in the guidelines.

This also highlights another key point. The iPhone has driven the most downloaded apps of any mobile device with the Apple App Store now having served over 1 Billion (yes that’s with a B). However the guidelines for the “Downloadable and on-device applications” and “iPhone guidelines” don’t seem to be related in any way. This is something that will obviously need to be addressed in the next version of the guidelines.

Measurement (pg 11)

I think either 4 should be extended or a new 5 should be added that recommends that the type of device and browser or application the ad was served to should also be reported. This is essential and is highly related to all the points above. This should be a standard and expected part of any Mobile Advertising Post Analysis Measurement and we have taught all our clients to expect that.

Reporting (pg 11)

I’m not really clear how this differs from the Measurement section above, and based on the content it seems almost identical but just using a slightly different wording.

Consumer guidelines (pg 12)

Advertisers should look at designing an intermediary landing page, and advising of
data charges.

This is commercially and technically impractical. First of all you simply don’t know what data pack or plan the user has and therefore cannot calculate the cost – if any at all. Second, and perhaps most important, this will absolutely drive down the effectiveness of any campaign. If you interrupt the flow from offer to acceptance you drive down the response rate. If you interrupt it with a warning about cost then you will drive it down to almost zero! The goal should not be to encourage advertisers to advise consumers about the cost of using their Mobile Campaigns…it should be for the Telco’s and the industry in general to help the consumers become informed about their own plan or data pack costs.

Summary

Overall this is a useful document and another good step forward by AIMIA. I hope this feedback is taken in the positive and constructive way it is supplied. More debate and discussion about this document can only help.





AIMIA Mobile Measurement Metrics Launch

31 03 2009

Attended the AIMIA Mobile Measurement Metrics Launch this morning and it was an interesting event that really highlighted where the industry is up to right now. The report is now available for download from the AIMIA site.

There were some great speakers and I think this is a really important initiative.

I also think a few of the un-stated assumptions and where the current focus is was really interesting. The point that raised the most discussion from the audience was questions about why such complex data charges are still being applied and why “flat rate” models weren’t being used to drive user adoption of the Mobile Web in general.

While people on the panel claimed this still didn’t make “business sense”, I think the Flat rate is the new phat – MetroPCS case study posted recently by Vic Gundotra, “Vice President of Engineering for Google’s mobile and developer products” is a classic example of a strong business case.

I am also still a bit confused by the whole economics of the overall Mobile Advertising endeavour based on where this nascent market is up to.

For example, Claudia Sagripanti from GroupM quoted a recent Telsyte research report claiming the overall Mobile Advertising spend in Australia for 2008 was $7 Million. If this is the case then the Telco’s are probably only keeping just over half of that, and if you split it up between the 4 major networks then on average they’re getting less than $1 Million each!

When you compare this with the $44 Million spent by Optus alone over only 2-3 quarters to acquire iPhone users this highlights that Mobile Advertising Revenue cannot be impacting their balance sheet or bottom line at all…at the moment.

The underlying point is that the real revenue for the Telco’s doesn’t lie with Mobile Ad Revenue right now – it lies in the subscription services and data revenue generated when users click on the ads and browse the sites these ads point to.

The real revenue comes from encouraging users to get addicted to the Mobile Web and high-end smartphones like the iPhone and Palm Pre.

The real revenue comes from getting users to stop being afraid of data charges and use the Mobile Web like all of us early adopters do – 24 x 7.

So my question is…”wouldn’t this $1 million for each Telco be better allocated on encouraging users to adopt data heavy mobile habits instead?“.

If this doesn’t happen then the rivers of gold that people believe Mobile Advertising could become will not be realised.

Personally, we’ve gained a lot of data and insights into the real on-the-ground mobile user behaviour over the last couple of years and we are still constantly amazed by how “data charge” phobic the average Australian mobile user is. A lot of people simply don’t know their phones are even capable of using the web. And when we show them that they are they’re horrified and worried that simply clicking on a URL will cost them a fortune. Another large slice of users have even actively disabled data services on their phone so they don’t inadvertently rack up mobile data charges.

It’s going to take quite a bit of mainstream market edumacation to remove these fears and I’m not sure that focusing on such a small amount of Mobile Advertising Revenue right now is really the solution.

As I said, I think the AIMIA Mobile Measurement initiative is important and should be supported. I just think we really need to raise our sights a little higher when we’re considering the underlying goals.





Not-Device Detection javascript, perl and php code

26 01 2009

While server based detection using mod_rewrite or similar will provide a much better level of performance, sometimes you just want to handle it from within a script. Below are examples in javascript, perl and php so you can choose your language/environment. I would strongly recommend using a server side script (e.g. perl or php) but I’ve included a javascript version for reference. Of course if you’re cutting edge then you could run the javascript on the server-side too.

I hope you find this code useful. If you find any bugs or logical errors please let me know.

NOTE: This code is designed to support 3 key classes of device – PC, iPhone and POM (Plain Old Mobile). See the comments by the winmo detection that shows where you may like to extend this for other high-end devices (e.g. Windows Mobile or Symbian).

Javascript Example:

/**
 *  Copyright © 2009
 *  Rob Manson, Sean McCarthy and http://MOBusiness.com.au
 *
 *  This program is free software: you can redistribute it and/or modify
 *  it under the terms of the GNU General Public License as published by
 *  the Free Software Foundation, either version 3 of the License, or
 *  (at your option) any later version.
 *
 *  This program is distributed in the hope that it will be useful,
 *  but WITHOUT ANY WARRANTY; without even the implied warranty of
 *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 *  GNU General Public License for more details.
 *
 *  You should have received a copy of the GNU General Public License
 *  along with this program.  If not, see .
 *
 *  Javascript Not-Device Detection Function
 *  Find out what type of device this is
 *  returns string - either pc, pom or iphone
 */
function _not_device_detection() {
    var ua = navigator.userAgent;
    var qs = window.location.search.substring(1);
    var agent = "error";
    var re = {
        "pcswitch" : new RegExp("pc", "i"),
        "pomswitch" : new RegExp("pom", "i"),
        "iphoneswitch" : new RegExp("iphone", "i"),
        "iphone" : new RegExp("iP(hone|od)(;|\s)", "i"),
        "winmo" : new RegExp("Windows\s+CE", "i"),
        "linux" : new RegExp("Linux", "i"),
        "windows" : new RegExp("Windows", "i"),
        "mac" : new RegExp("OS\s+(X|9)", "i"),
        "solaris" : new RegExp("Solaris", "i"),
        "bsd" : new RegExp("BSD", "i")
    };
    if (qs.match(re.pcswitch)) {
        /* This assumes you have a single query string value of "pc" */
        agent = "pc";
    } else if (qs.match(re.pomswitch)) {
        /* This assumes you have a single query string value of "pom" */
        agent = "pom";
    } else if (qs.match(re.iphoneswitch)) {
        /* This assumes you have a single query string value of "iphone" */
        agent = "iphone";
    } else if (ua.match(re.iphone)) {
        /* This user agent should be an iPhone/iPod */
        agent = "iphone";
    } else if (ua.match(re.winmo)) {
        /* This user agent should be a Windows Mobile device - you may want a special class for this and possibly high-end Symbian too */
        agent = "pom";
    } else if (
        (!ua.match(re.linux)) &&
        (!ua.match(re.windows)) &&
        (!ua.match(re.mac)) &&
        (!ua.match(re.solaris)) &&
        (!ua.match(re.bsd))
    ) {
        /* This user agent is not Linux, Windows, a Mac, Solaris or BSD */
        agent = "pom";
    } else {
        /* Otherwise assume it's a PC */
        agent = "pc";
    }
    return agent;
}

Perl Example:

######################################################################################################
##  Copyright © 2009
##  Rob Manson, Sean McCarthy and http://MOBusiness.com.au
##
##  This program is free software: you can redistribute it and/or modify
##  it under the terms of the GNU General Public License as published by
##  the Free Software Foundation, either version 3 of the License, or
##  (at your option) any later version.
##
##  This program is distributed in the hope that it will be useful,
##  but WITHOUT ANY WARRANTY; without even the implied warranty of
##  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
##  GNU General Public License for more details.
##
##  You should have received a copy of the GNU General Public License
##  along with this program.  If not, see .

##
## Perl Not-Device Detection method 
## Find out what type of device this is
## returns string - either pc, pom or iphone
######################################################################################################
sub _not_device_detection() {
    # either pass in \%ENV or pack the UA and QUERY into a hashref and pass that in
    my $env = shift;
    my $ua = $env->{HTTP_USER_AGENT};
    my $qs = $env->{QUERY_STRING};
    my $agent = "error";
    if ($qs =~ /^pc$/i) {
        # This assumes you have a single query string value of "pc"
        $agent = "pc";
    } elsif ($qs =~ /^pom$/i) {
        # This assumes you have a single query string value of "pom"
        $agent = "pom";
    } elsif ($qs =~ /^iphone$/i) {
        # This assumes you have a single query string value of "iphone"
        $agent = "iphone";
    } elsif ($ua =~ /iP(hone|od)(;|\s)/i) {
        # This user agent should be an iPhone/iPod 
        $agent = "iphone";
    } elsif ($ua =~ /Windows\s+CE/i) {
        # This user agent should be a Windows Mobile device - you may want a special class for this and possibly high-end Symbian too
        $agent = "pom";
    } elsif (
        (!$ua =~ /Linux/i) &&
        (!$ua =~ /Win/i) &&
        (!$ua =~ /OS\s+(X|9)/i) &&
        (!$ua =~ /Solaris/i) &&
        (!$ua =~ /BSD/i)
    ) {
        # This user agent is not Linux, Windows, a Mac, Solaris or BSD 
        $agent = "pom";
    } else {
        # Otherwise assume it's a PC
        $agent = "pc";
    }
    return $agent;
}

PHP Example:

/**
 *  Copyright © 2009
 *  Rob Manson, Sean McCarthy and http://MOBusiness.com.au
 *
 *  This program is free software: you can redistribute it and/or modify
 *  it under the terms of the GNU General Public License as published by
 *  the Free Software Foundation, either version 3 of the License, or
 *  (at your option) any later version.
 *
 *  This program is distributed in the hope that it will be useful,
 *  but WITHOUT ANY WARRANTY; without even the implied warranty of
 *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 *  GNU General Public License for more details.
 *
 *  You should have received a copy of the GNU General Public License
 *  along with this program.  If not, see .
 * 
 * PHP Not-Device Detection Function
 * Find out what type of device this is
 * returns string - either pc, pom or iphone
 */
function _not_device_detection() {
    $ua = $_SERVER['HTTP_USER_AGENT'];
    $qs = $_SERVER['QUERY_STRING'];
    $agent = "error";
    if (preg_match('/^pc$/i', $qs)) {
        /* This assumes you have a single query string value of "pc" */
        $agent = "pc";
    } else if (preg_match('/^pom$/i', $qs)) {
        /* This assumes you have a single query string value of "pom" */
        $agent = "pom";
    } else if (preg_match('/^iphone$/i', $qs)) {
        /* This assumes you have a single query string value of "iphone" */
        $agent = "iphone";
    } else if (preg_match('/.*iP(hone|od)(;|\s).*$/i', $ua)) {
        /* This user agent should be an iPhone/iPod */
        $agent = "iphone";
    } else if (preg_match('/Windows\s+CE/i', $ua)) {
        /* This user agent should be a Windows Mobile device - you may want a special class for this and possibly high-end Symbian too */
        $agent = "pom";
    } else if (
        (!preg_match('/Linux/i', $ua)) and
        (!preg_match('/Win/i', $ua)) and
        (!preg_match('/OS\s+(X|9)/i', $ua)) and
        (!preg_match('/Solaris/i', $ua)) and
        (!preg_match('/BSD/i', $ua))
    ) {
        /* This user agent is not Linux, Windows, a Mac, Solaris or BSD */
        $agent = "pom";
    } else {
        /* Otherwise assume it's a PC */
        $agent = "pc";
    }
    return $agent;
}





Not-Device Detection

16 10 2008

Over the last 2 years we’ve been refining a simpler and more powerful approach to device detection than everyone else seems to be focusing on.

While WURFL, Device Atlas, etc. are all great resources for very specific capability profiling…we’ve found that turning the problem upside down made much more sense and delivered faster, better results.

The key thing that most developers seem to be trying to do is to identify if a user IS using a specific Mobile Device.

The problem with this is that the User Agent strings on Mobile Devices are inconsistent at best…and completely useless or even non-existent at worst.

Once you accept this the inverse answer becomes clear.

PC browsers are much more reliable and consistent in identifying the Operating System they belong to. Also, there is only a small handful off Operating Systems you need to detect. So this is how our solution works.

We call this !device-detection (“Not Device” Detection).

If your User Agent isn’t one of the following Operating Systems:

- Windows
- Macintosh/Mac OSX
- Linux
- FreeBSD
- Solaris
- (Add niche OSes here)

And your User Agent doesn’t contain one of the following strings:

- bot
- slurp
- spider
- crawl

Then you are almost guaranteed to be on a Mobile Device.

Within this group you can then also clearly identify the important groups that are consistent:

- iPhone/iPod Touch
- Windows Mobile

We have implemented this method for two major Telco’s a major Insurance company, our leading edge Mobile Payment service and our own web projects. This is a strategy that has proven to be very effective and only requires a simple set of regular expressions in the form of Apache mod_rewrite directives that can work in either Apache or IIS.

We also couple this with a simple design pattern that provides a link from the Mobile site back to the PC site just in case we accidentally mis-classify a user. After all they should be able to ask for the full PC version if they really want it.

We’ve also recently put together a case-study that looks at some well known large corporations in Australia to see how they are or are NOT handling automatic device detection. The results are very surprising.

A full copy of the presentation is online on slideshare

Now we thought it’s time we shared this strategy in order to broaden the on-going device detection discussion.





MoMo Sydney Audience Profile

14 04 2008

MoMo Sydney Audience\'s Technology Profile

The overall audience size when the poll was run was about 75 people. 71 people tried to participate with 59 of them successfully joining in. The 12 that couldn’t join in all sent an SMS but either decided not to follow the link in the reply message or simply couldn’t because their mobile doesn’t support data or open internet access.

It was interesting to see that over 58% of users chose to join the Live Poll using SMS. This means they sent an SMS to our inbound number and we then sent them back an SMS with a link to join the Poll. A third of the users simply typed the TinyURL directly into their phone and 8% scanned the QR Code provided. All three of these Access Methods were listed on the postcard that was handed out to the audience.

Again we were quite surprised at how evenly the 3 major MNO’s in Australia were represented. This is similar to the results we saw at Web Directions last year and we believe this suggests that amongst Data Heavy Mobile Consumers the market share is much more evenly split. However these results are only meant to be indicative and are not statistically significant. I’ll make some analysis of the “Other” segment soon.

In terms of Device Manufacturers Nokia and SonyEricsson dominated as usual. However there were 7 iPhone’s (11%) which just highlights what a bunch of Early Adopters the MoMo crowd really is. We think this suggests that this audience is more representative of how the mainstream market will be in 12 to 18 months.

When it comes to Mobile Browsers the audience was fairly evenly split between Safari (iPhone and Symbian), NetFront, Pocket IE and Unknown. We captured the x_wap_profile headers for all of these users so I’ll provide some more info on the “Unknown” break down soon. Again it was very interesting to see how small the Opera slice was. And the IE/Firefox slices were from the PC’s we used on the stage.





Live Mobile Poll at MoMo Sydney

14 04 2008

Live Mobile Poll at MoMo Sydney

Last Monday we ran another MOB Live Mobile Poll…this time it was at MoMo Sydney.  The audience could join in by SMS, URL or QR Code.  The results of the audience profile and their answers where presented on screen in realtime.





Mobile Banking analysis

7 10 2007

Mobile Banking results

While a smallish 20% still “Didn’t know you could”, roughly 12% had tried it with half converting to regular “Monthly” use.