Mobile Advertising (Part 2: Differences Between Online and Mobile Advertising)

On the surface, mobile advertising looks quite similar to online advertising (channeled to desktop and laptop PCs). Both try to reach the same audience who may use different devices (from handheld devices or desktop) in different context (working, commuting, shopping, socializing or filling downtime) to accomplish specific tasks (from information search and content consumption to social interactions and commercial transactions) throughout the day. Both rely for the most part on the same set of digital technologies and infrastructures (e.g., WiFi, web browsers, digital media formats and service providers). So it is natural for advertisers and other industry players (e.g., advertising agencies and networks) to extend the knowledge and practices developed for the online advertising into mobile advertising. Just below that surface, however, there lie some technical constraints and capabilities as well as business value propositions that are unique to the mobile environment. Understanding the key differences between the online and mobile advertising environments is critical for successful adaptation of online knowledge and practices to mobile advertising. It may also provide an impetus for the development of practices and services unique to the mobile environment so as to better capitalize on the full potentials of mobile advertising.

App World on Mobile Devices

One key difference between the mobile and desktop advertising is the use of apps on mobile devices and consequently the availability in-app advertising (the placement of ads inside a mobile app in use) as an option. On the surface, the potential audience for in-app advertising can be huge. There are 224 million monthly active app users in the USA, compared to 221 million laptop and desktop PC users. During TV prime time (around 8 pm), the audience for mobile apps hits 58 million users, a figure that rivals the audience for TV networks (Gordon, 2013). Throughout the day, app users spend an average of 2 hours and 38 minutes on their smartphones or tablets, 80 percent of that time inside mobile apps and 20 percent on the mobile web (Khalaf, 2013). At a closer look, individual users typically spend most of their app time on about a dozen apps or so even if they may have installed several times as many apps. So there may not be as much room for mobile advertising as it first appears.

“For mobile devices, think apps, not ads”, declares an article in Harvard Business Review (Gupta, 2003). Accordingly, people do not like mobile ads. They tend to consider mobile as a more private venue and mobile ads as being more intrusive than desktop ads. Moreover, mobile devices have a relatively small screen that does not give room on the right margin for display ads; mobile ads therefore often pop up in unexpected places to the annoyance of mobile device users. Instead of focusing on mobile ads, the author of that article advises, marketers should create (branded) apps that add value to consumers’ life and enhance long-term engagement with their brands.

No Simple Way to Follow Mobile Users

A cookie, also known as web cookie or browser cookie, is a piece of data sent from a website and stored in the user’s web browser while the user is browsing a website. It enables the website to “remember” the user’s on-site activities (e.g., pages visited, time spent and buttons clicked). Cookie data help publishers to infer individual visitors’ interests (e.g., cruise vacations, performance cars and electric guitars) and preferences (e.g., United States edition of websites) but not browsing history or personal identity information (e.g., name and email address). When that user subsequently visits the website using the same connected device and hence the same web browser, the specific interest profiles from the stored cookie enable the site to serve relevant ads.

Cookies coming from websites whose addresses appear on the web browser’s address bar are referred to as first-party cookies. Those coming from advertisers, ad networks (intermediaries that aggregate ad space from many websites to offer advertisers greater market reach) and other technology providers, are known as a third-party cookies. By placing a cookie in the user’s web browser and updating it every time that user visits one of the websites in an ad network, that network can follow the user, build behavioral profile and serve relevant ads across many websites. This is known as behavioral targeting (more on this later). It is quite common in online advertising where users access content through web browsers.

Behavioral targeting is not as common in mobile advertising as it is in online advertising, for several reasons.

  • No cookies for apps. On mobile devices, users spend much more time on apps than on web browsers. Unfortunately for advertisers, mobile apps do not accept cookies. Ad networks cannot aggregate user behavior across apps by using third-party cookies the way they do across websites on desktop PCs. There are methods for indentifying individual app users for advertising purpose although none has yet been widely adopted. App developers can use an operating system (OS) identifier to identify individual users, e.g., Android ID on Android devices and UDID (Unique Device Identifier) on Apple iOS devices (iPad, iPhone and iPod Touch). Technically ad networks can track individual users across different apps and users have no control over that (like they could delete cookies on a desktop browser). Because of that, Apple has deprecated UDID in iOS5 and in its place recommends developers to create a unique user identifier for their individual apps. That means different apps would identify the same user differently. A solution is still needed that would balance between protecting users’ privacy and accommodating advertisers’ need to serve users across multiple apps.
  • Fewer cookies on mobile web browsers. Mobile web browsers can accept cookies. However, Apple sets the default state of its mobile Safari browser to accepting only first-party cookies (“From visited [websites]”) while blocking cookies from third parties and advertisers, thus effectively preventing ad networks from placing cookies to enable them to track users across websites. Users can change the privacy setting of their iPhones and iPads to “Never” or “Always” (accepting cookies) but very few users do or even know about this feature. Unlike Apple iOS, Android operating system does not restrict the use of third-party cookies. However, just keep in mind that Android smartphones account for less than half of Internet traffic, in term of visits, in major national markets (e.g., USA, China, Germany, France and the UK) except one (Japan). As for tablets, it is an iOS world. Android tablets account around 22 percent or less of the Internet traffic. (eMarketer May 6, 2013). Essentially, there are currently few places in the mobile world where advertisers can count on using cookies to target their mobile audience.

MobAd_MobileInternetTrafficByOS

 

  • No common identifiers between apps and browsers. On mobile devices, apps and websites are separate domains, which use separate identifiers. As a result, ad networks may see a single user as two separate individuals and therefore cannot follow an user when that user moves between an app and a web browser. Again, there are possible workaround solutions but they will have to be worked out between OS providers, advertising industry players and regulators to maintain a proper balance between business needs and consumer privacy.

Different Devices for Different Tasks

Consumers use different devices to perform different tasks. They may not see the ads appearing on these devices in the same light and are thus likely to respond to the ads differently.

  • Consumer uses of tablets are more like those of PCs (e.g., emailing, social networking and retail shopping, in that descending order) than those of smartphones (e.g., social networking, emailing and receiving news, weather and sports updates). They prefer smartphones and tables to PCs for being easiest to pick up but favor PCs as offering the preferred format. They also prefer mobile devices to PCs for entertainment.
  • Consumers feel more emotionally attached to their mobile devices, particularly their smartphones, having these with them practically around the clock. They use mobile devices as a personal assistant to better manage their life, e.g., finding quick answers to questions popping up throughout the day. They view mobile ads as personal invitations, with ads based on location as being “for me” (IBA UK, 201?).
  • Tablets are not instantly connected devices when in use like wired desktop PCs or truly “always-on” devices as smartphones. Users often download content (e.g., magazine articles) onto their tables for viewing later (e.g., in flights or on trains and buses) when there is no WiFi connection. Serving ads on the fly is impractical in such a case while preloading ads with the content makes such ads static, like print ads, rather than interactive, like digital ads should be. Using rich media ads is not an option either because their large file size would make preloading impractical.
  • On mobile devices, consumers use apps more widely than web browsers for certain tasks: “connect” (communication), “navigate” (seeking directions), “inform” (staying updated on news and knowledge), and “manage” (coordinating various aspects of life). It is the other way around for “entertain”, “search” and “shop” (Yahoo 2011).

Technical Differences

Compared to desktop and laptop PCs, mobile devices have much smaller screen, less processing power and some other technical limitations. Creative units designed for an online ad campaign are unlikely to work well on mobile devices without a great deal of adaptation.

  • Screen size. Mobile devices not only have a smaller screen than desktop or even laptop PCs but also come in a wide variety of screen resolutions, from 320×480 on older iPhone models to 2048×1536 on iPad 3 and later iPad models with retina display and many more in the between. Advertisers should therefore be ready to deliver creative units in several sizes to suit such screen-size variations. They may also want to consider designing the ads specifically for mobile devices, instead of squeezing online ads onto a smaller screen.
  • Mobile browser limitations. Mobile browsers typically do not support scripting or plug-ins. That means the range of rich-media content supported on mobile devices is limited. Apple, for example, bans Adobe Flash player plug-in on iOS devices. Flash is a very common rich-media format supporting interactions, animation and video display. It is widely used in online advertising.
  • Limited Bandwidth. Mobile web users are not typically on Wi-Fi like their online counterparts. Very few users can afford an unlimited data plan. Many phone carriers do not even offer, or have stopped offering, such a plan. Most users therefore have a data cap on their cellular devices or a speed cap after exceeding some data usage limit. They find it necessary to adjust their mobile content consumption (e.g., video watching, map-based search and web browsing) to such bandwidth limitations. It behooves advertisers to design their mobile ads with such limitations in mind.

It is not all about constraints and limitations, however. Mobile devices have certain technical capabilities that cannot be found on desktop and laptop PCs (e.g., access to a mobile device’s camera, GPS and accelerometer) thus offering advertisers opportunities to design engaging ads especially in the form of apps.

All About Apps: Part 1. Native, Web or Hybrid App?

This is Part 1 in the series “All About Apps”.

The rapidly growing population of mobile devices such as smartphones and tablets has opened up a new world of opportunities centering on “apps”. There is an app for practically everything, from games and entertainment to education, news, weather, shopping, social networking and productivity. Several hundred thousand apps are now available; they have been downloaded more than 10 billion times in the last few years. What are these apps? Are they any different from the software applications traditionally found on personal computers (PCs)?

What are so different about apps?

Applications are software programs designed for end users (e.g., database, word processors, presentation, spreadsheets, Web browsers and e-mail client) and are different from systems software, which consists of files and programs making up a computer’s operating system (MS Windows or Mac OS) and managing its resources (e.g., drivers for hardware). Applications sit on top of systems software; they cannot run without the latter. Those deployed by organizations are predominantly enterprise applications, which perform system-wide functions such as accounting, payroll processing, e-mail systems, production scheduling, procurement and customer relationship management. They are hosted on some servers and provide simultaneous services to a large number of users, typically over a computer network. Some are proprietary applications being developed and deployed in-house by corporate IT staff; others are outsourced from application service providers (ASPs). The latter can be installed on-premise or hosted by the providers (thus known as software as a service – SaaS). A more recent trend is to move enterprise applications to the “cloud” – a type of Internet-based computing services delivered to an organization’s computers on-demand.

Other than enterprise applications, there are single-user applications. They are installed and executed on a user’s PC and serves only one user at a time. Thanks to the proliferation of personal computers, single-user applications have become widely common, inside as well as outside organizations.

There is another kind of applications, which have caught on like wild fire thanks the rapidly multiplying population of handheld mobile devices such as smartphones and tablets in recent years. Known as “apps” (an abbreviation for “applications”) or often also as “mobile apps”, they make it easier for users to access common Internet-based services and utilities (e.g., email, bookmarking and text messaging) on handheld devices, which generally have smaller screens and more limited computing power than desktop or laptop PCs. They also provide additional functionalities and utilities (e.g., games, photo editing and office productivity) to mobile devices, making these vastly more useful (e.g., a smartphones is not just a voice and data transmitting device but also a web browser, a gaming device and a media player; a tablet is not just a gaming device and media player but also increasingly a replacement for a netbook or laptop PC). They have become the new channel for delivering enhanced services and experiences to mobile device users.

It should be noted that apps are not strictly for mobile devices even though their rise has been closely associated with the proliferation of mobile devices and in particular with the market success of Apple App Store. In May 2007, for example, Facebook launched the Facebook F8 Platform to provide a framework for software developers to create applications that interact with core Facebook features. Within a few months, it had attracted thousands of applications that enabled users to perform numerous tasks, from shopping (by tapping into circle of friends to find the best deals) to nightlife (by notifying friends on the nightlife hangouts of one another), which had not previously been available on online social networks, Facebook or elsewhere. These apps quickly expanded the functionalities of Facebook and helped to propel Facebook quickly ahead of its rival (then market leader) MySpace. They were originally designed for PCs, not mobile devices. Apple did not open its App Store until July 2008. Within 9 months of its launch, however, Apple App Store reached one billion downloads and by January 2011 (or two and half years later) ten billions. In light of Apple’s spectacular success, other competitors have also launched their own stores for mobile apps (e.g., Android Market by Google, BlackBerry App World by RIM and Ovi Store by Nokia). Even Apple has extended the App Store business concept with its Mac App Store for its Mac computers (instead of the iPhones and iPads) and its rivals have quickly followed (e.g., AppUp Store for Windows netbook PCs by Intel). So, apps are now going beyond mobile devices and onto the desktop and laptop PCs, the web (Chrome Webstore by Google) and even the billions of other connected devices out there, from TVs to cars.

If “apps” are not strictly for mobile handheld devices, then how do they differ from more traditional “applications” for desktop and laptop PCs? Both are software applications for end users, but they differ in some subtle ways.

  1. Functionalities and features. Traditional applications for PCs are typically designed to provide a fuller range of functionalities and features, where only a subset of which is actually needed by any individual users. They normally give users a menu of options for personalizing these features to individual needs. They require substantial hardware resources (e.g., computing power, graphics capabilities and storage space). By comparison, apps are more like mini,or bite-size, applications that perform very specific functions, typically on handheld devices with more limited computing resources.
  2. Prices. Given their full range of functionalities and features, applications for PCs naturally cost a lot, often in hundreds of dollar. Apps are on the other hand much simpler in design and hence in development and testing. They cost much less, $2.28 on the average on Apple App Store (148Apps.biz, 2011), although some may cost close to $1,000 (Shontell, 2011; Ide, 2011) .
  3. Distribution. Applications on PCs usually require relatively complex processes of software installation, personalization and updating that often cannot be easily completed without the help of an user manual. The same processes for apps are relatively simple and completely automated. Users usually find, purchase, download and update apps through a few major app stores, usually with a simple press of a button. Some apps can also be found on websites other than app stores; still, users can download, install and/or launch them with one button click.

Native, web or hybrid?

From the development standpoints, there are three choices: native, Web and hybrid apps.

  1. Native apps are those designed to run on a specific operating system (e.g., Apple iOS, Google Android or HP webOS) or even a specific type of device (e.g., iPad or iPhone, though both are running on iOS). Being system/device-specific, native apps can access the hardware features (e.g., camera, gyroscope, compass, accelerometer, microphone and GPS) and resources (e.g., local files, contacts and calendar events) of the device to give richer user experiences (e.g., responsive user interfaces and complex animated content). They use robust programming languages (e.g. Java, Objective C and C++) which are highly suitable for complex application development and have proven track records. Games and entertainment apps therefore tend to go the native route. On the downside, native apps designed for one operating system need to be recoded (with considerable time and cost) to run on another operating system. They are typically distributed through an app store and must therefore get approval from that store; the standards and process for approval vary from store to store. They have to be downloaded and installed on a device before they can run; once installed, they can run even when that device is offline.
  2. Web apps are web sites specifically optimized for mobile devices. These sites can be anything, from a currency exchange rate calculator or business brochure to an online newsletter. Web apps run on mobile Web browsers. They are typically written in a browser-rendered language such as HTML (for defining the static text and images) combined with CSS (for defining styling and presentational elements) and JavaScript (for describing interactions and animations), e.g., content is simply reformatted with CSS to suit a particular screen size and resolution. They work across almost any mobile devices and operating systems. Some uncertainties remain because, for any version of HTML, not all its features are supported by all browsers; likewise, JavaScript may not be interpreted in the same manner by all browsers and on some browsers may not be interpreted at all. There is no guarantee that a particular feature that works on one mobile web browser (e.g., Safari) will also work on another browser (e.g., Chrome, Firefox Android, Dolphin or Opera Mobile). Web apps do not need to be installed on mobile devices; nor do they have to be distributed through an app store. Each time a Web app is used, all or some of its parts are automatically downloaded from the Web. That means it cannot run unless the device on which it is used is connected to the Internet. Web apps are particular popular for communication, shopping, weather and financial services, which depend on data and content constantly updated via Internet connection.
  3. Hybrid apps combine selected features of native and web apps to take advantage of the strengths of these two app types. They do so by “wrapping” a web app, which uses cross-platform web technologies, with a native app to gain access to hardware features and resources (e.g., camera and local files). To users, hybrid apps look and feel just like native apps – they are downloaded from the app store or marketplace, installed on a mobile device launched just like any native apps. For developers, it is not necessary to recode hybrid apps from scratch in order to port them from one mobile operating system to another. Their web portion is already written in HTML, CSS and JavaScript, which can be reused across operating systems and devices.

Mobile Apps Explained from Splash Digital Media, LLC on Vimeo.

The image below illustrates how native, web and hybrid apps differ from one another. A native app has binary executable files that are installed on a mobile device. It interfaces directly with the mobile operating system, without any intermediary or container, and access hardware features and resources via the application programming interfaces (APIs) made available by the operating system vendor for the device. By contrat, a web app consists of web files written in HTML, CSS and JavaScript, and run on a mobile web browser, and thus does not interface directly with the operating system. A hybrid app wraps such web code inside a native container; that container then interfaces with the operating system through the device APIs.

Apps illustrated

Apps illustrated: native vs. web vs. hybrid (by Worklight, 2011a)

Until very recently, the look and feel of, and hence the user experience with, native apps and those of web apps were far apart. But that is beginning to change fast. Behind this change are the technology improvements being made by HTML. Its latest version HTML5, still a work in progress, promises to push the capabilities of web apps to the point of making them as engaging as Flash applications and as integrated with the device as native apps. It supports vector graphics, besides bitmap, and animation. Slowly it is enabling Web apps to gain access to some hardware features. Web apps can now get the user’s current location from the mobile device’s GPS. Before long they can gain access to its camera and sensors, and be cached on the device for offline use when Internet connection is not available.

HTML5 hardware access

Timeline for HTML5 access to hardware features of mobile devices (Global Intelligence Alliance,2011)

Which type of apps should an organization opt for?

  • When there is a need to offer complex user interfaces, killer speed and rich user experience (e.g., games), native apps are the way to go. Being distributed through an app store can be a benefit because app stores are where users go to look for apps. However, be prepared for the high costs of development and porting the apps to multiple platforms, and the time and uncertainties of getting these apps and their subsequent updates approved for distribution through an app store.
  • When there is no need for access to hardware features or only limited need for such access (e.g., simple GPS) but a much greater need for data to be updated frequently, and when speed is not important but low-cost, cross-platform availability is, web apps offer a better option. They cannot be distributed through app stores, however, and must therefore rely on search engines and website marketing to be found by users. This may not be a serious disadvantage as it was not too long ago. With the influx of (native) apps onto app stores, it is getting harder and harder to gain visibility there.
  • When there is a need to reuse a code base across multiple platforms for development cost savings and also to access some (but not the whole set of) hardware features for more complex user interface or richer user experiences, not to mention a desire to have app store distribution, hybrid apps offer an attractive compromise. There are some mobile development frameworks out there (e.g., PhoneGap) that let developers build the native wrapper for hybrid apps by using JavaScript, HTML and CSS, instead of difficult languages such as Objective C and Java, to query the device’s compass, take pictures, find contacts, create appointments and tap other hardware features not otherwise accessible to web apps.

Native, Web and Hybrid Apps Compared (by Worklight, 2011b)

Resources

  1. 148Apps.biz “App store metrics”, accessed Sept 19, 2011.
  2. Global Intelligence Alliance, Native or Web Applications? How Best to Deliver Content and Services to Your Audiences over the Mobile Phone, (April 2010).
  3. Micheal Ide “List Of Most Expensive iPad Apps Hits $999”, IT ProPortal, (May 11, 2011).
  4. Alyson Shontell “The 15 Most Expensive Android Apps In The World!Business Insider, (August 11, 2011).
  5. Worklight (2011a), HTML5, Hybrid or Native App Development.
  6. Worklight (2011b), Native, Web or Hybrid App Development? Worklight Webinar Series.