Month: May 2013

Categories
Business

Mobile Advertising versus App Store Promotion: a tale of woes and wins

As an independent developer, I ‘ve had my fair amount of successes and failures – examples of the former are TVPyx (Symbian, Windows Phone, Web) and TubeBusBike (Symbian).

Having developed apps on iOS, Android, WP, Symbian, Bada and Web – my experiences of all stores  has been mixed. As an independent developer it is increasingly difficult to get noticed in the sea of apps that are available on the various stores. I have had a fair amount of trial and error experiences with both advertising and merchandising across those stores. I ‘m here to share my experiences with both.

 There are a number of techniques available to developers that can be used to promote your app and increase downloads. Some of these you will need to pay for, some of which are just down to hard work and slick execution. Of course there is always an element of luck and right place right time usually built upon previous failures, think Rovio. I am going to concentrate on two methods of promotion.

 Advertising  and cross promotion – The method of promoting an app either through paid in-app advertising i.e. in someone else’s app/website or cross promotion through apps developed by the same publisher.

 App store promotion – The practice of promoting an app via app stores. Merchandisers (app store owner staffers) select apps by country/region to appear as featured or promoted apps on the store. Various ‘slots’ have different success rates where ‘featured’ is usually the Holy Grail in terms of maximizing eyeballs and downloads.

Advertising

Advertising using one of the mobile ad networks like Admob or an ad exchange like Inneractive is a paid-for activity i.e. you would pay for a campaign of ad impressions to promote your application in the usual advertising model. While someone like Admob may be excellent in a market like the Germany, they may lack in a specific region like Vietnam. This is where an ad exchange comes in. If you have a truly global application or specific regional needs that no one ad network can provide the required local content, an ad exchange barters on your behalf with local inventory and then serves the ad that gives you the most return.

Not all ad mechanisms are created equal, so you should take care whilst selecting one. While the fill rate may be excellent compared to a single network, the downside is that you may not be getting premium content that would be served by a truly local provider i.e. lower CPM. So while a fixed ad network can provide targeted delivery in terms of locale, an ad exchange can level the playing field especially in those maybe hard to reach areas of the globe. You need to understand your market and choose accordingly.

My personal experience of using paid-for app promotion was very disappointing. For £1000 one of my apps was involved in a campaign that consisted of a carousel with 4 ads shown in succession. The campaign as a whole  garnered 260,000 impressions. My ad was the 4th on the carousel meaning that it would be the 4th ad served once the app the ad was in was invoked. Quite far down the pecking order. From this campaign there were 82 clicks of which it is unclear whether any of these actually resulted in any downloads. No spike, no step change, just noise. The ad was targeted at UK mainly but a few other countries were involved. So quite a high customer acquisition rate!

Anecdotal evidence suggests that in some markets, advertising in apps might even have an adverse effect on downloads, as they use data which comes at a cost to the user.

App Store Promotion

Being a ‘featured’ app on any store will dramatically increase downloads. Naturally being featured in a store is likely the result of one of the following; it’s a great app, it’s a great experience, great PR, a relationship with a journalist on a national newspaper, major marketing budget, lots of hard work and maybe a bit of luck to name a few.

To get noticed by a store owner – especially an OEM – you need to consider what they as the builder of the devices are currently trying to push. For Nokia it may be imaging or mapping i.e. you are more likely to be promoted if you are harnessing one of the strengths of the business, what makes them unique. For Samsung it may be an app that integrates with their TV solutions. Segmentation considerations also work e.g. apps for a demographic that are being targeted by a particular device or devices. Building a relationship with an app store owner is a means to get promoted but this is likely to be the result of an app that meets the needs of a campaign or some quid quo pro between the developer and the likely OEM. A strong relationship or understanding of needs is required regardless of approach. I am privileged enough to have been involved a number of OEM programmes and have some close relationships with a number of OEM’s and platform providers so this approach has very much worked for me.

There are a number different areas on a store where you can be promoted; featured, staff picks etc. Some OEM’s have mini stores that usually link to their platform stores like Windows Marketplace or Play. This gives the OEM the ability to merchandise their partner apps without seeking the permission of the platform owner. Nokia has the App Highlights app shipped with all their phones, other OEM’s have their own offering.

My experience of being featured on Windows Marketplace was great for downloads as I suspect being featured would be on other stores. App Highlights worked well until Nokia changed the app due to having to try to promote more apps themselves. This meant my app started to get lost in the sheer number of apps being promoted. The latter being the inherent problem of managing app promotion on store.

Below is a graph of my own experience of being featured on Windows Marketplace and being promoted through App Highlights. There is no halo effect, as soon as the promotion stops the graph returns to the usual run rate. The implication is that you have to continue to promote and market the app to get downloads. As you can see the experience is far more positive than paid-for app advertising. Being featured represented a 1000% increase (800 downloads/day) in downloads whilst being included in App Highlights represented a 200% (160 downloads/day) increase in downloads.

Continuous promotion is crucial

There are other spikes on the graph that are not either Featured or App Highlights. The honest answer is I don’t know what caused them. I only know that my app was featured or highlighted because a) someone told me or b) I happened to know the right people. The other spikes could have been caused by promotion on other parts of the store that I was unaware of or a blog picked up on the app etc. It is usually the case that the developer is not told that their app is being promoted which seems a shame for the developer and the store owner not to be able to capitalize on the promotion.

Conclusion

To get downloads, you need to continuously promote and market your app. I experienced no halo effect, as soon as the promotion stops the graph returns to the usual run rate. For me, getting featured and highlighted was a far more effective solution than paid-for advertising. The key is to build close relationships with multiple OEM’s and platform providers and use it to deeply understand their marketing needs.

Categories
Business Tips

Why You Should Localize from Day 1 (And How to Do it Painlessly)

Continuous Localization

Localization is rarely discussed (and often overlooked by developers), but it is increasingly important in today’s economy where mobile development is a global industry. The United States ranks fourth, behind South Korea, Hong Kong and Taiwan in the number of mobile device users per capita. Singapore, Israel and a quartet of European countries round out the top 10.

Localization is certainly worth the effort. A 2007 paper by the Localization Industry Standards Association (LISA), for instance, reported that $25 dollars was returned for every $1 invested in localization. And a 2012 publication from Distimo revealed that on average, applications increased their download volumes on the iPhone by greater than 128% the week after introducing the app in the user’s native language.

But localization can also be a huge undertaking.

Localization can be expensive and cumbersome

But it doesn’t have to be.

Currently, there are three approaches to translation: manual, automated, and hybrid. Each has its own benefits and drawbacks:

Manual – Employees, contractors, volunteers, or language vendors serve as translators. Emails, FTP servers, and spreadsheets are the primary tools for workflow management.

  • Benefits: Accurate, aware of brand identity, and sensitive to context, tone and style.
  • Drawbacks: Expensive, cumbersome and slow
  • Examples: Applingua, LocTeam, WordCrafts

Automated – Computer software is used to translate text from one language to another. Also known as “Machine Translation.”

  • Benefits: Fast, efficient, and low cost
  • Drawbacks: Imprecise, lacks keyword recognition, and insensitive to style
  • Examples: Google Translate, Bing Translator, SYSTRAN, SDL Language Weaver

Hybrid – Human translators are paired with a localization platform that helps automate the localization workflow for developers, product/localization managers, and translators. It brings the benefits of the manual and automated approaches and the drawbacks of neither.

  • Benefits: Efficient, accurate, and sensitive to context, style and tone.
  • Drawbacks: Initial learning curve upon startup
  • Examples: Transifex with Gengo, OneSky

After a few years of trying to build super-computers that understand human language like only a human can, the localization industry is now leaning toward the hybrid approach that still brings a great deal of processor power to bear. The difference though, is in the personal touch that only someone with skin on can provide. A machine cannot understand context or tone. A machine cannot understand the difference between “manual” meaning “by hand” or “manual” meaning the skateboard trick. It can’t inject energy into a paragraph with an unexpected word choice. Those are things that only humans can do.

When to localize?

Once you select from one of the above solutions, the issue of workflow remains. Decide how your localization will get done, and you will also need to decide when in the development process your app will be translated. Developers traditionally approached localization in one of two ways:

In Development– Some developers opt to add an extra step to the release process after which no strings (also referred to as “segments”) may be added, edited, or deleted. This is sometimes called a string freeze. This gives translators the necessary time to work on and test translations without fear of changes. Following this point, only minor bugs may be addressed – strings cannot be changed.

After the strings are translated, they are returned to the developers for use in the final release. This process is then repeated for the next release of the software. This process slows down the release of the software in all languages quite a bit.

Post-Release – The second approach is to release the software and add translations afterwards. This means some pages will be not translated at all, or for software with a previous release that has been translated in the past, only partially translated. With this approach, companies are unable to do a simultaneous release in multiple languages.

Introducing: Continuous Localization

Using either of these traditional workflows means localization will be performed in large batches, making it incompatible with today’s agile processes. It delays the availability of the software in languages other than the source language. And every delay is a missed opportunity to create new customers and generate more revenue.

A new solution is available that moves at the speed of today’s development teams, without demanding development stoppage. The idea is that as soon as a new piece of content gets generated for your app, it’s made available for translation. As soon as a new piece of content gets translated for your app, it’s made available to your users.

It looks like this:

Continuous Localization

We call it Continuous Localization, and it is really only possible with the use of a Continuous Localization Platform to house and manage the entire localization process in the cloud. These systems, now emerging on the market, harness the power of the cloud and APIs to enable a nuanced human-driven translation at the speed of continuous deployment.

Categories
Tips

Backend-as-a-Service Shootout (the best alternatives to Parse?)

BaaS Shootout - Parse Alternatives

Using a Backend-as-a-Service (BaaS) can reduce development cost and time-to-market. It’s a simple way of getting a highly scalable backend solution without significant upfront investment. This avoids the technical risks of having to scale your own service to meet demand as your user base grows; in a world where an app that hits the store top charts might gain more than a million new users before you complete your next iteration of development this is worthy of serious consideration. In most cases the tradeoff is giving up control of your backend. This tradeoff was brought into the spotlight recently when the most popular BaaS, Parse, was acquired by Facebook. This created a predominantly negative reaction from developers who went from buying a service from a neutral party to hosting their backend with someone many already distrust that has an interest in mining their app data. So, if you’re looking for a BaaS for new project but don’t want to share your data with Facebook, or want to migrate away from Parse, where do you go? Our last survey asked developers using BaaS offerings to rate their primary tool against a range of criteria – the results could highlight some attractive alternatives.

Splitting out the 8 tools which had more than 10 ratings each, the “other” category is still almost 25% of responses and includes a further 11 tools that developers had selected as their primary BaaS. Our own sector page lists 43 vendors at the time of writing, suggesting that the sector is still very fragmented and likely to see consolidation in future.

BaaS Shootout

Some popular BaaS options tied to other tools

Parse was by far the most popular with almost 2.5 times as many responses as Appcelerator’s Cloud Service as the next most popular. Appcelerator’s service is fairly heavily tied to their popular Cross-platform tool (CPT) much like the Sencha offering, which had a very similar number of responses. However, while Sencha’s BaaS had the highest developer satisfaction in our survey, Appcelerator’s was the lowest of the top eight. This situation is the same as the satisfaction levels for the corresponding CPTs. While sencha.io may look attractive on developer ratings, adopting it implies using (at least some of) the Sencha libraries for cross-platform web development too – although this tool scored highly on cross-platform availability (the web works everywhere) there are no native SDKs.

Applicasa switched focus

Just behind sencha.io for developer satisfaction was Applicasa. However, while our survey was running Applicasa were in the middle of a mini-pivot from a generic BaaS to a “Mobile Game Management Platform”, having recognised that the generic BaaS sector was exceptionally crowded. They haven’t yet come out of beta or announced pricing, although this is likely to reflect their value-adding services for game developers. If you’re looking for a BaaS offering with extra functionality for mobile games then Applicasa may be worth a look.

Open source or specialised

Behind Applicasa comes Parse, closely followed by Deployd and CloudMine. Deployd does not yet have a production hosting solution, so it’s currently just an open source project that you host your own instance of on Heroku or Amazon. That’s also an advantage in that you can modify the code and you’ll always control your own data. Another open source BaaS option like this, Helios, was recently launched by Heroku themselves. If you can take on responsibility for some of the maintenance of the backend in order to maintain control of your backend code and data then this kind of open source option is very attractive. CloudMine on the other hand is focussing on larger corporate clients – they’re targeting enterprises and agencies producing lots of apps. Like Applicasa, they’re specialising to target what they see as a more profitable niche and trying to avoid mass market generic BaaS competition.

Further acquisitions likely – select with care

The remaining popular BaaS options in our survey scored below the average for “others” on developer satisfaction. However, just by looking at the top handful we can see some trends for the still immature sector emerging. The generic BaaS space is all about scale. The remaining vendors fighting for this market are likely to get acquired by a larger company, or run out of cash trying to compete. It was implied that there were multiple parties interested in acquiring Parse who are presumably still in the market for a similar solution. If the acquiror of your chosen BaaS is a PaaS vendor then the service should continue to evolve and developers’ data remain private. The large PaaS vendors are likely to build or buy a more complete BaaS solution – we already see this with Helios and Windows Azure Mobile Services. Other companies interested in buying a BaaS vendor might want to integrate with their own analytics (as with Flurry buying Trestle) or other developer services, secure a key supplier or just get a closer relationship with mobile developers. There may also be large enterprises that snap up a small BaaS vendor for their own internal use. Other BaaS vendors will specialise towards specific developer segments.

If, like most developers, you’re still experimenting in the market and not yet building your own services with a long term view then a BaaS that’s specialised to your app category might be a great option. For those looking to select a common backend architecture that they’ll re-use across multiple products, or platform to build on top of for the longer term, the open source frameworks look like the safest option in the current market.

Categories
Business Community Tips

Test Early, Test Often, Test on Everything?

Bugs Everywhere

Testing any mobile app presents a wide range of challenges. The often repeated but rarely followed software best practice of test early, test often is harder to adhere to than usual due to the fragmentation of the target environment and the relative maturity of tools. The increased acceptance of apps by mainstream consumers and intense competition have raised the bars for user experience and quality. There is more to test than ever, yet often very limited budget for doing so. Fortunately every challenge presents an opportunity and a vast array of tools vendors are racing to fill the gaps.

What to test?

Much of the traditional software testing literature focuses on various forms of functional testing – ensuring the system does what it’s meant to do. With a strong trend towards simpler, single purpose apps, this is often the easiest thing to verify in a mobile app project. There is now a much stronger focus on the user experience and this requires testing of an entirely different nature. The most effective way to test that an app is easy (or even fun) to use is to get feedback from real users. Doing that and finding major issues after the app has been built is a very expensive mistake to make, so most developers and designers will want to create mock-ups or prototypes for early feedback. There’s a wide range of tools to help with this task from simple wireframing through to full interactive prototyping. Given the importance of animations within mobile apps to enable users to discover interface interactions and learn to navigate, more complete prototypes are becoming increasingly desirable. As users become more sophisticated and specialist tools reduce the time and effort required to create interactive prototypes this trend is likely to continue.

With the majority of app store revenues coming through in-app purchases, another more specialized form of testing the design of an app is becoming increasingly important – split testing. On the desktop web, tools for trying out design and copy variants to optimize sites for specific user behaviours are very mature and the best of them can be used by staff with no development skills. In the mobile world most of the tools in this space are still very immature and developer-focussed. The responsive design trend on the web and the more restricted deployment options for native apps make this a more challenging problem for mobile devices but we expect the tools in this sector to mature rapidly.

[sectors slugs=’prototyping-mockup’]

When to test?

The earlier you find problems with software, the cheaper it is to fix them. As such, it makes sense to start testing as early as possible. How about testing the idea for the app via a mobile market research service before you even create your first wireframes? It’s worth considering – if you can’t generate interest in your app idea with a simple pitch it’s not going to be easy to get people to download it from the store either.

For most apps (particularly native apps) it’ll be worth using one of the mock-up or prototyping tools mentioned above and test the design before you start coding the real app. It’s much cheaper to iterate a simple design prototype than a native app. However, you’ll still want to try out the actual app with real users before you launch it. To help with that there’s a range of beta testing services that can help you distribute your beta app and find and/or manage testers. There are also services to help you get feedback from your users before and after the app launches. Providing a highly accessible feedback channel for users in the app is your best hope for preventing the inevitable disgruntled few from leaving bad reviews.

Ideally an app will be developed and tested iteratively with functional testing of new features and full regression tests for the existing functionality run for each iteration. This level of testing can get extremely expensive and time consuming unless it is automated. Fortunately there are several tools, open source frameworks and third party services that can help out there too.

[sectors slugs=’beta-testing,feedback-helpdesk,automated-app-testing’]

Where to test?

Another major problem for mobile developers is the scale and fragmentation of the market they’re trying to serve. Collecting a full library of test devices with major firmware variants is way beyond the budget of most developers, let alone the effort that would be required to test manually on all of them. Automated testing solutions can help here also and some services provide access to a large set of devices for remote testing too. However, it’s simply not feasible for most developers to test every version of their apps on all the device and firmware combinations they support. This limitation means some bugs are almost guaranteed to escape into the wild; the important thing then becomes how quickly you discover and fix them. For this reason, crash analytics and bug tracking tools are becoming increasingly important. Another useful weapon in this battle is your usage analytics data – it can enable you to focus testing on the devices which are most popular amongst your user base and also spot changes in use on particular device models that might signal a non-fatal error that’s causing users to abandon the app.

Finally, for some apps, where they are tested geographically may also be important. Do you know what the performance of your app is like for users who are far from your servers? If you use SMS, do you know how long it takes to get to users on different networks around the world (or if it even gets there). Have the localisations for your app been tested by native speakers? Our automated testing and app certification sectors include companies that can crowdsource beta testers or provide access software testing professionals almost anywhere in the world to help you scale globally without leaving your desk.

[sectors slugs=’crash-analytics-bug-tracking,user-analytics,automated-app-testing,app-certification’]

Categories
Business

Usage Analytics Shootout

Usage Analytics

Usage Analytics tools help developers understand their users and the way they interact with their apps. Measuring app usage in this way and using the data to help target improvements to the app can significantly improve revenues. We’ve already highlighted the duopoly in this tools sector, with Google and Flurry dominating. Our survey showed that 74% of developers made use of Google Analytics while 41% used Flurry. Clearly there’s some overlap here with developers using both and in fact less than 7.5% of developers who use this type of tool don’t use either Google or Flurry at all. However, lots of developers work on apps across multiple platforms for multiple clients and they may not always be able to use their first choice analytics tool. We asked developers to rate their primary analytics tool across a range of criteria. This data tells us which are developers’ first choice tools and how they compare.

Analytics Shootout

 

[box type=”alert”]The infogram service is currently experiencing some technical difficulties. We’ll bring back the interactive chart asap. In the meanwhile, you an find the filtered results mentioned in the article here.[/box]

Looking at all responses for developers primary tools Google and Flurry still dominate the market with Flurry slightly closer to Google and more than twice as popular as all of the other vendors combined. All of the tools show very high levels of developer satisfaction with Google slightly ahead overall. Outside of the top five selection criteria the only areas where other tools show significant advantages over Google or Flurry are custom views of the data and real-time analytics. If you have requirements on those areas it may be worth looking at the competition in more detail but for everyone else we can focus on the shootout between the top two.

Google beats Flurry in a head to head comparison

To try to get a more accurate comparison between Google & Flurry we filtered the data down to those developers who use both tools (and possibly others as well) such that they were in a position to make a direct comparison. This produces some interesting results; first, amongst developers that use both, Flurry is the primary tool for a majority of developers (53.1% vs 39.4%); second, on average, developers that use both tools rate Google higher on every single selection criteria, sometimes significantly so. The ratings gap between the two tools is magnified if we weight the criteria by the relative importance developers assigned in the survey. For the most important criteria, ease of integration, Flurry scores higher than Google when all responses are considered but the result is reversed when looking at only those who can make a direct comparison.

The future?

It seems Google has a slightly better tool but Flurry is still holding onto a majority of the developers that have tried both. The explanation for this slightly conflicting result appears to be that Flurry established itself as a leader in iOS analytics early and there is higher adoption of analytics amongst iOS developers in general. So, while Google’s analytics product may have the edge, it’s not sufficiently superior to justify switching for most existing users. Android ports or web apps may use Google analytics but the iOS app sticks with Flurry. This suggests that unless Flurry can improve their offering we may see their market share decline in future surveys as more developers adopt usage analytics. Given developer’s emphasis on ease of integration, the most likely disruption of the duopoly in this market would be an integrated offering – usage analytics combined with crash analytics and maybe also marketing analytics (install/referral tracking) in a single SDK.