We run a fairly popular chrome extension with 200K+ installs and 70-90K active users (according to chrome webstore reports)
We have noticed that our numbers have started dipping in the past two months, despite a steady stream of hundreds of new daily installs. These numbers are different but broadly correlate with our Google Analytics numbers.
We suspect that some fraction of our installs are not being working, either because of some browser version-specific bugs or because it is being blocked by an anti-virus.
How do we know for sure? There doesn't seem to be some easy error reporting that we can rely on and the only other option seems to involve trying different versions and anti-viruses to see if this is true. Is there a better method?
Provide an after-uninstall form (using chrome.runtime.setUninstallURL - since Chrome 41) where a user can select the reason for uninstalling. Some extensions (ZenMate, for example) do it.
Related
If I look inside of the Chrome Web Store "Analytics" section, it shows a certain number of installs over a specified time period. Google Analytics shows a totally different number. Why?
I've integrated my Chrome Web Store page with my Google Analytics page, for better tracking information. Installs are apparently reported in Analytics as page visits to a URL that contains "track_install". (I assume that's the case; there's shockingly no documentation I can find on, how to track any sort of conversions, install rates, etc, of Chrome Extensions, via either Google Analytics or Google Ads.)
My question is, why am I seeing such wildly different numbers between the two sources? Google Analytics is under-reporting installs by a factor of around 4, versus what I see in the Chrome Web Store page.
Any idea what is causing this, and how to resolve it?
Thanks
After publishing a new version of our extension to production, we sometimes see a weird behavior:
The extension on the browsers seems to be only partly updated (after given some time).
Our internal version number (part of our code) shows in such cases a previous version number, although some features and resources from the newer version already exist.
We have seen this occasionally in all browsers and on different operating systems.
Any idea why is that and what can be done?
Note: our extention.js and popup.html files are about 380kb (I don't know if that makes any difference).
Whilst I don't know the specifics of your scenario, in general, updates are automatically checked for and pulled if required by the extension several times a day. If there is anything that interrupts the process such as connectivity problems, then a partial update may occur though there are mechanisms in place to try and protect against this. Also, note that resources update if there are changes to one of the core files (extension.js or background.js).
[Disclosure: I am a Crossrider employee]
Is there a technical reason, why a Google Drive application must be installed through the Chrome Web Store (which severely limits the number of potential users)?
The reason that installation is required is to give users the ability to access applications from within the Google Drive user interface. Without installation, users would have no starting point for most applications, as they would not be able to start at a specific file, and then choose an application.
That said, I realize it can be difficult to work with in early development. We (the Google Drive team) are evaluating if we should remove this requirement or not. I suspect we'll have a final answer/solution in the next few weeks.
Update: We have removed the installation requirement. Chrome Web Store installation is no longer required for an app to work with a user's Drive transparently, but it is still required to take advantage of Google Drive UI integrations.
To provide the create->xxx behaviour that makes a new application document from the drive interface, and to be able to open existing documents from links, there must be some kind of manifest registered with Google's systems and some kind of agreement from the user that an application can access your documents and work with specific file types. There's little way around this when you think about the effects of not doing this.
That said, there are two high level issues that make for compatibility problems.
As the poster says, the requirement to install in the chrome store
severely limits the number of potential users.
But why? Why do the majority of Chrome Web Store applications say that they only work on Chrome? Most of these are wrappers to web applications that work on a range of browsers, yet you click through a selection and most display "works on chrome", aka only installs on chrome.
Before we launched our application on chrome we found that someone had created "xxxxxxx launcher" in the store, that simply forwards to our web app page. We're still wondering why it only "works on chrome". I suspect that some default template for the web store has:
"container" : "CHROME",
in it, which is the configuration option to say chrome only. That said, I can't find one, so I'm very confused why this is. It would be healthier if people picked Chrome because it's the better browser (which it is in a number of regards), not because their choice is limited if they don't. People can always write to the application vendor and ask if this limitation is really necessary.
The second thought is that a standardised manifest format across cloud storage providers would mean a much higher take up in web app vendors. Although, it isn't hugely complex to integrate, for example, with Google Drive, the back-end and ironing out the the details took over a week in total. Multiply that lots of storage providers and you have you lose an engineer for 2 months + the maintenance afterwards. The more than is common across vendor integration, the more likely it is to happen.
And while I'm on it, a JavaScript widget for opening and saving (I know Google have opening) by each cloud storage provider would improve integration by web app vendors. We should be using one storage providers across multiple applications, not one web application across multiple storage providers, the file UI should be common to the storage provider.
In order to sync with the local file system, one would need to install a browser plug-in in order to bridge the Web with the local computer. By default, Web applications don't have file I/O permissions on the user's hard drive for security reasons. Browser extensions, on the other hand, do not suffer from this limitation as it's assumed that when you, the user, give an application permission to be installed on your computer, you give it permissions to access more resources on the local computer.
Considering the add-on architectures for different browsers are different, Google first decided to build this application for their platform first. You can also find Google Drive in the Android/Play marketplace, one of Google's other app marketplaces.
In the future, if Google Drive is successful, there may very well be add-ons created for Firefox and Internet Explorer, but this of course has yet to be done and depends on whether or not Google either releases the API's to the public or internally makes a decision to develop add-ons for other browsers as well.
I'm developing a Chrome App (as a packaged app/extension) which purpose is to act as the base platform for several fullscreen apps to be build on top of. Chrome will be running on Ubuntu Linux.
And no trouble so far. But then I was told, that an intended app it is to be the platform for requires the source code to be updated with very short notice, as it probably is to be deployed for large scale use before the system has been tested through (even though it's a bad idea to deploy software that's not completely stable, but we're on a tight schedule). The problem is, that the "a few hours" interval for the autoupdating mechanism just isn't good enough.
So I somehow need to have the updating interval changed. I know this can be done with the --extensions-update-frequency command line switch, but as apps cannot access the command line (for obvious security reasons), and I'd prefer that the intended background page was to handle all the "administration", I don't think that switch is possible to use.
Is it somehow possible to update at a higher frequency? Or at times when it's ordered to?
There is now a method chrome.runtime.requestUpdateCheck():
Requests an update check for this app/extension.
It will return a status, which can be either "no_update", "update_available" or "throttled".
Unfortunately, the docs do not specify the limits for frequency that will trigger "throttled".
Your best option will be to have the extension manually check with your servers for an updated version. If there is an updated version show the user a desktop notification to manually update.
Potentially you could write a NPAPI plugin to modify the update frequency.
This may cause issues with CSP but you can try to live load JavaScript from your server that executes in the extension. In this case to "update" your extension you would simply update the JS hosted on your servers and the extension would automatically start using it on next load.
Curious if anyone's seen/heard anything on the ability to use Chrome Profiles to allow synchronization of data contained within extensions between computers.
Put another way, I would like the ability to synchronize / access localStorage from multiple computers signed in with the same browser profile.
Nothing from Google on this now, AFAIK. Anyone know any differnetly?
Chrome has an experimental API that allows syncing of data. Hopefully it will be in stable within the next couple of months.