2019 editions of Windows 10 are on two-thirds of Windows 10 PCs now. Check out our full report here.
Windows 10 May 2019 Update picks up another 11% of April 2018 Update users for a total of more than 56% usage share. Check out the full report here.
Windows 10 May 2019 Update is on one-third of the PCs. Check out the full AdDuplex Statistics Report for August 2019.
Windows 10 May 2019 Update is in a cautious rollout. Check out our Windows 10 statistics report here.
Windows 10 May 2019 Update is shipping now. Check out how it’s rolling out here.
Some time ago it has come to our attention that data in Microsoft’s Partner Center (formerly Dev Center) Acquisitions reports doesn’t seem to be realistic. Specifically, the “Page views” numbers.
Customers noticed that the number of clicks they get on their ad campaigns differs by order of magnitude from what is reported for page views in the Partner Center. And these numbers have to be pretty much identical (minus a tiny percentage of people who cancel navigation mid-redirect, etc.)
We did our own experiment, and for a campaign that got more than 11,000 clicks, only 506 page views were registered in Partner Center. That’s more than 20x difference!
The table right underneath this chart gave us the first clue of what could be wrong:
As you can see, according to this report it seems that our test app is enjoying a whopping 44% click-to-install ratio. Any user acquisition professional would sell their soul for a rate like that. An industry standard is somewhere in 1 to 5% range. Based on our click data (11,000), and assuming that Microsoft’s conversions number is correct (224) we get a click-to-install ratio of around 2%, which is in line with what one should expect.
After additional experimentation, we were able to verify that the cause of this massive discrepancy is a bug in Microsoft’s Store that only counts page views when a user clicks that “Get” button in the web store and proceeds to the Store app. This is obviously logically incorrect, as this click on “Get” is a clear intent to download – hence the magical 44% click-to-install rate.
Not only this is incorrect from the common sense perspective, but it is also in contradiction with Microsoft’s documentation (emphasis mine):
A page view means that a customer viewed your app’s Store listing page, either via the web-based Store or from within the Store app on Windows 10.
We have reported the issue to Microsoft some time ago but are yet to get confirmation and an estimated ETA for the fix. We will update this post once we hear some additional information and/or when the issue is fixed.
In the meantime, keep in mind that the page views number is inaccurate and either use an intermediary (like an URL shortening service) to track visits to your app’s page in the Store or just exclude these numbers from your campaign effectiveness assessments.
On November 17th, 2015 we’ve launched AppRaisin – an app and a service to help Windows 10 enthusiasts discover new apps and games. On August 10th, 2016 we decided to stop active development for reasons I described in a lengthy blog post. On May 6th, 2019 AppRaisin’s story will come to an end…
Since we stopped development the usage went down slowly but steadily. Yet, the distribution between mobile and desktop users didn’t change much – AppRaisin is still de-facto mobile-first app even though Microsoft’s Windows Mobile platform is not really an active thing anymore. We tried to maintain and moderate the service for as long as it provided value for the community and wasn’t a big strain for us. In recent months it just doesn’t feel like we are providing an adequately sized value for the effort.
Even though our efforts were limited in recent years, AppRaisin managed to maintain a 4.8-star rating in the Store which means that many people still find value in it that the official Microsoft Store and 3rd party websites can’t satisfy. So, while this decision was on our minds for more than a year now, we knew that it will upset some people and just couldn’t find the courage to pull the plug. It’s time though…
I would like to thank everyone who worked on AppRaisin over the years, everyone who used the app, submitted and upvoted app news, rated it in the store and provided valuable feedback, every developer who made great apps that enabled AppRaisin to have content, and every person and media outlet who helped us spread the word about our little project.
Update (April 29th, 2019): Looks like Microsoft has fixed the issue with http Store URLs, so it should be safe to use those once again. The “ms-windows-store” protocol workaround described below is still needed if you want to use protocol links.
Last week it has come to our attention that it wasn’t possible to open the Store application on Windows Phone 8.x by clicking on the “Get” button in the web version of the Microsoft Store. We reached out to Microsoft but are yet to hear anything actionable on the subject. This post will cover a workaround that developers may use to mitigate the issue.
Why is this important?
Some of you may wonder “why would anyone care about Windows Phone 8?” That’s a valid question, so here’s the answer:
Here at AdDuplex, we have served more than 11 million ad impressions to more than 3,000 Windows Phone apps on more than 400,000 WP8 devices just yesterday. And we are in only a small portion of available apps and games. While obviously, no one is building their future on Windows Phone in 2019, many developers rely on passive income still coming from their Windows Phone apps to fund their current and upcoming projects.
Plans and calculations have been made on the assumption that the Windows Phone 8.x store will function properly at least until July 1st, 2019.
What’s the issue, exactly?
Developer web sites, ad networks, news sites, blogs, social media posts, and other resources usually link to apps in the Microsoft Store with an official standard link that looks something like this:
At the time of this writing, when you follow such a link on a Windows Phone 8.x device you get to the web version of the Microsoft Store where you see a button to get the app or game. When you click it you are not taken to the phone’s Store app like it was before, and therefore can’t download the application.
To be clear, those super-enthusiastic users who really want it, can still launch the store app manually and search for the game in question and download it from there, but it’s obvious that a lot of users won’t go through the motions or don’t even know that this is what they should do in the situation.
We don’t know when (or whether) Microsoft will fix the web store to work on WP8 as expected. Obviously, Windows Phone is not a priority for the company. In the meantime, we need to take matters into our own hands.
In addition to the HTTP store URL, App identity page in the Partner Center (Your app -> App management -> App identity) contains a Store protocol link which is a scheme that should open the Store app right away. And it does on Windows 10.
Unfortunately and bizarrely, at the time of this writing, these links open Xbox Music (!) app on Windows Phone 8.1 (contradicting both common sense and documentation).
The real fix… or rather a workaround
This is where we got stuck for a couple of days while we assumed that everything is totally broken and only Microsoft can help us. Fortunately, we have a great geek friend, Microsoft MVP and overall awesome person Rafael Rivera (check out his great EarTrumpet volume control app in the Store (duh!)).
Rafael suggested we try several old-school/undocumented protocol options and, to our delight, two of them worked. Namely:
Yes – Zune!
Note: both worked for us every time (both on Windows Phone and Windows 10) but one of our clients reported that the “ms-windows-store” one didn’t work for him while “zune” worked. It’s unclear how thorough his testing was but just to be on the safer side we went with implementing the “zune” version.
You may be wondering where to get the GUID version of your app’s ID? In current Partner Center it’s not presented anywhere on the App identity page. However, you can most likely get it in your .appxmanifest file in your solution or WNS/MPNS (push notification) page under the same App management section in the Partner Center:
What should I do?
We have implemented this workaround for all Windows Phone apps/ads served on AdDuplex, so if this is your only exposure to Store links, then you don’t have to do anything.
However, if you have a website for your app or other places under your control where store links are used, we encourage you to implement the above Store protocol workaround for all your links.
In our testing the “zune:” protocol link worked everywhere, but if you want to be on a slightly safer side and don’t mind some extra work you may differentiate links for Windows Phone 8.x versions of your app (use “zune:navigate”) and Windows 10 version (use the regular http link).
Additionally, please let your fellow developers know about this so they can maximize the returns of the final months of the Windows Phone 8.x lifecycle.
And, please, let us know in the comments or at email@example.com if you have any additional insights or feedback about this issue.