“I lost a lot of money, people quit, and were fired. We got nothing in return, and I hated every single moment of native apps.”
This is the capsule version of why Jason Pontin, Editor in Chief and Publisher of the MIT Technology Review has lost his religion regarding native and has fully embraced HTML5.
Jason was joined by Nick Alt, VP of Mobile from Vimeo and Ryan Spoon, SVP of Product Development at ESPN on a panel app-tly named Are Apps or the Web the Future of Mobile Content? last week at PaidContent 2013.
“Traditional publishers told themselves something like this: The Internet taught readers they could pay nothing and advertisers they could pay less, and though no one in the history of publishing had ever really liked digital replicas, native apps would be like digital replicas but even better. They would teach readers to pay again…and we could somehow move back into the past.”
Though Pontin never fully bought into that gospel, he did believe native “could do sufficiently cool things that it might be worthwhile investing a lot of money in it.” Not unlike where many retailers and publishers find themselves today.
“Over a year long experiment, we ended up with around 200 new subscribers, we spent around $400,000 in unbudgeted expenses, and my head of digital development and most of his staff left, and the editors were furious.”
After the fact, Pontin determined that for the MIT Technology Review, “native apps were worthless,” and everything of value he wanted to do could be done with HTML. So in October, 2012, the publication joined the Financial Times in pulling its Android and iPhone apps in order to focus more on HTML5.
The case for native
For Pontin’s co-panelists from Vimeo and ESPN, dodging native is not an option. Says Spoon:
“We have a diverse portfolio of products. Watch ESPN streams millions of hours of live footage. This can’t be done in HTML5 in the quality and movability that we want it to. There are other components – scores – which is the fundamental need of what we do, and content, and we build products to serve both avenues.”
ESPN builds its Web experience using mobile first principles, but “for rich experiences, it has to be native.”
Both Vimeo and ESPN cited the communication benefits of their apps. While email is far from dead, updates on things like sports scores hook into native apps much more seamlessly than through constant email updates. Vimeo has run identical campaigns through email and push notification in tandem, and experienced more monthly unique users and revenue for push vs. email.
The summary from the panelists whether to go native or not could be boiled down to “if your content needs to tap deep into the software and hardware of a device, and you want to do things HTML5 can’t do yet, go for native.” But it’s simplistic to conclude that publishers of non-video content should stick with Web apps because MIT Technology Review or Financial Times pulled out.
Looking under the hood
If my client told me “we tried testing our home page, but we didn’t see any uplift, so we stopped testing,” I’d have a lot more questions for this marketer. I’d want to know what elements were tested, what tools were used, was everything implemented properly, how was success measured, how long the test was run, etc.
I have similar questions for MIT Technology Review:
- You achieved 200 sign ups. What was your conversion rate? Was any effort made to improve app store conversion rate (screen shots, description, reviews, value propositions)?
- What is your app store conversion rate relative to Web and Web app? How do you know an HTML5 Web app won’t have similar results?
- How was your native app priced? Was it sold as an additional paid subscription to existing subscribers? How was it priced relative to other delivery formats? Have you explored freemium?
- How many app downloads were existing vs. new readers of your publication?
- How was your app marketed? Was it a silent launch? If you surveyed your entire readership today, what percentage would be even aware a native version was available? What value propositions did you present to motivate subscribers to download your native version?
- What metrics besides new subscribers did you track? Can you measure native’s impact on engagement vs. HTML5 apps, and how did that impact advertising revenue and subscriber retention?
- How did your native users rate your app? Did you gather feedback on usability and satisfaction? Did you leverage push notifiactions to re-engage app users? Did you support offline reading?
- ROI for such a costly project does not always happen within a 12-month span. Why abandon so quickly?
- Have you explored new business models that a native app could serve, rather than simply re-purpose print content? What if the app could provide search across issues, access to back-issues and back-articles suggested through a personalization engine to drive incremental revenue while monetizing your legacy content? In other words, have you explored new business models a native app could be built around?
The publishing industry faces challenges with going native, no doubt. Aggregators like Zite and Flipboard are competitors with a disruptive value proposition. For some publishers, dodging native and partnering with aggregators is an option. Generally, people are reluctant to pay for content that’s easy to find for free. But MIT Technology Review isn’t generic news. It’s possible that any of the above questions hits on a hole in the planning and execution of the native strategy.
Minimizing your risk of trying native
MIT’s native flop was a costly learning. And some learnings can only be reaped after throwing some time, effort and cash at the wall. Every digital and retail business is faced with the decision to build and support native apps, HTML5, both or none. How can you reduce your risk of making an expensive mobile mistake?
- Don’t be a first-mover. Sit back and watch your competitors. Are they pulling out of new channels as quickly as they got in (think Facebook Stores)? It’s the safe option, but carries risks of lagging behind the competition and concluding that it doesn’t work for your industry based on one or a handful of withdrawals, without knowing the reasons why the projects failed.
- Pick a flagship platform. Some businesses offer only Apple apps, for example. If it’s successful, branch out.
- Wrap it in native. A quick fix is to take a common HTML5 code base and wrap it in native code for each app store. Not as robust as a full native app, but enables you to fail faster and gauge customer acquisition and revenue uplift without investing too many resources.
- Use an app builder. The classic build vs. buy decision – there are vendors that can build you an app at a fraction of the cost of doing it in house. As with ecommerce platforms, businesses that require custom features likely won’t find app builders sufficient.
- Use a touchpoint broker. The big challenges in bringing commerce to new touchpoints is costly experienced developer resources, long project lead time, and the security risks in exposing business logic to outside applications. We set out to solve these problems through a dynamic touchpoint broker. Elastic Path Cortex turns content and transaction requests into simple language that developers can easily embed into a variety of device and platform-friendly apps.
To end on a positive note, Popular Science has netted over $1 million in revenue after design, licensing and revenue share with Apple on its iPad edition. Popular Photography has converted 10% of subscribers to iPad. And Condé Nast grew digital sales by 268% in 2011.
Future made $1 million from the iOS Newssatand in its first month, with 75,000 new subscriptions.
Take heart. Native apps are not dead for publishers industry-wide.