When you open Local for the first time, two dialogue boxes open and ask users to enable reporting. Local has two preferences that control what data gets sent back to the Local team: usage reporting and error reporting. You can change these settings at any time from within Local’s “Advanced” section of the “Preferences” menu.
Enabling these preferences helps us make Local an even better tool for WordPress development! Reporting is completely optional, but by getting this information back to our teams it helps us understand how we can improve Local and where we can focus to make the biggest impact.
So what exactly is collected, and how does it help make Local better?
Usage reporting focuses on answering “What features are most used?”
Having usage reporting turned on also allows us to quickly find features that aren’t working as expected. For example, we noticed a sudden drop-off in usage of Local’s Live Links. When we took a closer look, we were able to find, and quickly fix, an issue with this popular feature, without needing a bug report from our users!
This data is completely anonymized with a randomly generated userId and cannot be traced back to an individual user. These events are viewed in aggregate to help the Local team prioritize improving the highest impact features.
Examples of the reported events are:
- “New site created”
- “Live Link enabled”
- “Open Site Admin Button clicked”
- “Image Optimizer optimized an image”
We all want a flawless app, but errors do happen. The fastest way for the Local team to find and fix bugs is to have enough information to replicate the issue!
When error reporting is enabled, Local automatically provides the most valuable details for replicating bugs. These details include things like:
- the type and version of the operating system
- the version of Local
- the programming steps (stack trace) that led to the error
Like usage reporting, this data is anonymized and is only used to zero in and fix product bugs!