Interpreting the statistics in the AdDuplex monthly report

Every month AdDuplex, the leading cross promotion network for Windows Phone and Windows Store apps, releases a report with statistics on devices running apps that have their advertising controls embedded. You'll find the latest one (for March 2015) on their blog at http://blog.adduplex.com/2015/03/adduplex-windows-phone-statistics.html

*disclaimer - if you didn't know, I'm a paid advocate for AdDuplex and help in preparing the report*

As happens every couple of months, there has been some discussion about the relevance and completeness of the data used to prepare the report.
I want to address some of these points and add some clarification over what the report actually shows.

Firstly, let's be clear on what the report is.
The report is an analysis of the devices used to show ads from the AdDuplex network on a particular day. It does not attempt or claim to be an analysis of all Windows Phone devices in use worldwide.

If it's not a complete picture, what's the point of the report?
The report serves three purposes:
1.  To provide information to developers who are or are considering using the network.  This was the ultimate aim when the report was first published. To help developers. After all helping developers to best promote their apps is one of the core aims behind AdDuplex.
2.  To raise the profile of the company. Because no one else is publishing such reports this is the best view of the device landscape available and so is newsworthy in appropriate circles.
3.  It’s better than nothing. Without this report, how would you know which devices are actually in use? At best you'd rely on anecdotal evidence or data collected from a smaller sample set.

It's the first point that is most important!
With this information developers can be aware of which devices are most likely to be used to run their app. It's really easy to assume that other people are like you and, just as much as anyone else, developers often fall into this trap.
In general, most developers I speak to who have and use a Windows Phone have a higher spec device. At the moment they're mostly the Lumia 930, 1020 or 1520. Based on this it would be easy for developers to only think about such devices and how their app looks, performs and behaves on such.
However, through looking at the data in the report it is clear that the majority of devices in use are not like these. 60.8% of devices in use are Lumia 5XX and Lumia 6XX devices. These devices have smaller, lower resolution screens and less powerful processors. Without paying attention to it, the experience of apps across different devices can change and be less than desirable in some instances. For this reason it is important to check apps on different devices. This is even more important when the majority of [potential] users are on such low spec devices.

But this still isn't representative of all devices!
There's an argument that people who pay more for a device are less likely to be tolerant of ads in their apps and so won't use them or will pay to remove them. The corollary of this being that people who pay less for their device have less disposable income and so are more likely to be tolerant of having ads displayed in their apps. This argument is based on anecdotal evidence at best as is also likely to be skewed by cultural biases as people in some parts of the world are more tolerant of ads and readily accept them.
Whether the opinion or anecdotal evidence reflects reality or not, this is a point that needs to be addressed.
AdDuplex are not able to answer this question, don't attempt to and for the sake of informing the people who are using their network it doesn't matter.
- Due to the way that the data is gathered, from apps that are displaying ads, it is not possible to report on devices running apps that don't show ads.
- The report is clear is saying it shows data based only on devices running apps that contain their ad control.
- If you're a developer looking to show adverts in your app then the devices of people who don't use apps that contain ads are not as relevant.

For those of you who are particularly interested, here’s an official comment from AdDuplex on this matter:

The accuracy of the stats we gather is obviously affected by a lot of factors. These range from differences in incomes in various countries to accessibility of mobile internet to the effect of bigger apps and games that we have and the audiences that they target. An argument that people with higher end phones are more likely to buy paid apps is probably correct on a logical level, but it doesn’t mean the opposite – people who are likely to buy paid apps are not less likely to use free apps too. People who are “allergic” to ads come in different shapes and forms of personal income and device preferences (not everyone who can afford an expensive phone necessarily buys one). On the other hand the argument could be made that more of the owners of cheaper phones don’t have access to mobile internet (or have a limited/expensive access) making them less likely to see the ads in apps. More people who buy cheaper smartphones necessarily use them as one (never download any apps at all). It is also worth noticing that not all of the apps and games run on 512mb memory devices, potentially skewing the stats in favor of more expensive devices. All-in-all you can have a number of arguments tilting the scales in favor of one theory or the other, but there’s no data to quantify these effects. At the end of the day with data coming from more than 5,000 apps of various types and calibers, I think the results even out quite nicely and, while no statistical report can be 100% accurate, I’m sure we paint a pretty credible picture of the ecosystem as a whole. And I’ve heard off the record confirmation of this from people who’ve seen the “real” numbers.

Wouldn't it be nice to have more?
Yes, from a point of curiosity there are lots of things that it would be useful to know about what devices are in use, where they're used and what apps are used on them.
There are also strategic and tactical decisions that could be better made with this data.

So why aren't reports with this data published?
The main reason is that the only people with the complete data are Microsoft and there are almost certainly competitive and legal reasons not to release all the data. They have released some in the past (the last was in September 2014 http://blogs.windows.com/buildingapps/2014/09/29/windows-and-windows-phone-store-trends-september-2014-update/) but there is a lot they haven't shared with us.

Could anyone else provide more information?
Possibly. It depends on what data you want though.
If you're just after an analysis of all types of devices in use you need analytics from a publisher (or publishers) who has a free app (or apps) used worldwide.
If you want to compare free, ad supported and paid apps then you need aggregated data of all such apps across all territories you're interested in.

There are probably only a handful of publishers who have sufficient data to provide this analysis.
Other advertising networks or analytics providers probably have the information to produce such reports.
Here's the catch though, there is no incentive or commercial interest for any of them to produce and share such a report so I don't expect any of them to do so any time soon. Should anyone do so, I be as keen to read it as anyone.


It may not be everything that everyone would like but the monthly AdDuplex report provides an insight into what devices are being used by the people who use ad supported apps.
It's also the best public information there is.

I've started building my first windows 10 app

No, I don't have the SDK but that doesn't matter.

I'm building an app that will exclusively target the phone but requires capabilities that aren't available today (in 8.1) but do currently exist on the desktop for Windows apps. 

I'm assuming that what Microsoft are telling me about being able to build one app that can run on all devices and the convergence of APIs will mean that the capability will be available on the phone when the Windows 10 SDK is available.

Planning is the most important step in development anyway so doing most of the work before the API is available (but assuming it will be like the existing desktop version) means I'm not blocked by a lack of SDK.

I want to be ready for when the tools and store become available so I can make the app available as soon as possible.

What if the API is very different or doesn't allow the functionality I want when it is released? 

I'm allowing for some level of difference in the APIs so am not expecting it to be completely painless when the tools are available. 

If it's a very large difference and requires massive effort I can reevaluate then. 

If the app won't be possible when the SDK is available I'm not losing a massive amount of effort as it's a simple app. 

I think the risk is worth the initial effort and I'm learning things now in terms of having to think about what the app should be like and how I will design it for a great Windows 10 experience.

It's taken me 5 years to come to this realization about Windows Phone apps

For many years I've had the idea that you should wait before you publish your app to the store until it's the best it can be. Add all the features, polish it thoroughly, test extensively, that sort of thing.
It's part personal opinion and also, I believe, part a culture thing - I know this isn't a common attitude in other parts of the world.

However, I no longer believe this. As soon as it's "good enough" - submit it.

What's "good enough"? - As soon as it can provide use or value to the person using it.

The benefits of getting feedback from having real people use your app will far out-weigh any benefit from you tinkering with the code or adding one more feature before you do.

I'm not saying don't test your app, or don't fix bugs, or that features don't matter. I'm saying that feedback from real users matters more.

Being first to market doesn't have an impact in most app categories. And are you really defining a new category in your app?



But here's the most important thing:

Getting an app in store is the start of the real process, not just the end of the initial development one.

Putting off launching your app on the public isn't helpful. Ship it. Get started.


When you haven't released it can be easy to put things off, to wait before adding a feature, to defer fixing that bug until another day.
When you have actual users asking for the feature or being affected by the bug there's a greater incentive to make the change. This will often lead to you having a better app in the store, with more users, sooner than if you'd waited until you did everything before releasing it.


To be clear
I'm not saying, don't test it or release it untested. There is a big difference between releasing to beta testers and releasing to the public without having tested it.
This isn't for every app. If you've not developed an app before. Just make something simple and learn the process of submitting to the store with that. Don't dive in with your first app being a highly complicated one.


Disclaimer: this above is focusing on smaller, developer driven apps. If you have a large brand name or are planning a high profile launch then there is a greater reason to get more features and functionality in the app for launch. I understand that and hopefully you do too ;)

Slide view / splitview / side draw and a hamburger are not necessarily the same thing

There has been a lot of discussion about some of the native apps in the Windows 10 technical preview releases using a hidden menu, accessed via a "Hamburger icon". Some people have taken great offence to this and object to it's use in Windows Apps.
Let's get a few things clear though:

• The hamburger icon is a variation on the icon for a list that represents a menu (a menu is just a list of options anyway)
• It's typically used on a small screen device, where space is limited, to allow for the person using the software to cause the menu to be displayed. The menu is not typically shown all the time because of the amount of screen real estate it requires.
• In addition to being useful on small screen devices, it's also useful when the size of the window can be changed and vary greatly.
• The idea is to hide the menu off screen until it's needed.
• The downside is that the person using the software doesn't know what's in the menu until they open it. If they don't use it regularly and/or it contains a long list of options then they have to remember what's there. Or, more likely, they have to open it to see what options they have.
• How the menu is displayed is not related to using the "hamburger" icon to represent it.
• You do not have to use a side draw or slideview to show a menu.
• Using a side draw or slideview does not require the use of a hamburger icon. You could use something else. Even text.
• It's a convention though. Many people already recognise the hamburger icon (even if they don't call it that) and have an expectation about what it will do.

You don't have to use a hamburger icon in your [Windows 10] app.

Native API usage from Windows 10 web apps

When Microsoft demoed the packaging of web sites at MWC last week, I noticed an interesting thing. The demo was hosted on a public website: http://contosotravel.azurewebsites.net/.

As all the logic for the extra new functionality exists on the web server (in the javascript served with the page), I wondered if this was public also. They may have been detecting appropriate user agents and only serving the functionality to devices which can use it.
It turns out they weren't and examples of the new API usage exists (minified) at http://contosotravel.azurewebsites.net/main.js

Through the help of http://jsbeautifier.org/ I was able to tidy this up a bit and find some examples of things that can be done. And yes, they look a lot like WinJS. **Disclaimer** this is all pre-release and so may change. I only know what was said publicly at MWC and what I found looking at the JavaScript on the above public website. If you find anything else interesting in the

Microsoft removed 2 reasons for building an app for a website...

... by making it possible to bundle a website as an app.

At MWC last week Microsoft announced that in Windows 10 it will be possible to package websites for distribution via the store. Additionally, when the website is viewed after having been installed from the store it will have access to device APIs (via javascript).

This actually removes two of the reasons that used to exist for creating an app equivalent for a website.

1. Discoverability (via the store)
2. Access to device specific functionality.

In some circumstances there are more but these are the main ones.

1. If you can package a website as an app just to help people discover it in the store then there's no need for a separate app. This is a good thing. If you have a website that works perfectly well on Windows devices you shouldn't have to create an app just so you appear in the store.

2. Access to device specific functionality is normally only available through native APIs. This was a strong reason for needing to build an app previously. Of particular general use was the ability to use push notifications to inform people of new content. As this is (will be) now available to websites installed through the store it is no longer a reason to need an app. Additionally access to contacts and calendars will also be available, further removing necessities to build an app.


Here's the other important point. The packaging for the website is simple. It's a manifest defining the URL and the permissions/capabilities required plus some store specific assets. (images, description, screenshots, etc.)
You won't have to include all the files that make up the website/webapp and ship them to the store. They will stay on your server. This will make updating and modifying the site (app) much simpler than if it had to go through the store.

There are some potential gotchas though too:

• You won't have access to this extra functionality if the site is not being accessed after having been "installed" from the store. You may have to detect this and advise the user appropriately if they want some functionality that is only available when "installed".
• By blurring the lines between web site and installed app you may have to make this extra clear to your user what this is and how it works.
• The browser in Windows (8.1 & presumably 10) has a user agent that many websites can mistake for Android or iOS devices. Be aware of this and consider your device detection carefully. It might look very bad if a website is installed as an "app" only for it to display messages to the user telling them to 'install the Android app' when they try and use it on their Windows 10 device. I see this quite a lot from sites on a Windows Phone 8.1 device and it just reflects badly on the site.
• You'll still need to make sure that your website works on all devices and only exposes this, new, Windows 10 specific functionality on appropriate devices. Yes it's more work but probably less than maintaining a separate app.

**Disclaimer** all the above is based on comments made by Microsoft at MWC. There was no recording and the information was made publicly only to those people in the room. I was there so you'll just have to trust me. Also, the information released wasn't final so all this may change and the feature/functionality may even get cut.