Skip to end of metadata
Go to start of metadata

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


  1. 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.


  2. Anonymous

    Very good description of what is send. This should be an example of how to explain what gets send in your Analytics data.

    You now receive metrics from me (smile)

  3. 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!

    Keep up the great work guys!

  4. Anonymous

    They'll never, never, never collect anything about me. 

  5. 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.

  6. I like the honesty and the ability to choose. I will be choosing yes to this to help the project! Besides, I always like to look at analytics of my stuff too!

  7. 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?" (big grin). Not trying to be a prick, just curious about the answers to these questions...

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

      1. "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.
      2. "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.
      3. "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.
    2. Hey Ernesto,

      To answer your questions:

      1. The collection of data is placed on a low priority background thread, so you shouldn't notice any performance drop in SourceTree at all.
      2. 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.
      3. 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)

      Hope that helps



      Now, that is outstanding.

  8. 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.

    Cheers, Don


    1. 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.

      1. Anonymous

        Thanks for the quick response! I will pass on the opt-in for now.

  9. Anonymous

    I've gone in and enabled it simply because, as the others have said, the transparency here is stellar.

  10. Steve Streeting [Atlassian] what tools are you using to gather analytics ? I am interested in doing something like this in our software. I am interested on windows platform. Thanks

    1. Hi mihai,

      I was the developer on analytics for SourceTree.

      We developed a completely custom solution on the client-side. The server-side is Atlassian's pre-existing analytics systems.

      If you need more specific information I'm sure I can help out.


  11. Hi guys,

    this is an impressive experience of clearness.

    I liked both what I read here and how transparent the data is.

    That can be a showcase for other companies to do it right.


    cheers - Chris