Additional context to download stats

Topics: General
Mar 13, 2013 at 9:05 PM
It is understood that the below represents a large unit of work. In the end, if it's decided this functionality is desirable, it is accepted that it will likely be broken up into sub issues. The reason for creating a single issue at this time, is so a discussion can occur, taking the larger picture into account.

Package Statistics

As a package owner, I want to be able to access the detailed download stats of my package to determine:
  • the difference between install vs update vs restore
  • the difference between direct downloads vs dependent downloads vs automatic downloads (i.e. the latter being automatic because VS template had it included out of the box)
  • the difference agents and versions that are downloading my package (i.e. VS - 20120, 2012 vs TeamCity - 7.1, 7.0 vs etc)
  • where in the world my package is being downloaded from
and in an ideal world, but understand that its probably not possible,
  • The number of unique downloads (per machine vs per project)
This will allow me to better answer questions I have around:
  • why particular legacy version of my application are being downloaded,
  • how many "true" users my package has,
  • how many of my downloads are caused by CI servers and which ones
  • how much support should I be anticipating that I need to legacy versions
  • am I "marketing" new release announcements correctly
Note, eventually, as a package owner, I want to be able to break this data down by day/week/month since the project was created (think google analytics date filtering).

Powershell Integration

As a package owner, I want to be able to gain access to some of this information from within powershell to facilitate having logic run:
  • differently between install vs update vs restore
  • differently between direct downloads vs dependent downloads vs automatic downloads
  • differently when we know the other packages that were a part of the command "transaction"
  • differently between cultures
and in an ideal world, but understand that its might not possible,
  • the other packages the user currently has involved (without having to manually read the packages.config)
This will allow me to better tailor custom actions to do things like the following:
  • when an install is done, I would show a the full instruction doc of how to get up and running vs when an update is done, we assume they know how things run already and hence show the relevant release notes vs a restore we do nothing
  • since we have access to the other packages in the command "transaction" or that is currently installed, providing custom actions or information based on this knowledge

Powershell Events

As a package owner, I would like to be able to tap into an event that runs at the beginning and end of a command transaction.

This will allow me to run the aforementioned logic at the correct time.
Mar 15, 2013 at 1:04 AM
My view:

People use package download count as a way of gauging popularity of a package. Including automatic downloads in this number distorts it, making it less useful as a way to gauge actual popularity of a package.