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!)
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.
The SmartMOB Toolkit 
Got to wonder about an industry body that is still living in the land of wap and prescribes crude (to put it nicely) design recommendations for creative. I’m still aghast at the interstitial idea (“intermediary landing page”). Come on AIMIA, this is not what the voice of the industry should be producing.
You were very polite but methodical in your analysis of a document that obviously needs a lot of review.