(resending to analytics@) tl;dr I am hoping the setup for wikipage view counts (based on Varnish UDP logging) could be reused for thumbnails, and I am asking for advice on that. Hi all, while the tracking of user behavior on Wikimedia sites is generally in a sad state, there is a decent-enough external tool [1] for telling which Wikipedia articles are popular and how that popularity changes day-to-day. The same is not true for images, for which there are no public view statistics at all. As a poor but still-better-than-nothing tool, people have been looking and file description page view counts to get an estimate of the level of interest in an image. This will be rendered mostly useless by MediaViewer (per our logs, only about 2% of readers follow through to the file page), which makes GLAM people sad. I am looking into alternative ways for supporting image curation with usage statistics. I can see four use cases here: 1. track how often an image is seen 2. track how many people are interested in an image 3. track how many people download/reuse an image 4. track how many people are interested in image metadata (e.g. GLAMs like to know not only how many people have seen the image, but also how many of them have seen which institution it comes from) I haven't yet collected much information on how much people actually want each of these; I would like to understand first which of them are realistically doable. I'll share my vague plans on how to implement them; I would appreciate if you could poke holes in them / suggest better solutions. == Tracking image view counts (including thumbnails) == This seems largely analogous to how page view counts are tracked: in one case we need to know Varnish html hit counts, in the other Varnish image hit counts. For the page view counts, according to [2] Varnishes send an UDP packet to a statistics server whenever a page is requested; the results are aggregated in hourly buckets, published at [2], then further aggregated into daily buckets, put into an SQL database and visualised on a 3rd party server. This seems to be easily replicable for thumbnails / image originals: deduplicate by file name (and possibly some sort of thumbnail size buckets), save in dump files, ask Henrik to include them in stats.grok.se(it would be probably easy to hack them into the current system if they get fake wikidb names). It would be even more reliable than page view counts because image redirects work differently from article redirects, and don't split the view counts forever. The big drawback is caching: while HTML pages are not cached (in the sense that the browser always sends a request for them), most images are [3]. I don't think this could be realistically helped (in theory it could be possible to calculate from the page view stats and the imagelinks table the exact number of times an image has been displayed, but doing that on the scale of Wikipedia pageviews is not plausible), and it might even be considered a good thing: instead of view counts, we get a reasonable approximation of unique visitors (image viewers). == Tracking people "expressing interest" in a file (whatever that means) == Knowing how many people see the thumbnail of a file is important, but - unlike article view counts - it does not really say how many people show any interest in an image. It might just happen to be included in an article they are interested in; maybe they never scrolled to the bottom of the article and haven't seen the actual image at all. So it is useful to know how many people clicked through the image. Without MediaViewer, file page view counts can (and are) used for this (even if they have their own problems for Commons images); with MediaViewer there would have to be a way to tell apart a thumbnail that was requested for use in MediaViewer vs. for some other reason. This could be done similarly to how the ?download query parameters are handled: append a source=mediaviewer URL parameter to the filename, have Varnish rewrite it to avoid cache splitting, add the parameter to the UDP packet and filter on it when processing the logs. This would be a fairly generic mechanism which could be potentially used for other things (source=filepage, source=hovercards etc); it would still split the cache on the browser side, but given that the large thumbnails used by MediaViewer don't overlap much with the thumbnail sizes used on wiki pages, this does not seem tragic. == Tracking the number of downloads/reuses == MediaViewer adds a ?download parameter to download links (to ensure that the Content-Disposition header is set), which could be used to track downloads. (It would miss downloads from other sources; I'm not sure there is a generic solution. Maybe something based on referrer or some other header, in case the browsers set those differently for downloaded and displayed images?) Reuse is too vague a category to say anything about, but tracking views of an image which originate outside the Wikimedia universe seems possible, but too much effort and too different from the previous methods to be worth spending time on now. == Tracking the interest in image metadata == MediaViewer collects global statistics on the ratio of people viewing an image vs. following through to the file page vs. scrolling down to open the panel with file metadata information. I don't think a per-file tracking of this would be useful or worth the effort; if it is needed, it would have to be done by some EventLogging-ish setup with MediaViewer creating tracking gifs whenever the metadata information is opened. What do you think, is any of this plausible? [1] http://stats.grok.se/ [2] http://dumps.wikimedia.org/other/pagecounts-raw/ [3] looking at the effects of a page load in the network tab, it seems that most thumbnails on a page are loaded from the browser cache, while there are a few which are requested from the servers which respond with a 304. Which images do that is deterministic but otherwise seems totally random; e.g. on the current enwiki mainpage, RalphBakshiJan09.jpg is loaded from cache while Prayuth_Jan-ocha_2010-06-17_ITN.jpg is always requested. I am curious about the reason for this.