Installation and support
Google Analytics is a paid addon for Atlassian Cloud (Jira and Confluence). The purpose of the add-on is for owners of google analytics data to be able to share it with the public. For Confluence, anyone can add a macro onto any page they desire. The macro can be configured to display data from different daterange and chart type. For Jira, all logged-in users of can view the charts, either by adding the gadget to their dashboard or if an admin adds it on a system dashboard.
(Picture below shows multiple charts on one page, inserted into a regular table for side-by-side view))
Google analytics for Atlassian Cloud is available on the Atlassian marketplace
After you have installed, you have to configure. Configuration can be divided into two parts. First, authorizing the application to access your google analytics data. Second to configure what data the users should be able to see.
First part: authorizing. When you click on authorize button, a new tab will open in your browser where you will be redirected to Googles authorization page. After authorizing, the newly opened tab will close. After that you have to refresh the initial page manully.
If for some reason your browser or adblock prevents the new tab from opening, you can copy the link and open it manually.
The second part, this screen will appear after you have authorized and refreshed the page
On the configuration page you must select which analytics view that should be used. Views are defined in the Google analytics dashboard. Usually every website has 1 default view.
The daterange sets which dates the data should be for. All the "Last x days"-options in the dropdown have a sliding end date. Meaning: the data shown today will not be same as tomorrow because the time window will have moved 1 day. There is an option to set custom date range too.
By setting custom range the start and enddate will be as set and will not move. It is not recommended having large daterange as it means more data has to be sent to the users and rendered in the browser.
Please contact us: Support
Google analytics for Atlassian Cloud stores your analytics refresh token. This is needed in order to fetch data from google analytics for your website. The refresh token only allows us access to read analytics data. Not to write or access any other part of your Google account. When the add-on is uninstalled in Atlassian Cloud all data is removed!
In addition, for better user performance we cache the received analytics data for 3 hours at a time.
It is very unlikely this will happen due to all the security measures taken, which you can read more about below. But in the scenario of compromise and the attackers get copy of the sql database, they will obtain access to all refresh tokens. If this happens, Gressquel can within seconds disable the Google analytics API account (which is tied to our google account), by doing so all the obtained refresh tokens will instantly become invalid, thus rendering compromised tokens garbage.
The data is stored in Microsofts datacenter in East-US (Virginia). We use Azure Cloud to deliver our services.
Microsoft has extended report about this subject, which you can read: Protecting-Data-and-Privacy-in-the-Cloud.pdf
Security and backup
As we use Azure Cloud, we also have premium 24/7 security. Operators are online at any given time, carefully monitoring the systems for unauthorized access. Google analytics for Atlassian Cloud uses Azure SQL and Azure app service. Both of these have strict access control. The SQL server only access specific IP addresses to test and deployment system. Even in the unlikely event of compromised credentials, an attacker will not be allowed access to the SQL unless he has the exact IP address as the deployment machines.
In addition, we have intrustion detection systems and monitoring for any suspicious activity, this means even if someone tries and fails to break into the system, the Gressquel admins will be notified and actions will taken if necessary.
On the application layer, we have implemented strict SQL injection protection.
Where can I get more details about security measures
Microsoft has more information, which you can read: Azure security
Through Azure automated backups are taken and stored for 35 days. Within minutes of a disaster or accident, the database can be recovered. SQL Database automatically performs a combination of full database backups weekly, differential database backups hourly, and transaction log backups every five minutes to protect your business from data loss. These backups are stored in geo-redundant storage for 35 days for databases in the Standard and Premium service tiers.
ERT (estimated recovery time), RPO (recovery point objective), we are on premium tier on the table below
|Capability||Basic tier||Standard tier||Premium tier|
|Point in Time Restore from backup||Any restore point within 7 days||Any restore point within 35 days||Any restore point within 35 days|
|Geo-Restore from geo-replicated backups||ERT < 12h, RPO < 1h||ERT < 12h, RPO < 1h||ERT < 12h, RPO < 1h|
|Restore from Azure Backup Vault||ERT < 12h, RPO < 1 wk||ERT < 12h, RPO < 1 wk||ERT < 12h, RPO < 1 wk|
|Active Geo-Replication||ERT < 30s, RPO < 5s||ERT < 30s, RPO < 5s||ERT < 30s, RPO < 5s|
Microsoft guarantees that Apps running in a customer subscription will be available 99.95% of the time.
Microsoft guarantees at least 99.9% availability of the backup and restore functionality of the Azure Backup service.
Microsoft guarantees at least 99.99% of the time customers will have connectivity between their single or elastic Basic, Standard, or Premium Microsoft Azure SQL Database and our Internet gateway.