One of the most interesting aspects of working in digital marketing is that the pace of innovation often overtakes conventional wisdom. By the time the white papers are written and an approach congeals across the industry, the recommendations therein may have been superseded by advances in technology. Nowhere is this more apparent than in the lemming-like rush to “mobile” that is migrating from consumer marketing into the pharma industry.
The conventional wisdom in this area is that there are two possible approaches: native apps and dedicated mobile-optimized websites. But there is a groundswell of contrary opinion (a contrariness to which I adhere) that either approach is largely a waste of our time and our clients’ money.
The best practice when considering technology recommendations is to examine the past, be sure to understand the present, and extrapolate from these two data points the future. As digital marketers in the highly regulated pharma industry, this extrapolation is especially important, as we must allow for legal, medical, and even federal regulatory approvals, all of which can contribute to a long lag time between any project’s approval and delivery. And in striving to future-proof our solutions, we must also allow for any post-launch updates.
With these things in mind, let’s debunk the two most common approaches to the mobile delivery of marketing materials:
In the native app space, Apple is the dominant player, Android is a looming presence, and there are a number of smaller players with diminishing market shares. On every existing platform, any consumer-facing native app must be distributed through a proprietary app store and is restricted to the platform for which it is written. Disregard any fantasies about HTML5 being a universal panacea: each platform demands its own custom code.
This means to deliver a native app to 100% of the smart phone market, you must develop and maintain separate, functionally equivalent apps for every available system: iOS, Android, Blackberry, WebOS, and Windows Phone, just as a start. Achieving functional equivalency across these systems will not be trivial – each platform has its own proprietary code, strengths, and weaknesses. And remember, this will not be a one-time expense: every system upgrade on every platform brings with it testing, potential tweaking, and a new release.
Even if you restrict your delivery to the two most common platforms (iOS and Android own around 80% of the smart phone market) there are additional challenges. iOS is relatively coherent (less so recently with the introduction of Retina displays on new phones), but Android’s multiple screen sizes and operating system fragmentation (just over 10% of Android devices run the latest version) will mean testing on hundreds of different combinations for full compliance: Is the ISI above the fold on a 480×800-pixel Samsung Captivate screen? What about on a 480×320-pixel Motorola Droid Pro? Have you tested the app on all of the currently active Android systems (Gingerbread, Honeycomb, Ice Cream Sandwich, and Jellybean to name just the major versions)?
Putting aside the development costs, even the distribution stores present challenges for pharma. Consumer can rate and review any app, so a strategy must be developed for handling comments about adverse events or off-label discussions over which the app owner has no control.
Finally, apps are an installed piece of software, and updates (including those driven by regulatory content changes) are technically optional to users. While the FDA may mandate a label change that affects your app’s content, there is no requirement for users to install the latest update reflecting those changes. An added wrinkle for iOS apps is that each update must be reviewed and approved by Apple. For pharma, with the legal requirement that the latest safety information accompany any claims, the potential to have consumers relying on out-of-date information is clearly problematic.
Native apps certainly have their place on mobile devices. For gaming applications, where high-performance graphic capabilities are critical, for apps where integration with phone features such as cameras or accelerometers are required, or where quick access to substantial media assets is a success criterion (such as sales presentations), a native app may be the right solution. But for pharma, where the key to success in most cases is quick access to authoritative information, there are clearly critical issues around consumer apps that have not been addressed.
Dedicated mobile sites
The advantage of a website is that the information on the site, including how it is updated and displayed, is completely within the site creator’s control. The historical issue with websites on mobile phones is that they didn’t look or function correctly—many early web-capable phones simply did a miserable job of displaying conventional websites. Starting in the late 1990s, specialist technology companies developed a number of solutions, but the dominant approach has been to have a “mobile gateway” sitting over the site, which would detect the kind of browser the visitor was using and push any mobile visitors to a separate, specifically designed-for-mobile version of the site.
Some of these solutions are extremely sophisticated—they can detect and optimize the display of the mobile pages to any of thousands of different phone and browser combinations. Often the content—and almost always the navigation—of the non-mobile site would be adjusted, and mobile-optimized templates would be applied to display what the site owners feel mobile users are most likely looking for. The major goals of this approach are to reduce the download size of each page to something palatable by the relatively low bandwidth available to phones, to allow for devices that would not render images, and to adjust the overall layout for the small screen sizes.
One issue that is immediately raised for pharma is how to create, review, and approve each of the mobile versions of the site: each version multiplies the effort required by UX teams, designers, and coders; each version may require a separate manuscript (if content is modified individually); legal teams must review multiple instances of every page (This is what it looks like on an iPhone; Here’s the Nokia 900 view); etc.
Much of this effort is wasted for pharma. Here’s why:
1) Bandwidth is no longer a huge issue for most users. 3G coverage is available to 64% of the US population (95% of Japan and 85% of Korea) [http://www.itu.int/ITU-D/ict/facts/2011/material/ICTFactsFigures2011.pdf]. This is the segment most likely view a mobile site, and at 200kbit/s, they no longer need a massively reduced page weight to get the information they need from your site. Any reasonably designed and coded site will perform adequately within that bandwidth. Even less optimized sites will be easily viewed at the increasingly common WiFi hot spots.
2) You don’t really need to optimize for all possible mobile browsers these days. The current generation of smartphone browsers are almost all based on the WebKit browser technology. This is the default browser on iOS, Android, Kindle, Blackberry 6+, Playstation 3, S60 on Symbian, and WebOS. Webkit adoption as the basis for both mobile and desktop browsers is increasing rapidly; the only serious competition on the horizon may be the Windows 8 mobile browser, but I hear rumors of a Vista-magnitude trainwreck for that engine. At least for the next 12 months, WebKit compatibility will be the gold standard in mobile development, and it renders the “mobile gateway” approach unnecessary.
3) In any event, right now, iOS and Android are the only games worth playing:
|Proportion of North American webpage views
from mobile devices, by OS (May 2012)
|Source: StatCounter, May 2012.|
Where dedicated mobile sites are useful is for obviously mobile-specific uses. If portions of the information on a sites are location- or time-critical and likely to be accessed through a mobile device, highlighting that specific information and optimizing access to it for mobile users makes complete sense. For example, www.jetblue.com redirects mobile users first to their app and then to mobile.jetblue.com, which provides optimized access to flight status, check-in, and travel alerts—exactly the information people need on their way to the airport. Similarly, www.mcdonalds.com redirects mobile browsers to mobile.mcstate.com, where the emphasis (90% of the screen) is on locating a restaurant by ZIP.
There may be opportunities in pharma to give mobile users optimized access to Prescribing Information (for HCPs), and safety, physician finders, and coverage support (for patients). But does doing so require a full mobile-optimized site?
Mobile traffic to the pharma sites we manage closely mirrors traditional browser paths and targets. The largest driver of HCP traffic is the Prescribing Information, which is presented as a downloadable PDF document on most sites. We can optimize the position of the link to that PDF for mobile users, but the actual PI cannot be “mobile optimized,” beyond web-standard size reduction techniques; PDFs are specifically designed to display identically on any device. Consumers present a more diverse constituency – depending on their place in the adoption cycle for a drug, they may be self-diagnosing, attempting to find a physician, researching a new prescription for safety or coverage, or conducting compliance exercises. Given this diversity of intent, providing the full site content (rather than a small subset) seems the best policy.
A better mousetrap
There is an alternative solution that leverages the prevalent trends of widespread adoption of smart phones, increases in phone browser capabilities and screen pixels available on those phones, and the growing availability of broadband for mobile devices. This solution aligns with the context and purposes for which the vast majority of pharma-information-seeking users are utilizing their smart phones and—finally—provides a significant cost savings over the conventional approaches.
Any well-constructed site should be navigable on any smart phone. Flash elements should have an HTML equivalent or replacement for iOS, but no other changes should be necessary. The inclusion of viewport metatags on each page will make any validating XHTML site viewable on a smart phone, and a few additional simple steps that will allow any conventional (competently coded) site to take advantage of modern smartphone capabilities. (Full discussion of existing site “mobilifying” options here [http://www.html5rocks.com/en/mobile/mobifying/] and here [https://developers.google.com/webmasters/smartphone-sites/]).
This is an almost zero-cost solution (beyond the cost of quality code in the first place) to providing your site to mobile users and one that will work for the vast majority of circumstances. Consider that most people browsing the Internet on their phone:
1) Will most likely have 3G or WiFi bandwidth
2) Are comfortable scrolling and zooming to read articles or click buttons
3) Will increasingly conform to (1) and (2) over time
If you disagree with these assumptions, there is a middle ground…
The current best practice if you insist on doing something special for mobile is to present identical content to each visitor, but to configure the layout of that information for each visitor’s device. I prefer not to make assumptions about the visitor’s intent—by all means optimize the interface for activities that analytics show the audience is interested in, but do not patronize mobile browsers by removing site content from their device-view of the site. Sure, many mobile users are searching for location based information while on the move, but 86% of mobile Internet users report using their devices while watching TV, as well, under which circumstance they may be looking for almost anything. They will expect Google to be able to lead them to the right page of your site, which is only possible if *all* of the site is present in the mobile version and at the same URLs.
Obvious advantages to this approach include that the manuscript needs only one version, design and development can leverage much of the code from a common base to each version, and the result can compete with dedicated mobile sites. But there may be a better way still!
The rise of the web app
The biggest limitation of any Internet site is just that: you need to be connected to the Internet to see the content. For mobile device users, this means that (for now) your favorite sites may be out of reach (or extremely slow) at exactly the times you may have time to devote to them: in a subway, on a plane, and so forth. This is the great advantage of apps—once downloaded, they are always available, regardless of connection.
In June 2012, Financial Times abandoned both their native app and their dedicated mobile site in favor of the first true hybrid experience. Mobile visitors to www.ft.com were pushed to app.ft.com (note – NOT the Apple or Android store, but a simple website), which creates a cache of the website on their device. One download gives the user offline access to every article in the site, allowing users to download the day’s content using WiFi in the morning and browse quickly and seamlessly throughout the day. Steve Pinches, Group Product Manager, Emerging Platforms at FT, gave this [http://www.mosquito-fp7.eu/c/document_library/get_file?uuid=c1414aa7-71bb-4ea2-9a22-8c50529fbedc&groupId=27225] presentation about the approach, which is where I’d put bets for the future of mobile information browsing. For transactional sites or massively dynamic ones, the approach of caching the persistent elements locally and using available bandwidth only for the “live” elements may be that perfect compromise between the past and the present that propels us into the future.
As stated at the start of this post, the most frustrating interesting aspect of digital marketing is never knowing for sure what the future holds. But if anyone’s interested, I’m taking bets that by 2014 there will be far less heat around native apps and dedicated mobile sites, and far more web sites that “just work”—on any device, at any size, for any system. In the meantime, here are some brightside guidelines for where apps and dedicated sites can still work:
- When building media that must provide quick access to large amounts of media on a single platform (eg, on a sales rep’s e-detail)
- When offering high-performance graphics or device functionality not available to a website (eg, a game)
- When there are limitation issues with the target audience’s Internet connectivity (eg, maps for pilots)
Dedicated Mobile Sites:
- When there is specific location-specific or time-sensitive information on your site that a user is likely to search for from a mobile device
- If a high proportion of your target audience is using older mobile devices
Under any other circumstances, I’m recommending housing all information on one site and building that site right.