SourceTree's analytics is designed to discover how users are interacting with SourceTree. Here's information that we do and don't collect.

What we DON'T collect:

Personal information. We define personal information as information that, alone or when in combination with other information, may be used to readily identify, contact, or locate a specific individual, such as: name, address, email address, or phone number.

Information about the content in any repositories.

What we DO collect:

Which buttons and panels you chose to interact with. For example:

Did you use the keyboard to commit (shortcut)?

Did you select 'Push commits' from the commit sheet (cascade)?

Did you use the toolbar to pull changes (click)?

Did you stage in Git using the staging area by dragging files (drag)?

Very basic system information, such as your system locale, screen resolution, and OS version

Counts of various statistics, for example:

How many bookmarked repositories you have

How many hosted accounts you have

How many repositories have been opened in a twenty-four hour period

Whether certain SourceTree preferences are set i.e. whether you use the staging area, or if the command line tools are installed

If at any time you wish to find out more about this you can open a support ticket over at support.atlassian.com.

17 Comments

Anonymous

Wow, this is the clearest privacy policy description I have ever read.

I came here because I really like SourceTree, and I like the idea of giving automated feedback that's used to further tune the app. This description of what is recorded first confirmed my belief that nothing private is collected and then clarified exactly how my interaction with the software refines Atlassian's understanding of how we all are using it.

Anonymous

Outstanding work on the way this feature got implemented. Both in terms of introduction in the product and the amazingly clear description above of why/how you use the info. Looking forward to our behaviour making Source Tree an even better product than it is today!

Anonymous

Anonymous

Wanted to add my voice to the chorus of those offering kudos for by far the best roll out and explanation of background usage tracking I have every seen. This is the first time I've ever said yes to this sort of tracking, and it's all because a) the product is awesome and I love how quickly it improves and b) how clearly this change was explained before I was offered the choice.

Kudos for the transparency. For "Outstanding", though, I would have needed the answers to the following questions: "How much does the recollection of this information affects SourceTree's performance?", "If I choose not to share this info, does it mean the software stops collecting it or simply that it does not send it to its overlords?" and "How can I verify/contrast which info is being sent?" . Not trying to be a prick, just curious about the answers to these questions...

Fair questions, it's a balance in the main article between stating everything and keeping it brief enough that people will read it

"How much does the recollection of this information affects SourceTree's performance?"This was a major consideration during development and we did a lot of load testing to make sure it didn't affect performance. While it can never be zero overhead, all the analytics 'events' are queued into a low-priority, serial background queue so they're never blocking anything you're doing, and the logging is actually pretty cheap anyway. We're monitoring it closely but all evidence so far is that it's not noticeable.

"If I choose not to share this info, does it mean the software stops collecting it or simply that it does not send it to its overlords?"It stops collecting.

"How can I verify/contrast which info is being sent?"In the Application Support / AppData folder for SourceTree a file is built up per day named YYYYMMDD_<randomguid>.txt. Each day starts with a bunch of summary info like OS version number, the number of bookmarks you use etc, then a line is added when you perform the major actions so we can tell which buttons / views you're using most etc - important when we're considering any design changes. The file is zipped and uploaded (then deleted) after a day's rollover.

The collection of data is placed on a low priority background thread, so you shouldn't notice any performance drop in SourceTree at all.

If you choose not to share the data then SourceTree will stop collecting data altogether, so no background threads issued at all, nothing collected. The first thing it does before collecting any data is check if analytics is enabled, and if it's not, it won't do anything at all.

We store a load of data and then summarise it. All of the data is stored locally in your application support directory, you can actually see the text files in ~/Library/Application Support/SourceTree/ being generated ready for upload the next day (one file per day)

Anonymous

I like this approach - good job on the clarity. However, one thing is stopping me enabling it. There is no policy on what happens when you decide to change what data gets analysed and sent over. Are the changes silent? Do I have to keep checking this site periodically to see if it changes? Will you visibly inform me of the changes on each new release? Will I have to scan the updates text?

What I'd consider an ideal "opt-in" approach would be that whenever you change what data you collect you disable the feature and require us to enable it again, like it does now.

We will not change the nature of the data we collect as set out in this page; i.e. that we never collect personal data or any information about your specific repository contents, but we will be tracking which features you use in order to influence design decisions. If we ever changed the fundamental principles of what is collected (and I can't imagine that ever being the case, but hypothetically), then absolutely a new opt-in would be required. But we will tweak the feature tracking over time, for example as new interfaces are tried out, or if we need to get a more detailed idea of which elements of a screen you're using (or not). None of this changes the spirit of what is collected, but yes the minutiae may fluctuate over time - that's really the only way for it to be useful as an analysis of what people use and what they don't. I don't think it's required or usual to have to re-opt-in every time we decide to change which checkbox clicks in a dialog are tracked for example, but if that makes you uncomfortable then you probably want to opt out.