I’m a couple days late getting this post up, but the analytics in this post cover the same range of days as last week’s entry.
The first on the 17th fixed a number of issues and made some improvements in the time billing system. I use the apps to run my consulting business and based on a few things I noticed creating invoices for the first half of the month there are some more tweeks to come. These fixes were delivered by our application services.
The second set of updates changed the app packages to request additional permissions, the first was Read on the site collection. This was required to fix an issue that prevented the creation of content types in app webs installed in subsites. It turns out that this is necessary because the parent content types are part of the site collection’s root web. I will write about the provisioning of content types in an upcoming post.
The other update added a request for app only permissions that will allow impersonation when persisting settings to fix an error when users who are a not site owners attempt to update settings or generate invoices.
The changes for additional permissions required a resubmission via the seller dashboard. We submitted both apps on Friday 9/13 and received approval on Monday for one app and on Tuesday for the other. We watched and the new versions appeared in the marketplace late on Tuesday, but it wasn’t until Thursday that the apps prompted us on our test site that an update was available.
New users will get the new version but old users will not receive the update until they accept the update via the link shown in the screenshot above. How long will it be until we can implement the change affecting users with member access? We will need to implement additional code on our end to check a user’s version and prompt them to apply the update! Even then they could ignore the update so we will need code to accommodate that situation as well.
The primary takeaway is that you should always ask for the highest permission set you think your app will ever need. Getting an update to all of your users later on will be complicated and time intensive. The amount of time required for any update and the fact that such updates to the app package are always optional requiring user consent is another reason we do not like SharePoint hosted apps in the marketplace and prefer our hybrid model or pure provider hosted apps.
Stats, Analysis, and Disappointment in Google
Downloads per day were similar in weeks one and two. We still have not begun any advertising or promotion and we figure it is still too early to expect much word-of-mouth. Therefore this is organic traffic coming from views in the Office 365 marketplace. If the trend continued with no advertising or promotion we would have 1000 installs in a little under six months.
Of course not everyone who installs one of the apps uses it after checking it out. The usage pattern from the first two weeks breaks down as follows:
A little over half never used the app after the first download, but as I wrote last week, half of these people hit a bug that prevented the installation from completing. Over half of the people who managed to complete the install came back another day and there are now real people using the apps to run their small practices!
Trouble with Google Analytics
The InstantQuick site is new and has migrated content from the now retired Elumenotion.com site. I was very concerned when I decided to make the change that Google and Bing would punish the move and we’d lose traffic from search. We use Google analytics on this site as we did on the old site, but this site uses the newest tracking script where the old site used the script from 2007 when that site launched. Looking at the analytics data it appears that the drop in traffic was much worse than expected, but it turns out that there is good evidence that the numbers Google is providing aren’t anything close to accurate!
Earlier this week I wrote a technical post titled Design Tips for SharePoint 2013 Apps on Tablets and Subnotebooks. This site uses Feedburner to syndicate content via RSS and the RSS feed is in turn used by a few content aggregators. Among them is a site I recommend, Planet SharePoint. According to this single aggregator 143 people followed their link to my content in the first day it was available.
Feedburner’s statistics have been unreliable for a long time and they have become even less reliable lately oscillating wildly from day to day so I don’t put much stock in their reporting. But their stats say there were 48 clicks on that article in the feed and that only 10 of them were from Planet SharePoint.
Google Analytics tells me that the page was viewed 13 times.
I’ve done a few other things to confirm this using other pages, but it looks like my Google Analytics numbers are off by over a factor of 10!
Although I am much more interested in the usage patterns of the apps I will need to get to the bottom of this Google problem soon or find a new way to measure traffic on this site!