Topic: Mobile Development in Q3 2013

Survey: The State of Mobile Development in Q3 2013

by Abel Avram on Jul 19, 2013 | 

• Read later
• My Reading List

A recently published VisionMobile study has measured the mobile landscape: the market, developer mindshare, preferred platforms, revenue, developer motivations and others.

VisionMobile carried out an online survey having over 6,000 respondents and 21 one-to-one interviews during April-May of this year in an attempt to evaluate the state of the mobile landscape, measuring the ecosystem, developer mindshare, revenue models and developer tools. The results were published in the Developer Economics Q3 2013: State of the Developer Nation report. The survey was translated in 10 languages and made available through regional agencies in 115 countries from all continents. Only developers using a mobile platform were considered. Following is a distilled version of the most interesting findings of the report.

The Market

For the first time, smartphones have surpassed feature phones in number of units shipped, the move being driven by cheap Android devices which took 75% of the smartphone market in Q1 2013, while iOS claimed 18%. Microsoft is still struggling with only 3% market share.

According to the report, it is “almost impossible for contenders [Windows, Blackberry, Bada, Symbian, etc.] to compete directly and displace” the Android-iOS duopoly, noting that even the strongest challenger has not managed to make a difference in spite of huge amounts of money and developer efforts invested:

Even Microsoft with an estimated over 5 billion dollars invested in Windows Phone has managed to secure a tiny 3% smartphones sales share in 2.5 years since the platform launched.

Instead of direct competition, the authors of the report suggest “asymmetric competition”, challenging the “control points of modern ecosystems: app development, distribution and consumption of apps,” remarking that Amazon and Facebook are doing exactly that. The three control points of a mobile ecosystem are Service Creation, Distribution and Consumption, as detailed in the following graphic:

Mindshare

When it comes to developer mindshare, the report finds Android and iOS topping developers’ preferences with 71% and 57%, in slight decline compared to 2012 when Android and iOS had 76% and respectively 66% mindshare. Interestingly enough, HTML5 is third with 52%, while Windows Phone is down to 21% from 37% in 2012.

While in 2011 and 2012 Samsung sold more Bada devices than Windows phones, its developer mindshare plummeted, the respective OS not appearing in top 10. The authors consider that “Samsung’s bada experiment is coming to an end,” being an “interesting example of the network effects that dominate app ecosystems: user adoption does not suffice in the new app economy.” This leads to the conclusion that

The positive feedback loop must include developers who benefit from an increased user base. If developers are left out of the loop, the necessary network effects will not kick-in and the platform will fail to grow.

Platforms

According to this survey, developers use 2.9 platforms on average and they choose between them based on revenue, reach, delivery speed, costs, app discovery and development environment. The preferred (primary) platforms are Android (34.4%), iOS (32.7) and HTML% (17.3).

The primary platform is the one targeted first by new applications or new features. This platform is the one that receives most attention and investment. Android’s lead is explained by the fact that new developers prefer this platform (40%) compared to iOS (21%). Also, game developers slightly favor iOS (37%) vs. Android (35%), while music and video devs like Android more (36% vs. 29%).

But in order to measure developers’ loyalty the survey asked respondents to indicate the main platform they are using daily. It turns out that most developers prefer iOS for personal use, followed by Android and HTML5 as shown next:

Revenue

When it comes to revenue, iOS leads with $5,200/developer/month followed by Android with $4,700 and Windows Phone with $3,600. The next chart indicates the monthly revenue per developer by primary platform, and includes “revenues beyond app store revenues such as contract development, advertising, e-commerce sales and licensing fees.”

Developers

The survey used the Jobs–to-Be-Done methodology to categorize mobile developers, the authors discovering that there are 8 segments: Hobbyists, Explorers, Hunters, Guns for Hire, Product Extenders, Digital Content Publishers, Gold Seekers and Enterprise IT developers, their sizes, preferred platforms and revenue being depicted in the following chart:

The Hunters and Guns for Hire -”those seeking revenues from the app economy” - represent 42% of the developer population and take 48% of the app economy revenues. They prefer iOS.

Explorers and Hobbyists – “those seeking to learn, have fun and self-improve” -  represent 33% of the mobile developer population and take 13% of the app economy revenues. They prefer BlackBerry 10 and Windows Phone.

Product Extenders, Enterprise IT developers, Digital Content Publishers and Gold Seekers – “aiming at extending a business” – represent 29% of the developer population and take 39% of app economy revenues. They prefer Android and HTML5.

Regarding motivation, most developers are driven by personal fulfillment, followed by commercial success then community recognition as show below:

Other topics covered by the report and not mentioned here are: HTML5, tablets, application economy, revenue models, tools, developer intentshare, and others.

Topic: Big Data & Mobile

The big data advantage: How businesses can better influence their mobile audience

IP Expo 2013

14 Aug 2013 by Nelson Estrada, 14 Aug 2013

Data on what the consumer is interested in, buying and saying to their friends is accumulating every second. When businesses tap into that data to better segment their customers and target their messages, companies can see their profits and customer satisfaction soar.

Big data enables businesses to understand their customers in real-time and through a wide variety of data sources. With the majority of customers going mobile, the amount of data being produced is increasing even more, since data is also being created by apps and other services in the background even when the consumer isn't actually on their phone. This leaves a data trail documenting the consumer's movements and actions. This type of data could be used for a variety of purposes, including the ideas below.

Improve apps

There are hundreds of apps out there, but the majority of mobile customers only continually use a handful of the apps they have downloaded on to their smartphone. App developers can now compare their retention rate to other apps within the same category, and then use user or social data to find out why customers prefer using one app over another.

In addition, companies like BloomReach are working on changing apps to be more friendly to e-commerce by creating a new framework for retailers that is touch-screen friendly, has lots of pictures, and eschews lists of links. With big data, BloomReach has also created a predictive search that relies on the data created by a company's app, website and millions of other searches to predict what a customer is looking for when they just type in a letter or two into the search bar. With similar information, BloomReach also creates a "What's Hot" section on retailers' apps based on what has been popular on sites like Twitter and Pinterest.

Meeting individual needs

In today's world the customer is king. A customer won't stay loyal to a brand if the brand doesn't deliver what they want when they want it. With everyone's needs being slightly different, companies are starting to use data to help customise offers and app landing pages to every individual who comes to their site. For example, your business may find out through social media posts that a certain customer is interested in a new iPod, so you can then send a special offer for purchasing an iPod, or feature an iPod on the landing page of the app.

This data is useful in-store too. US retail giant Walmart is working on an in-store mode for its app that would allow customers to scan items for price and request suggestions for specific products in a certain price range.

Enhance location-based marketing

Location data is the primary differentiator between mobile and web-based data. Due to GPS and check-ins, businesses can access where potential customers are and send them offers when they come near a store. Not only does this help companies reach customers at the right place, but with access to other big data information, such as demographics and interests, the offers can be better catered to each individual.

The beauty of big data is that these are just a few examples amongst a slew of options and creative ideas businesses could use to better reach and understand the mobile client. As big data platforms like Hadoop continue to develop, business leaders will need to consider how much more big data will influence their strategy going forward.

Nelson Estrada is a marketing and operations management analyst at big data platform solutions specialist MapR Technologies
.

Read more: http://www.itproportal.com/2013/08/14/the-big-data-advantage-how-businesses-can-better-influence-their-mobile-audience/#ixzz2fZOFy5Mi

Topic: Mobile Tracking Cookies and UDIDs

Understanding mobile tracking with UDIDs and cookies

April 25, 2012

Michael Dewhirst 

By Michael Dewhirst

There are numerous problems that still need to be solved in the mobile advertising world: patchy cookie support and understanding how they actually work; device identifiers – or, as they are otherwise known, UDIDs – and their inconsistency; and the lack of ad tracking information pass-through within the Apple App store, to name just a few.

The good news? There are offerings on the market right now that allow advertisers and agencies to very precisely track and attribute downloads, conversions and even in-application events such as frequent use, purchases and game-level completion.

In the first of two articles, I will take a look at the problems facing the mobile world, and how they can be overcome.

App download tracking and attribution is a reality right now and the information is usable by media buyers to plug into automated or programmatic buying solutions such as demand side platforms (DSPs) to understand and adjust their buying strategy.

Goal and benefits of trackingBy plugging app download tracking data into a DSP, its learning mechanisms can automatically adjust the buying strategy to buy more of the traffic that has the same profile as that which delivered the best results.

The DSP effectively finds a “pattern” of the traffic that is most likely to result in a download by looking at many variables such as device types, versions, location, time of day, day of the week and the site the ads are shown on.

When there are enough statistics for the events that the advertiser wants to buy such as a download and install, the DSP will find the same recurring set of variable values and make a note of them.

It will then bid higher for such traffic and buy more impressions with such a profile – all on an impression-by-impression basis. And we are talking 10,000-plus impressions per second here. That is 20 billion-plus impressions a month.

A typical traffic “profile” might look something like this: iPhone or Samsung Galaxy S, Sunday and Saturday lunch time, on sites from publisher XYZ and apps from game maker ABC and so on. We actually use about 30 different variables to determine this pattern.

Think of this as a large number of criteria to distinguish between different people, such as personality, hobbies, height, weight, eye color and hair color, as used on a dating site.

The more parameters you use, the more precisely you can identify a person that is right for you.

The result is then a much more focused buy, which has massively larger yields than that of a blind buy that is done in bulk and not on an impression by impression basis.

This way, the advertiser knows exactly who drove the most effective traffic, and can adjust the spend in the right direction accordingly.

What if there is a “missing link”?
How does a DSP – or anybody for that matter - track and attribute impressions and clicks to a download or subscription if there is “dead space” between the “entrance” and “exit” of the mobile app advertising workflow?

The answer is not a single solution, but a combination of approaches and technical implementations, which together deliver the required result.

UDIDs – set up to fail from the start?
Currently, when a DSP or an ad network buys a mobile banner that runs on a mobile media exchange – or a supply side platform, also known as SSP – the latter’s code in the app passes the UDID back, often one way encrypted, also known as hashed.

So, many ad networks quickly adopted a “match the ID” approach where they would record the UDID of the click and ask the advertiser to send the UDID of the device which installed the app to their server, where they would check to see if that UDID is in the click records – attributing the download if there was a match.

But there are several problems here right off the bat:

• Typically, an advertiser will use many different banners to advertise an app and the above approach does not precisely pinpoint which banner drove the download. And no, you cannot always argue that last view or last click won.

• Secondly, the exchange may be sending the UDID hashed using one algorithm (e.g. SHA1) and the advertiser may be sending it hashed using another (e.g. MD5) – so there will never be any match. A bit like trying to match a phone number and a ZIP code. They are just never going to match, even if they are for exactly the same house.

• Thirdly, the Android operating system has several IDs available to app developers – AndroidID, IMEI, MEID or ESN. Exchanges and advertisers often will use and send different ones again. Combine that with different hashing algorithms and it is a right mess.

• Lastly, Apple is deprecating the UDID and it will no longer be available within apps to be pulled out by the SSP SDK, so this free ride will end soon. There will be other IDs one can use on the device, such as the Mac address of the WiFi card, but this may not be very reliable either for several reasons.

There is often a lack of clarity when setting up a campaign between the advertisers, agency, media buyer and the exchange and again, the wrong IDs are often compared and therefore never match. Many attributions are missed and do not go back into the mix, driving up the cost of the download and reducing their number too.

One more reason still to ditch the UDID
If this is not enough to convince you, the last and one of the main other problems with this approach is that only media that is running inside an app – and not media seen on mobile sites in a mobile Web browser – can be bought if UDIDs are to be used for download attribution.

This is because a UDID can only be obtained when you have access to the operating system API, i.e. you are some code running inside an app.

If you are a simple meat-and-potatoes HTML page or even a fancy one with some JavaScript, you just cannot get the UDID of the device you are being shown on.

It is like arriving in a building blindfolded and only being able to go into one room with no windows to the outside world. You will not be able to work out where you are unless you can peak outside and glance at a street sign.

This is a problem because there are a huge amount of mobile-optimized sites which could be driving punters to the app store to download that app. Hundred percent more, in fact, in addition to the app traffic.

The net effect is that app inventory becomes more sought-after and, in turn, the price, yield and cost of a download goes up. Yes, this keeps the app developers happy – which is not necessarily a bad thing – but does not benefit anybody else.

“But if the app stores are a dead-end where advertising tracking dies, how do you tie an impression to a download without a device ID?” you ask.

Surprisingly it is back to the old veteran – the cookie.

Back to the cookie
Cookies actually work fine on most mobile devices, especially on all the main ones that have app stores and apps, such as iPhones, iPads, Androids, BlackBerry phones and Nokia devices.

If they did not, many sites where you have to log in such as Gmail, eBay and Facebook would be pretty hard to use as the site would not remember who you were from page to page.

Those that do not work are some feature phones, where you cannot install apps anyway, so who cares.

So a cookie is a bit like that ultraviolet stamp that a bouncer would put on your hand so they know who you are after you pop out for some fresh air or a cigarette and decide to go back in.

The only issue that exists with cookies is on the Apple operating system, iOS – but only with the setting and not reading – of third-party cookies.

If you are not sure what I mean by first- and third-party cookies, I simply refer to the domain of the page you look and the domain of the server where the tracking cookie was set from.

For example, let us say you are looking at a page on Amazon.com and there is a tracking pixel pointing to strikead.com, which tries to set a cookie. This strikead.com cookie will be classed as a third-party one as it is not from the same domain as the page you are on.

Cookies from Amazon.com, however, are first-party since they are from the same domain as the page.

Setting a third-party cookie in iOS Safari, the iPhone browser, will not work. The attempt to set a cookie will be blocked by Safari.

However, reading both first- and third-party cookies is just fine on iOS Safari on the iPhone, iPad and iPod touch.

Getting to cookies from an iPhone appThat is all fine and dandy, you say, but how do I read that cookie from inside the app?

The simple answer is – you cannot, since Safari is just another app and apps on iOS cannot share data for security reasons. The longer answer is you can, but there are a few workarounds to be done.

The problem with reading cookies from inside an app is that they are set in the device’s browser, and only it has access to them.

You can, however, launch one app from another. For example, you could launch the device’s Web browser, such as Safari, from inside the downloaded app.

When you do so, you tell the server to go to the same tracking page where the cookie was set earlier during the click.

You can also pass the server any necessary information for the download to be attributed to the click and this information gets passed to the server.

The server then tells the browser to go back to the app it came from and the loop is complete. No more “dead space.”

It may sound like magic, but this is possible and it works very well.

The only negative effect of this process is a brief “flash” of the browser window whilst you are in the app – a few hundred milliseconds – blink and you definitely will miss it.

Many advertisers are already using this method and have found that it does not affect user experience and only gives them much better insight into the app life.

Think back to the desktop computer and the standard browser – pop-ups are still common there and nobody really cares about them.

What about Google Play?
Good old Google, being deeply steeped in advertising, understands that certain things need to happen for the advertising machine to keep turning its wheels and provide free app developers with a source of income.

So, Google Play – the former Android Market – actually has a mechanism which allows variables to be passed to it from a click on a banner and from there to be passed to the app. The app can then pass this information back to the media buyer for attribution and optimization.

So for those advertisers who really cannot have a pop-up in their app – at least on Android – there is a way.

Technology is here nowThis technology is a reality now.

It is clear that there are solutions out there to make mobile app advertising more successful and cost-effective, but it will take the triumvirate of the advertiser, agency and media to adopt them.

Without all three parties understanding the options and using them, nothing will happen – or at least not easily and not quickly.