I don't think it'll make much of a difference if you're only showing numbers
for the most recent version. The new version will show tens of thousands of
downloads on the first day - but the same user isn't downloading it more
than once.
If you want to see *only* (for example) "people who did their initial
install on version X", take the number of downloads for version X and
subtract the number of downloads for version (X - 1) - that will get you
close. You'd have to account for the number of people who uninstalled after
(X - 1) but before X, not to mention people who simply haven't updated yet,
in order to get the number exact. But not taking those into account will
get you, IMO, "close enough".
If you just want to see the total number of current users (which I think is
the whole point of this), the number of downloads for the most recent
version would be pretty close - again, to get it to an exact number you'd
have to worry about some edge cases, but I'd say this gets you "close
enough" :)
I apologize if I'm just not articulating this properly. Communication
hasn't always been my strongest suit.
On Sun, Feb 13, 2011 at 8:33 PM, Cory Fields <[email protected]> wrote:
> On Sun, Feb 13, 2011 at 8:18 PM, Mike Cronce <[email protected]>
> wrote:
> > I don't know if all the necessary code to do it would already be in place
> or
> > not, but one way to count "total number of users" with a plugin would be
> to
> > include a unique identifier for the XBMC system that's running the
> > download. MAC address for the active network interface would be an easy
> way
> > to do it.
> >
> > Alternatively, since you're already sending the version number (as part
> of
> > the file name), another option would be to only count the number of
> > downloads of the most recent file. Maybe even take it a step further if
> you
> > can find space in the GUI somewhere, a cool statistic would be a line
> graph
> > with number of downloads on the Y axis and version number (or release
> date)
> > on the X axis. Sort of lets you see how the plugin has grown.
> >
> > On Sun, Feb 13, 2011 at 7:54 PM, Jonathan Marshall <[email protected]>
> > wrote:
> >>
> >> Hi All,
> >>
> >> First off, let me thank you all for the great effort with all your
> >> addons. The addons are what makes XBMC so great - keep it up!
> >>
> >> We'll be introducing download statistics within XBMC for addons in Eden,
> >> and to do this we've got some nice statistics-collecting stuff care of
> >> TheUni's work with google analytics.
> >>
> >> First off, I want to assure you that no user-data is collected in order
> to
> >> generate these stats. Basically what happens is we receive a download
> >> request on our server, and then apache then requests a .gif
> (server-side)
> >> from google analytics. Thus, the only info google sees is that the
> xbmc.org
> >> server is downloading a particular .gif. The location of the .gif tells
> >> google what the download was (eg "script.xbmc.subtitles-v1.0.7.zip") and
> the
> >> referrer string tells analytics whether this is an update or fresh
> install
> >> (we know this as XBMC sets this info in the referer URL - or at least it
> >> will do in Dharma 10.1 as we forgot to backport it!). In addition, the
> >> user-agent string tells us XBMC version and OS version.
> >>
> >> We're working on adding the downloads info into the UI at the moment,
> and
> >> we're wondering what makes the most sense to include. My thinking is
> that
> >> we want:
> >>
> >> 1. The total downloads.
> >> 2. Some measure of "install base" or "popularity".
> >>
> >> Number 1 is obvious. Number 2 is not so obvious. Reason is that addons
> >> that have had a lot of updates will obviously have a lot of downloads,
> as
> >> those users will ofcourse be receiving the updates. Thus, total
> downloads
> >> itself isn't really good measure of install base. If we only use
> "fresh"
> >> installs (i.e. ignore all updates), however, then those addons that are
> >> included with XBMC (recentlyadded, confluence etc.) will essentially be
> zero
> >> as you can't "fresh" install it (you already have it). Another measure
> >> might be total_downloads/number_of_updates. Assuming updates are far
> enough
> >> about that most users will get each update, then we can assume each user
> >> receives the same number of updates and we have a reasonable number.
> >> Ofcourse, any user that doesn't have auto-updates on, and instead just
> >> checks every month or two screws that one up. An alternate is maybe
> just
> >> listing some sort of fuzzy "frequency of update" thing (eg "Updated:
> >> Regularly") and let the user take that into account.
> >>
> >> We can also use this to order by number of downloads, or order by
> >> "popularity", so whatever statistic we use it needs to be reasonably
> fair
> >> (equally biased for the statisticians).
> >>
> >> So, is this sane? Do you think a different measure is needed? Do you
> not
> >> care?
> >>
> >> PS: If you're interested in your downloads to date (regardless of
> whether
> >> they include updates or not) I'll send through a post in a bit with
> those
> >> totals.
> >>
> >> Cheers,
> >> Jonathan
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio
> XE:
> >> Pinpoint memory and threading errors before they happen.
> >> Find and fix more than 250 security defects in the development cycle.
> >> Locate bottlenecks in serial and parallel code that limit performance.
> >> http://p.sf.net/sfu/intel-dev2devfeb
> >> _______________________________________________
> >> Xbmc-addons mailing list
> >> [email protected]
> >> https://lists.sourceforge.net/lists/listinfo/xbmc-addons
> >>
> >
> >
> >
> ------------------------------------------------------------------------------
> > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> > Pinpoint memory and threading errors before they happen.
> > Find and fix more than 250 security defects in the development cycle.
> > Locate bottlenecks in serial and parallel code that limit performance.
> > http://p.sf.net/sfu/intel-dev2devfeb
> > _______________________________________________
> > Xbmc-addons mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/xbmc-addons
> >
> >
>
> I don't think we're interested in doing any per-user tracking (that
> always sets off red flags with users).
>
> We can indeed generate numbers based on versions. That still doesn't
> address the main problem though. The day an addon is bumped, that new
> version will get tens of thousands of downloads automatically
> (auto-updates are on by default). The question is, do we need to show
> "fresh" installs as well as updates in the GUI, and if so, how?
>
> Cory
>
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Xbmc-addons mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/xbmc-addons
