If you’re selling an extension, check out my project Analytics for Google Payments Center.
Earlier this year, I launched my first paid Chrome extension: Autoplaylists for Google Music. The non-software work involved - like organizing a beta, wrangling paperwork, and finding users - was a bit daunting to handle solo. So, to help other first-timers publish their side projects, I’m writing up my experiences and making recommendations.
This post focuses on analytics and error reporting. For the first post on the tax and legal requirements of selling an extension, see part 1. If you’re interested in reading future posts, consider subscribing to my RSS feed.
Analytics lets you track how your extension is being used and found, while error reporting lets you find bugs users may not otherwise report. Without them, you’re sticking your head in the sand.
I recommend the free tiers of Google Analytics and Sentry. If you’ve used them before, know that there’s a bit of extra work involved to make them effective in an extension.
I use Google Analytics heavily. It helps me answer questions like:
To handle all this, Analytics runs on my web store page, the extension itself, and autoplaylists.simon.codes. They all report into one account as separate properties.
Hooking up the web store and homepage are trivial. Adding reporting to the Chrome extension itself is a bit more involved: you’ll need to use the Chrome Platform Analytics library. In addition, be sure to:
I’ve linked my code above as examples.
Now that Analytics is running, you should customize it a bit. The web store is simplest: track installs by setting up a destination goal for “begins with /track_install”. I plot goal conversions and completions on the same chart and have it emailed to me weekly. I haven’t figured out a good way to track other web store events like reviews and comments.
Customizing reporting for your extension will of course vary based on what you’re doing. I’d recommend at least adding app views for your UI and an event for loading the extension. To give you some ideas on what else to track, here are some examples from Autoplaylists:
Once basic error reporting is working, there are two extra steps you should do every time you publish a new version: create a Sentry release and upload source maps. These will help you track down exactly which changes introduced an error. I’ve written a script that automates both steps (it also publishes my extension via Google’s web store api).
Keep in mind that Raven will only automatically collect exceptions, which Chrome apis don’t raise (they use lastError instead). I’ve written a decorator that will automatically send these errors to Sentry as well.
Finally, here are some parting tips:
Feel free to shoot me an email if I can help with anything: firstname.lastname@example.org.