Talk:Pageviews Analysis/Archives/2016/3

Latest comment: 7 years ago by MusikAnimal (WMF) in topic Begin at zero

ordinate not beginning with zero

Hello there, I just wonder why the numbers on the vertical axis don't start at zero but cut off low numbers instead. That overemphasizes differences between daily pageviews, which is quite unusual in statistics.--Rody5505 (talk) 08:47, 1 July 2016 (UTC)

The lower numbers are only cut off if there's no data in that range. For instance, if the pageviews counts range from around 6,500 to 9,000 (example), including the blank space from 0 to 6,000 will take up much precious real estate on the chart, and consequently make the other differences harder to visualize. I'm not sure if this is contrary to conventions, but we want to prioritize visualizing fluctuations in data while still being accurate, which I think is what is being done. We could consider an option to always start the y-axis at zero, if you think that would help? I fear we'll get more complaints than compliments if this option were defaulted on MusikAnimal (WMF) (talk) 16:49, 1 July 2016 (UTC)
Obviously one can find arguments for both versions, the version with axis crossing at zero and the current version . If asked, I'd prefer a checkbox allowing me to choose between these versions. I'd put that feature on my wish list for the years ahead. Anyway, thanks for your great work here.--Rody5505 (talk) 18:22, 1 July 2016 (UTC)
Issue created at https://github.com/MusikAnimal/pageviews/issues/132. This should be fairly easy to implement, so expect a release soon! :) MusikAnimal (WMF) (talk) 19:55, 1 July 2016 (UTC)
@Rody5505: Another user contacted me about this. They were trying to compare the pageviews of two articles, but were doing so using two different tabs. Obviously that caused problems because each chart started at a different point. Is the same concern you had? In case it was, just know you can compare pageviews on the same chart: simply type in additional page names in the "Pages" input field. If you have any recommendations on how to make this more apparent, it's certainly appreciated :) MusikAnimal (WMF) (talk) 18:57, 2 July 2016 (UTC)
Comparing two articles wasn't my initial point since I didn't even know that possibility. I only learned it from your example right here and I appreciate it very much. In order to inform new users, I'd prefer a tooltip for the "Pages" input field.--Rody5505 (talk) 19:56, 2 July 2016 (UTC)
@Rody5505: The "Begin at zero" option has been deployed. Let me know if there's anything else we can do to improve tool for you. Best MusikAnimal (WMF) (talk) 03:01, 5 July 2016 (UTC)

Bug report

URL: [1]
User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0
Error message: Operation timed out
— The preceding unsigned comment was added by 212.0.102.74 (talk)

I tried out the above URL and had no issues using Firefox 47 on Windows 7. It's possible you're using a slower internet connection or the servers were being slow, in which case a timeout is expected. Please refresh the page and see if it works. If it still isn't working, I might have some more detailed instructions to give you so that we can figure out what's going wrong. MusikAnimal (WMF) (talk) 16:18, 5 July 2016 (UTC)

Radar chart not working

URL: [2]
User agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0
Error message: TypeError: e.scales.yAxes is undefined

The above error is displayed when trying to render a radar chart on Firefox. Gts-tg (talk) 13:57, 5 July 2016 (UTC)

Confirmed. Working on a fix! MusikAnimal (WMF) (talk) 14:57, 5 July 2016 (UTC)
@Gts-tg: This should be   Fixed. Thanks for the report! Note also the radar chart isn't going to look so great for wide date ranges MusikAnimal (WMF) (talk) 16:14, 5 July 2016 (UTC)

Redirects

Tracked in Phabricator:
Task T121912

Is it feasible for Pageviews Analysis to take account of redirects? For some articles it can make a lot of difference.--Penbat (talk) 12:26, 10 July 2016 (UTC)

@Penbat: This has been scoped out before ([3][4]) and we decided it was too expensive to do. Sorry! Ultimately we're hoping the pageviews API itself will handle redirects, see phab:T121912.
In the meantime, you can still manually include redirects to a page. In "Settings" choose "Autocompletion including redirects" so that the search will show the redirects. Alternatively you could manually type them into the URL. Hope this helps MusikAnimal (WMF) (talk) 12:24, 11 July 2016 (UTC)
Thanks. I do not understand what "Autocompletion including redirects" is. Autocompleting what ? It didn't seem to make any difference when I tried it.--Penbat (talk) 18:12, 11 July 2016 (UTC)
@Penbat: Sorry, what I am referring to is the autocompletion when searching for an article. E.g. normally if you type "Barak Obama" the search suggestions show the correct spelling "Barack Obama". If you have your search set to "autocompletion including redirects" you will be able to select the redirect "Barak Obama". This will allow you to add up to 9 redirects in addition to the main article and see the totals. You aren't trying to see the redirects as a result of a page move, are you? I ask because we have considered implementing a workaround for that ([5]) MusikAnimal (WMF) (talk) 03:01, 12 July 2016 (UTC)

Localize date format

When I tick this box I do indeed get a different date format but not mine which is dd/mm/yy and I am always misreading what is currently displayed. I realise this is very much a refinement and everything now seems to work so well I don't like to whinge but there it is. Thanks, Eddaido (talk) 02:04, 12 July 2016 (UTC)

@Eddaido: This must either be a misconfiguration on your or our end, and we can easily fix it either way. Could you browse to this very simple script and tell me what language code you see in the alert box? MusikAnimal (WMF) (talk) 02:52, 12 July 2016 (UTC)
en-us. I use a mac, Safari and OS 10.11.5 and up top right of the screen it shows I am in Australia (which is the nearest Mac can get to New Zealand but don't you worry about that!) Many thanks for your interest, Eddaido (talk) 04:32, 12 July 2016 (UTC)
@Eddaido: Pageviews Analysis goes by your computer settings, which you evidently have set to American English. This may be a different setting than your location, which as you say is correct. In "System Preferences" > "Language and Region", change your preferred language to "Australian English". Some browsers have their own language settings, but I believe Safari will go by the system. Let me know if this works for you. Best! MusikAnimal (WMF) (talk) 20:14, 12 July 2016 (UTC)
Done! Thank you very much indeed. It was set to something call English (no further description!) which I suppose means to Apple US English. With kind regards, Eddaido (talk) 22:48, 12 July 2016 (UTC)

Setting options

"Format numerical data" and "Localize date format" probably don't mean much to most people. Maybe we should make these labels more detailed or provide some examples. Kaldari (talk) 20:39, 12 July 2016 (UTC)

I had given thought to organize the settings with a "Localization" and "Chart options" sections, which may aesthetically allow for more detailed explanation of what the settings do. I will play around with the idea! MusikAnimal (WMF) (talk) 02:24, 13 July 2016 (UTC)

Error: TypeError: c is undefined

Expand to see reports of the same error

Extended content

13 July 2016

URL: [6]
User agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0
Error message: TypeError: c is undefined
Carlos Luis Cruz (talk) 18:50, 12 July 2016 (UTC)

URL: [7]
User agent: Mozilla/5.0 (Windows NT 10.0; rv:47.0) Gecko/20100101 Firefox/47.0
Error message: TypeError: c is undefined
Fugiel (talk) 00:49, 13 July 2016 (UTC)

I am not able to reliably reproduce this, but I did see it using the link above using Firefox 47 on Windows 10. I think it's either a timing conflict or related to caching, as the steps I took to initially reproduce did not work on subsequent tries MusikAnimal (WMF) (talk) 00:51, 13 July 2016 (UTC)
Hopefully   Fixed with 63d93a0 MusikAnimal (WMF) (talk) 20:30, 14 July 2016 (UTC)

outreach.wikipedia.org is not a valid project

I tried to get pageviews for Outreach which is a valid project according to this. Is there any plan to add more projects to the current list of supported projects? Thanks, --Jane023 (talk) 15:27, 13 July 2016 (UTC)

@Jane023: I'm going to update that error to say "...or is currently unsupported", which is the case here. Adding Outreach and other unsupported WMF wikis is on the Analytics team road map, but I can't give any projected dates. See phab:T130249 for more info. Sorry! MusikAnimal (WMF) (talk) 00:39, 14 July 2016 (UTC)
Well I suspected as much and I think it would be useful to put a list somewhere of the supported projects with a talk page where people can vote on their wishlist. --Jane023 (talk) 06:45, 14 July 2016 (UTC)

JavaScript error when trying to compare page views

URL: [8]
User agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0
Error message: TypeError: c is undefined
I got the above error when trying to compare the page views for en:Brendan E. Hunt and en:Brendan Hunt (actor, activist). – nyuszika7h (talk) 13:08, 14 July 2016 (UTC)

  Confirmed and hopefully   Fixed! I believe this issue is the same as the other unresolved error reports above, only this example was reproducible because there is no data on either article you entered. Now, you're probably wondering why there's no data. en:Brendan E. Hunt was created only today, but the data unfortunately takes a full 24 hours to populate. For en:Brendan Hunt (actor, activist), the page was just moved, and so we suffer from the same problem. You'll have check views of en:Brendan Hunt to see that data, until we come up with a solution to query for page moves (see issue #26). So basically the bad news is we can't give you the data right now in the way you requested it, but the good news is you helped solve a long-time issue that I've been fighting to diagnose. So thank you!!! :D MusikAnimal (WMF) (talk) 20:29, 14 July 2016 (UTC)

GHeissläuferortung

Ihr Beitrag ist kümmerlich. Sehen Sie bei "VOEST ALPINE" unter Heissläuferortung nach. Schliesslich sind 4 internatonale Patente verarbeitet und solche teuren Systeme auf der ganzen Welt bei Eisenbahnen ein gesetzt.

Schauen Sie unter Patents : Titel und mein Name . Jens Duehrkoop ( Hamburg, Heidelberg,Muenchen).

Komplizierter geht es wohl nicht....... — The preceding unsigned comment was added by Jensduehrkoop (talk)

Es tut mir leid, dass Sie an der falschen Stelle sein. Dieses Forum ist für die Diskussion über Pageviews Analysis. English: I'm sorry you may be in the wrong place. This forum is for the discussion of the Pageviews Analysis tool. MusikAnimal (WMF) (talk) 20:00, 14 July 2016 (UTC)

Timeout

URL: [9]
User agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36
Error message: Operation timed out

49.145.20.151 12:38, 16 July 2016 (UTC)

Please try the link again and it should work for you. I'll increase the timeout threshold even more, as it appears some users are running on an especially slow connections, or the server is for some reason being that slow MusikAnimal (WMF) (talk) 16:28, 17 July 2016 (UTC)

TypeError: c is undefined

URL: [10]
User agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0
Error message: TypeError: c is undefined

Larske (talk) 13:27, 16 July 2016 (UTC)

@Larske: Is the link working for you now? This shouldn't be happening anymore, unless it's an unrelated bug. I'm hoping you hadn't used Pageviews Analysis since we made the update (14 July 2016), so it's possible your browser returned the old code. At any rate, I'm going to introduce automated error reporting so I can have more information to diagnose these issues MusikAnimal (WMF) (talk) 16:25, 17 July 2016 (UTC)

Statistics for some articles are missing for yesterday, but only for date range setting of "last 20 days"

There is a problem with displaying statistics for some articles for "yesterday" if the date range is exactly 20 days. For other date ranges yesterdays data is displayed for all articles.

Here are some examples showing this:

  • This (10 days range) shows results for the last date 2016-07-15, i.e. the bars are shown for 2016-07-15

https://tools.wmflabs.org/pageviews/?project=sv.wikipedia.org&platform=all-access&agent=user&range=latest-10&pages=Undantagstillst%C3%A5nd%7CTurkiet%7CVisby

  • Also this (30 days range) shows results for the last date 2016-07-15, i.e. the bars are shown for 2016-07-15

https://tools.wmflabs.org/pageviews/?project=sv.wikipedia.org&platform=all-access&agent=user&range=latest-30&pages=Undantagstillst%C3%A5nd%7CTurkiet%7CVisby

  • But this (20 days range) does only show results for one of the three articles (Visby) for the last date 2016-07-15. The bars for the other two articles are not shown.

https://tools.wmflabs.org/pageviews/?project=sv.wikipedia.org&platform=all-access&agent=user&range=latest-20&pages=Undantagstillst%C3%A5nd%7CTurkiet%7CVisby

  • Same problem if the same date range of 20 days is stated manually

https://tools.wmflabs.org/pageviews/?project=sv.wikipedia.org&platform=all-access&agent=user&start=2016-06-26&end=2016-07-15&pages=Undantagstillst%C3%A5nd%7CTurkiet%7CVisby

  • 21 days works fine:

https://tools.wmflabs.org/pageviews/?project=sv.wikipedia.org&platform=all-access&agent=user&start=2016-06-25&end=2016-07-15&pages=Undantagstillst%C3%A5nd%7CTurkiet%7CVisby

  • and so does 19 days:

https://tools.wmflabs.org/pageviews/?project=sv.wikipedia.org&platform=all-access&agent=user&start=2016-06-27&end=2016-07-15&pages=Undantagstillst%C3%A5nd%7CTurkiet%7CVisby

--Larske (talk) 14:09, 16 July 2016 (UTC)

@Larske: I'm almost certain this is a result of normal caching on the server-side. I assume the first time you loaded the data you were in the default latest 20 days range (or maybe someone else did), so the server cached that result. Using different date ranges means a new "endpoint" on the API, so a fresh result is returned. Apparently by then data became available for yesterday. This anomaly is unfortunately unavoidable, but the data that is missing in the 20 day range will eventually show up. Are you seeing all of the data now? This issue is reported a lot, so I will update the FAQ to explain it MusikAnimal (WMF) (talk) 16:22, 17 July 2016 (UTC)

Error: Cannot read property '_meta' of undefined

Expand to see reports of the same error

Extended content

9 July 2016

URL: [11]
User agent: Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36
Error message: TypeError: Cannot read property '_meta' of undefined
— The preceding unsigned comment was added by Terraflorin (talk)

@Terraflorin: Could you elaborate more on what happened? I tried out the link using Chrome 51 on Windows 10 and the page loaded for me MusikAnimal (WMF) (talk) 14:31, 9 July 2016 (UTC)

11 July 2016

URL: [12]
User agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36
Error message: TypeError: Cannot read property '_meta' of undefined

MoSchle (talk) 03:38, 11 July 2016 (UTC)

@MoSchle: Could you explained what happened? Did you simply click on the "Abrufstatistik" link on de:Bixnaaf, or did you type in the article manually? Antworten auf Deutsch, wenn die Ihre bevorzugte Sprache ist MusikAnimal (WMF) (talk) 12:19, 11 July 2016 (UTC)
Danke fürs Nachfragen. Ich habe einfach auf Abrufstatistik geklickt. MoSchle (talk) 14:10, 11 July 2016 (UTC)
@MoSchle: Ich kann das Problem nicht reproduzieren. Haben Sie dieses Problem? Englisch: Are you still having this problem, or did it only break one time? Sorry I don't speak German, I just wanted you to be able to still be able to respond in case you don't speak English. Danke MusikAnimal (WMF) (talk) 15:55, 11 July 2016 (UTC)
I often use this tool, but this failure I saw only once. MoSchle (talk) 17:10, 11 July 2016 (UTC)

11 July 2016

URL: [13]
User agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36
Error message: TypeError: Cannot read property '_meta' of undefined
ישראל משה (talk) 14:27, 11 July 2016 (UTC)

12 July 2016

URL: [14]
User agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36
Error message: TypeError: Cannot read property '_meta' of undefined

Matijak (talk) 19:46, 12 July 2016 (UTC)

URL: [15]
User agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36
Error message: TypeError: Cannot read property '_meta' of undefined

5.170.195.150 09:25, 12 July 2016 (UTC)

URL: [16]
User agent: Mozilla/5.0 (Linux; Android 5.0; SM-G900H Build/LRX21T) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.89 Mobile Safari/537.36
Error message: TypeError: Cannot read property '_meta' of undefined

AzorAhai (talk) 18:08, 12 July 2016 (UTC)

13 June

URL: [17]
User agent: Mozilla/5.0 (X11; CrOS x86_64 8172.56.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36
Error message: TypeError: Cannot read property '_meta' of undefined

I had selected "All" instead of "Users" and pressed "start at 0". It dispayed 11 642 hits per day. Then I press "90 day" and got this.

Josve05a (talk) 11:20, 13 July 2016 (UTC)

18 June

URL: [18]
User agent: Mozilla/5.0 (Linux; Android 5.0; SM-G900H Build/LRX21T) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.89 Mobile Safari/537.36
Error message: TypeError: Cannot read property '_meta' of undefined

AzorAhai (talk) 09:15, 18 July 2016 (UTC)

Hopefully   Fixed with 63d93a0 MusikAnimal (WMF) (talk) 20:30, 14 July 2016 (UTC)

Smaller-than-unit increments are unnecessary

Tracked in Phabricator:
Task T140784 resolved

For low pageviews, the tool's graph shows increments smaller than the unit on the Y-axis (cf. an example here). There is no need to (since there are never e.g. 0.2 pageviews), and therefor I would propose a developer to simplify the possible Y-values (limited to positive natural numbers). (Verheyen Vincent (talk) 22:50, 18 July 2016 (UTC))

The Chart.js library has one way of getting around this, but it is not ideal. I'm going to try to find a solid workaround. Thanks for the fine suggestion! MusikAnimal (WMF) (talk) 00:03, 19 July 2016 (UTC)
@Verheyen Vincent: Should be   Done :) Thanks again MusikAnimal (WMF) (talk) 01:13, 21 July 2016 (UTC)
@MusikAnimal: Amazing. You are the one to be thanked. A very rapid and perfect (as far as I can currently notice) solution was provided. If you would happen to be able to elaborate a little bit more on the procedures taken to solve this problem (or provide some links about that), I would be much interested. (Verheyen Vincent (talk) 02:00, 21 July 2016 (UTC)).
Heh, not a whole lot involved. Chart.js has a callback function so you can tweak the numbers on the left side ([19]), and turns out you can just return null and it won't show a horizontal line (or "tick" as they call it) at all [20]. Here we just return the value if the modulo of it and 1 is zero. This "null return" approach is undocumented but I don't expect to undergo another Chart.js upgrade, so it should be stable MusikAnimal (WMF) (talk) 02:23, 21 July 2016 (UTC)

Option to always hide logarithmic scale

Tracked in Phabricator:
Task T140783 resolved

Would it be possible to add a URL parameter to prohibit the scale becoming logarithmic? I often use page views to show impact to people from partner GLAM organizations and because the logarithmic scale "hides" peaks, it is now more difficult for me to clearly demonstrate to those people the attention that is being paid to their topic on Wikipedia at peak times. People who are new to our charts may easily disregard the scale or have no idea of logarithmic scales at all. To make an impression, a peak has to clearly outmeasure regular traffic. --Blahma (talk) 07:51, 19 July 2016 (UTC)

@Blahma: Oh I see, so you are sharing the link with these people. In that case yes, a URL param of sorts seems could be added. However, the automatic showing of the log scale is for the exact purpose of not giving too much weight to the spikes in traffic, as otherwise it's difficult to make out differences in the smaller numbers. The Y-axis should still show accurate numbers, but I know what you mean that in your use case you want there to be a visible spike. For your own computer, you can uncheck "Automatically use logarithmic scale if applicable" in the Settings. I will create a ticket to add the URL parameter as requested, not a bad idea :) MusikAnimal (WMF) (talk) 16:05, 19 July 2016 (UTC)
@Blahma: I've deployed a patch making this functionality possible. Just append &autolog=false to the URL, see this example. This parameter is retained when the application loads, so that if the link is shared it will continue to use the normal scale. Hope this works for you! Thanks for the recommendation :) MusikAnimal (WMF) (talk) 01:19, 21 July 2016 (UTC)

Logarithmic scale issue

I noticed something odd about the logarithmic scale display, which is an option for the Pageviews Tool with line charts. In the settings, logarithmic scale can be chosen every time, or whenever the Pageviews Analysis Tool considers it to be appropriate. I am seeing examples where the tool chooses logarithmic scale even when it is not appropriate. Specifically, whenever there are zero pageviews in a day, the logarithmic chart displays no value at all for that day. I understand why that happens, because log(1) = 0 for one page view, but log(0) is undefined for zero pageviews. When that is the case, with zero page views during the time interval queried, shouldn't the y-axis display base 10 numbers only? Here is an example line chart with many missing values because they are zero. It is for the most recent 30 days of pageviews for that Wikipedia page.

I don't know what your criteria for determining when logarithmic scaling is appropriate, although I am curious! Here's why I mention that. The logarithmic scale (with missing data points) displays for the most recent 20 days, 30 days and 60 days. However, it does not default to logarithmic scale for 10 days or 90 days, thus both those views have proper representation of all data, including days with zero pageviews. I don't see any obvious reason why the 20-, 30- or 60-day chart should default to logarithmic scale, versus 10- or 90-day views, given the data.

I am using Google Chrome browser version 51.0.2704.103 running Windows 7.--FeralOink (talk) 01:14, 19 July 2016 (UTC)

@FeralOink: All valid concerns! If it were a true logarithmic chart, you are correct that it would show only powers of 10 (if that's what you mean). However some articles have say, 150 pageviews at the maximum across the date range, so the y-axis would show 1, 10, 100 and 1000. The space between 100 and 1000 is significant, and the lack of a numerical horizontal guide makes it hard to see what the values are at a glance. Hopefully that makes sense. You are also correct that 0 isn't shown because log(0) is undefined (or negative infinity according to JavaScript!). I still want to find a way to make the chart start at zero and actually show zero for those values, which essentially will involve a hack of the Chart.js library we're using.
Finally, Pageviews Analysis uses the Theil index to determine when a log scale is appropriate. The algorithm, if you will, can be found here. We currently have the threshold set to 0.5, which seems to be a happy medium. There will always be a few edge cases where it doesn't seem to make sense, which I think is the case with your examples, as they all scored just over or below 0.5 MusikAnimal (WMF) (talk) 01:35, 19 July 2016 (UTC)
Tracked in Phabricator:
Task T140910 resolved
Possibly related, but it defaults to a logarithmic scale when the values are in the range 0-3 - which is not helpful as it's not possible to easily distinguish lower than maximum values from zero on such a chart (see [21] for example). This is probably most easily solved by never defaulting to a logarithmic chart when the maximum value is less than n (n=10 would be my initial suggestion). These sorts of values are quite common when dealing with redirects. Thryduulf (talk: meta · en.wp · wikidata) 11:04, 20 July 2016 (UTC)
This we can do. Tracked at task T140910. Thanks MusikAnimal (WMF) (talk) 15:56, 20 July 2016 (UTC)
@Thryduulf: This should be   Done :) I currently have the threshold set to 10 as you recommended MusikAnimal (WMF) (talk) 01:12, 21 July 2016 (UTC)
Thank you. I haven't done much experimentation so the figure of 10 may need to be adjusted, but it's a good starting point based on the limited research I have done. If it is simple (I haven't the slightest clue), you might want to allow the threshold to be set as a preference, but it's probably not worth going to great lengths to add. Thryduulf (talk: meta · en.wp · wikidata) 23:09, 21 July 2016 (UTC)

Pageviews bug report

The Analysis of pageviews doesn't work.

--В.Галушко (talk) 13:45, 21 July 2016 (UTC)

@В.Галушко: Could you please provide more information? Does toollabs:pageviews not work at all or is it just for a certain link? What browser (Chrome 50, Firefox 42, etc.) are you using, and operating system (MacOS, Windows 7, etc)? Thanks MusikAnimal (WMF) (talk) 18:03, 21 July 2016 (UTC)
Thank you, it has worked out by itself. Don't worry.
--В.Галушко (talk) 12:48, 22 July 2016 (UTC)

Pageviews not showing up

Hello! I have an IE browser and a Windows 7 OS. Beginning July 1 and continuing through the present, whenever I access "Pageview statistics" I get a grid with a zero in the middle, a +1 at the top, and a -1 at the bottom!

For years I'd been getting bars showing pageviews for each day, and I liked that. Can you tell me how to return to the bar chart? (Please keep it simple, I am not at techie.) I have most frequently gone to the Mark Satin pageview statistics, but I have checked the stats for over a dozen other Wikipedia articles since July 1, and they all come back with the same weird +1 to -1 chart.

I'll check this page for your response. Thanks so much! - Wikipedia's Babel 41. - Babel41 (talk) 02:23, 22 July 2016 (UTC)

@Babel 41: This sounds bad and I want to figure this out. My first suspicion... what version of IE are you using? Only IE11+, Chrome, Firefox and Safari 8+ are supported. I tried it on IE9 and IE10 on Windows 7 and got the "please upgrade your browser" error which you should be seeing in you're using an older version. There was a major reworking of the app around June 30, so I do believe this is related to the code. You still bring up an interesting bug: if there are zero pageviews across the whole date range it should not should show negative values on the y-axis. This I can fix. Why you are seeing zero pageviews is the question, though! If you are using IE11, could you also try in Chrome or Firefox? MusikAnimal (WMF) (talk) 06:07, 22 July 2016 (UTC)
@Babel41: Looks like I pinged the wrong username. Would love to get this bug sorted out, hopefully it is not widespread! MusikAnimal (WMF) (talk) 23:30, 22 July 2016 (UTC):::
Thanks for all this info. I am afraid I am really a primitive Internet user (though I've done some successful edits on Wikipedia articles) and have no idea which version of IE is installed on my computer. It must be one of the earliest since it goes back to, I think, 1999. Fortunately, somebody installed a version of Google Chrome on my computer last year. I hardly ever use it (it's too overbearing for my taste), but I tried it today with my Windows 7 OS, and I did get the bar charts that I had not seen since before July 1. So you have solved my problem so far as I am concerned ... when I want to see the bar charts, I'll use Chrome. Thanks again for your help. Sincerely, Wikipedia's Babel41. - Babel41 (talk) 03:38, 23 July 2016 (UTC)
@Babel41: Glad to hear Chrome is working for you! However I would like to diagnose the issue with Internet Explorer, if that's okay with you. When you use Internet Explorer, do you see a red banner at the top that says "Internet Explorer 10 and below is not supported. Please update your browser"? MusikAnimal (WMF) (talk) 15:29, 25 July 2016 (UTC)
I am sorry I brought this problem to you. I feel obliged to answer your questions (since you helped me immeasurably above), but I am probably the person on Wikipedia who least understands or cares about computer issues. I wish I were back in the 1970s. That being said, I feel confident (OK, fairly confident) reporting that I have never seen the red banner you describe. I remember getting various notices & alerts when my Windows 6 was about to expire, but never for IE. But of course that doesn't make sense, since my IE (as I said above) goes back to 1999. To the best of my knowledge, IE had never hampered my work until the issue I brought up with you, the inaccessible bar charts. But I only use my computer as a word processor and for Internet access. I don't use Office, create charts, etc. Editing Wikipedia articles is my most complicated computer operation by far. Best, - Wikipedia's Babel41. - Babel41 (talk) 23:21, 26 July 2016 (UTC)

Autocompletion using redirects

Given this example:

The total doesn't change when "Autocompletion using redirects" is checked. However when manually adding the redirect "Death of Harambe" it shows an additional amount

Is there a way to get all redirects automatically included in a single stat? -- Green Cardamom (talk) 02:01, 26 July 2016 (UTC)

@Green Cardamom: The overlapping pageviews for "Death of Harambe" I'm going to assume is mostly from search engine caching, though when I checked just now I see that Google is showing the target "Killing of Harambe". The old title is also linked on a number of pages, so when those links are clicked a pageview is registered. There currently is no way to automatically include all redirects, as this could be very expensive to process. We do however have plans to query the move log of a page and include redirects created from that, see phab:T141332. Stay tuned! :) MusikAnimal (WMF) (talk) 02:42, 26 July 2016 (UTC)
No problem. I guess ultimately trying to answer "how many clicks arrived at the page" regardless of redirects which is what most are probably expecting. In Harambe's case I suspect a lot of external websites have the old name. Harambe (the corpse) has gone viral in the Australian Prime Minister elections for some reason as a write-in candidate. -- Green Cardamom (talk) 16:44, 26 July 2016 (UTC)
Agreed most are surely interested in how many landed on the target page, and not which redirects got them there. The Analytics team has is a ticket to add better redirect handling for the Pageviews API (which Pageviews Analysis uses), see phab:T121912. Best MusikAnimal (WMF) (talk) 17:54, 26 July 2016 (UTC)

OpenSearch

It would be nice if Pageviews Analysis specified a search engine using Opensearch. This means that users can easily specify a hotkey for using that "search engine" to show the pageviews of an article title. For example, I have manually (the point of opensearch is to make this less manual) created the search engine in my browser, and defined the hotkey "wpa", so by typing "wpa cat" in the address bar, I can see the pageviews analysis of the "cat" article. Wikipedia itself already specifies an opensearch search engine.

There is also a problem with encoding. Using my "wpa" browser search engine, "wpa map seed" will pass "map+seed" to Pageview Analysis. This will make Pageview Analysis look up "map+seed" literally (with the "+"). It would be helpful if Pageview Analysis would use the url argument format expected by browser search engines. Thue (talk) 13:03, 26 July 2016 (UTC)

@Thue: This is a fantastic idea! I think this is doable however I'm not sure how much work is involved. Additionally a "search suggestions" feature would probably not be feasible since it would have to go off of the Wikimedia API, when Pageviews Analysis is a purely clientside application. For your second concern, a + symbol is a valid title for pages, so we'd need to somehow encode it before search is performed. Happy to look more into this. Thanks MusikAnimal (WMF) (talk) 17:48, 26 July 2016 (UTC)
The tricky part would be in adding another search engine for each project the user searched on; I don't know how hard that should be. About the second point, isn't that just normal encoding? So space is encoded as "+", and "+" is encoded as "%2B", and all strings are therefore representable. Thue (talk) 21:55, 26 July 2016 (UTC)

Salute ! An excellent service indeed. Is there any possibility to get the list of the involved IP‘s in a specific day or in a range of several days as well ? Certainly in case only, when there is no celebrity in question. Is there somewhere also an accessible file with such content ? File with certain capacity, automatically saving the new and erasing the old data. Probably in very much the same way as the capture of my IP - now. But, wouldn‘t something like that be much to inquisitive ? Thanks in advance. JN

Pageviews bug report

https://tools.wmflabs.org/pageviews/?project=en.wikipedia.org&platform=all-access&agent=user&range=latest-20&pages=List_of_vetos_exercised_by_the_US_government_in_the_UN_Security_Council — The preceding unsigned comment was added by 2804:14c:5bb6:8956:fc5d:d7a1:6c2a:cd85 (talk)

The page is loading for me, and I don't see a recent automated report. Did you see an error message or did it time out? Try refreshing, it should work MusikAnimal (WMF) (talk) 22:14, 27 July 2016 (UTC)

Case sensitive?

Is the Pageviews Analysis tool case sensitive? Can it distinguish between Ba (pharaoh) and Ba (Pharaoh), even though the first is an article and the second is a redirect to the article? The question has been raised in this RFD. —Gorthian (talk) 18:56, 8 August 2016 (UTC)

Further investigation suggests this might be more of a UI issue than a stats issue - but the above question is still valid. It seems that it is not possible to view the stats for redirects from other capitalisations using the UI, e.g. en:Barak obama never appears in the drop-down list so it is possible to compare it with en:Barak Obama only by following a link to the former and then adding the second or directly editing the URI. When titles that differ only in capitalisation redirect to different targets (e.g. en:Nice and en:NICE), are different articles (e.g. en:MAVEN and en:Maven) or one is an article and the other a redirect elsewhere (e.g. en:DOS and en:Dos) both can be selected in the UI. Thryduulf (talk: meta · en.wp · wikidata) 20:42, 8 August 2016 (UTC)
Replied on enwiki. Your findings appear to be correct (I didn't even fully understand it :). That is, some redirects are searchable as you say due to differences in capitalization and whether they are a redirect, and what the target of the redirect is. This "cirrus completion suggester" is relatively new and is favourable by most, as we don't want you to end up seeing stats for "Barak Obama" when you really meant "Barack Obama", for instance. I can clarify this behaviour in the FAQ. Thanks MusikAnimal (WMF) (talk) 22:47, 8 August 2016 (UTC)

Seven day pattern

Currently the horizontal axis of the pageviews graph is divided in 40 ticks, if the number of days is larger than 40, resulting in a variable number of days per tick (variable = dependent of the chosen number of days). However, the pageview curve of many articles has a seven day pattern. (Examples: "physics" popular on schooldays, "church" popular on Sundays). Could the tick pattern be changed to major ticks and grid lines for Sundays, and minor ticks for other days? Ceinturion (talk) 12:06, 15 August 2016 (UTC)

@Ceinturion: If I understand correctly, you'd like to shift the date labels so that days with higher pageviews are shown? This is a fine idea, but a lot of work I think. Fortunately you can always hover over data points to get the date of that spike in traffic, and the exact number of pageviews. This works for the GUI, but I realize if you wanted to print the chart or export as a PNG it'd be preferred to have the date labels shown for the more important dates. I will look into it MusikAnimal (WMF) (talk) 16:22, 17 August 2016 (UTC)
What I meant was highlighting each Monday (first day the week) by a bold gridline. Ceinturion (talk) 21:53, 17 August 2016 (UTC)

Pageviews bug report

https://tools.wmflabs.org/pageviews/?project=de.wikipedia.org&platform=all-access&agent=all-agents&range=latest-90&pages=

@Capricho41: Könnten Sie die Schritte erklären Sie, dass zu dem Fehler geführt hat?
If you speak English: Could you explain the steps you took that lead to the error? The link works fine (shows no articles), and I don't see any recent automated error reports on my end MusikAnimal (WMF) (talk) 01:36, 18 August 2016 (UTC)

Pageviews referrers and search terms feature request

Some blog sites and similar services offer lists of the search terms that people use to arrive at a page. How feasible would that be to add to Pageviews Analysis? It would be really helpful to find how or why people are coming to pages. Larsnooden (talk) 17:29, 17 August 2016 (UTC)

Unfortunately referral information is not provided by the API. However you can see which redirects are the most popular with Redirect Views, which can help gauge how people end up at the article when searching within Wikipedia. I know that's not what you were looking for, but hopefully it helps if not a tiny bit :) I believe actual referral information (Google search terms, etc) is not recorded out of respect for privacy MusikAnimal (WMF) (talk) 01:44, 18 August 2016 (UTC)
Thanks. I've seen Redirect Views, but I was hoping for some sanitized referrer information (Google search terms, etc). The search terms are something, I think, that can be safely extracted from the referer {sic} request header. Since the terms would be stored and the other headers dropped, it could be done without violating the privacy of the visitors. I'm seeing occasional flurries of activities around specific book chapters and can't even guess why. Having even a little more information would help focus editing and maybe fill in some gaps in book coverage. Anyway, thanks for the Pageviews Analysis tool, it is helpful and quite interesting. Larsnooden (talk) 07:15, 18 August 2016 (UTC)
For sure! I can't really speak for our privacy policies except that they are intentionally very strict :) Referral information would indeed be helpful, and as I understand it is collected to some degree. In some exceptional cases, the Analytics and Reading teams are able to more data mining to figure out why there are spikes in traffic, for example phab:T141506. Some stats for global referrals, on a very broad basis, can be found on discovery.wmflabs.org, but again that doesn't really help you :/ MusikAnimal (WMF) (talk) 01:27, 19 August 2016 (UTC)
Are the Analytics and Reading teams' services ever available for individual books? Larsnooden (talk) 17:56, 26 August 2016 (UTC)

Could use link to article

I recall the older pageview had a link to the article, which is handy. With this pageview, there's no back arrow either. It would be great to have a direct link to the article. --Light show (talk) 08:50, 24 August 2016 (UTC)

I see nothing!

Perhaps my browser is of a too old version, but I get no results (I got results before, but now, it is completely blank). I can't find any information on not supported versions, and thus I presume that it is your page that is out of order. I have no intentions to upgrade to the increasingly stoopid and resource consuming versions of Firefox. Methinks this attitude of yours is shit. Because viewing some statistics showing that at least someone have visited a page one has written (probably not read, but at least visited) gives a little positive feedback that in a kind of way motivates one to write more articles. --Episcophagus (talk) 14:16, 24 August 2016 (UTC)

@Episcophagus: Hey! I'm happy to help you with this. Could you first tell me when the tool was last working for you? What article on which wiki are you trying to view statistics for? Finally, I do need know what browser version and operating system you are using. Firefox should be supported, unless it's very, very old. If you click on this link it should show a pop up with some information. Please copy and paste that here, as it will tell me exactly what browser and operating system you are using. Best, MusikAnimal (WMF) (talk) 15:37, 24 August 2016 (UTC)
@MusikAnimal (WMF): When it last worked was more than a year ago (or something like that). I'm apparently using: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6. Best, --Episcophagus (talk) 05:31, 25 August 2016 (UTC)
Ouch... It appears your browser and operating system are very outdated (7+ years). I'm in no position to encourage you to invest in a new computer or version of Windows, but unfortunately Pageviews Analysis requires technologies not available on your system. Upgrading Firefox itself may help, but I'm not sure what modern versions are available for Windows XP. I'm sorry I'm unable to help you further! MusikAnimal (WMF) (talk) 20:47, 29 August 2016 (UTC)

Topviews – how to get bottom views

No, that's not a joke. I want to get all views of a page and all its subpages (even if a subpage has minimal views) in order to get all views of all wikibooks.

For instance: b:de:Pathologie has about 80 subpages. The Topviews Analysis (Dec. 2015) contains 32 subpages between 18 and 1169 views but no pages with less views.

The complete 2015-12 list contains pages with a minimum of 13. I want to know the views of all pages with a minimum of at least 5. In this case the Pathologie result would give about 50*5 more views. That's a little difference, but other books and their subpages may lead to greater differences.

I tried some requests (list of pages, time range) but I wasn't able to get a list with less views than 13. Is there a way to set the requested minimum at a specific value? This option may be part of the mask or a parameter of the URL. Or is there another way to get such pages? -- Thank you! Juetho (talk) (Jürgen) 16:40, 28 August 2016 (UTC)

Topviews only provides (roughly) the top 1000 most-viewed pages of a project. This is an API limitation. However I can add subpages as a new "source" into Massviews which it sounds like will fulfill your need. I've created a ticket at phab:T144238. I don't plan on adding any options like "show pages with minimum N views", but you could export the data to CSV and filter those pages pretty easily (try Google Sheets if you don't have spreadsheet software on your computer). Hope this helps, MusikAnimal (WMF) (talk) 23:52, 29 August 2016 (UTC)

Topviews – how to download directly

In order to get total wikibooks statistics – all views of each wikibook all over the year – I want to analyze the csv results programmatically:

  • request the topviews analysis month by month
  • if possible including all pages with few views
  • save each analysis as csv file
  • open all csv files and count the views for each book's page (including all subpages) all over the year

Is it possible to save the result as csv file directly (without showing on the screen) using another URL parameter? If the result can show pages with few views this question may be omitted. -- Thank you! Juetho (talk) (Jürgen) 16:40, 28 August 2016 (UTC)

I suppose it is possible to add a parameter that forces a download of the data, but this may or may not help depending on how you'd be fetching it. All of the Pageviews apps are written in JavaScript, e.g. there are no backend API endpoints. So if you made a GET request to https://tools.wmflabs.org/pageviews?params&download=true it will respond with a HTML data type, and in a new tab you'd get the CSV with data type "text/csv" (code). This should be fine if you used JavaScript to make the requests and you actually wanted to download the CSV files to disk, but if you were to hit the endpoint using a headless browser or something like cURL I'm not sure it'd do what you wanted it to. I can happily add a download=true parameter, just first let me know if that's really what you want. At some point I hope to implement a real API using PHP, but for most cases developers would just assume use the RESTBase API that Pageviews Analysis goes off of. MusikAnimal (WMF) (talk) 00:06, 30 August 2016 (UTC)

Discrepancy between Topviews and Pageviews

What now about b:de:Einführung in SQL: Testdaten erzeugen?

Is there someone to explain this discrepancy? What's the best and most successful way to get really all views of all pages? -- Juetho (talk) (Jürgen) 06:34, 29 August 2016 (UTC)

As explained above Topviews shows (roughly) the top 1000 pages as provided by the RESTBase API. If you want total combined pageviews, consider using Siteviews. If you need pageviews data for each individual page, one by one, from which you can do calculations, you may want to just download the entire dataset. More info here and at Research:Page view. MusikAnimal (WMF) (talk) 00:16, 30 August 2016 (UTC)

Massviews – how to change a pagepile list

I created PagePile 4917. Unfortunately, my internet connection was interrupted while I saved the list. Therefore the list contains one wikibook page only (and an empty line). I want to add the missed lines, but I cannot find a way how to do.

  • How can I change the pagepile list?
  • If there's no way: how can I delete the wrong list?

Such a simple error, but I don't know how to correct. -- Juetho (talk) (Jürgen) 17:07, 25 August 2016 (UTC)

PS. Clearly, this isn't a PagePile talk page. But I don't find such a page (as well as I didn't find a help page). I hope that some PageView users have a hint. -- Juetho (talk) (Jürgen) 16:40, 28 August 2016 (UTC)

The answers about changing or deleting are "not available". See w:de:Wikipedia:Technik/Labs/Tools/pagepile: "Verändern lassen sie sich zurzeit nur durch Programmierer auf den Labs."
Moreover, it may be a bug: I tried again and got PagePile 4971 with the same result – first line correct, second line empty, no more lines. No problems while saving the list. I'll try to report but I have to create a new account for another host (BitBucket).   -- Juetho (talk) (Jürgen) 07:05, 29 August 2016 (UTC)
@Juetho: Yes, sounds like a bug on with PagePile. As far as I know you cannot update or delete piles. Would you mind sharing the list of pages you tried to add? Maybe I will notice something, perhaps it's the encoding. I'm about to reply to your other inquiries below (thank you for keeping them separate!), but won't spam you with a ping with each reply. Best MusikAnimal (WMF) (talk) 23:47, 29 August 2016 (UTC)
@MusikAnimal (WMF): I wrote that changing or deleting are "not available". Thank you for all your useful hints, I'll check them in the next days. -- Juetho (talk) 12:57, 30 August 2016 (UTC)
  This section is resolved and can be archived. If you disagree, replace this template with your comment. Bug is fixed by Magnus Manske, thank you! -- Juetho (talk) (Jürgen) 12:57, 30 August 2016 (UTC)

bug: TypeError: d is undefined; application.js:11:17281

If thismonth is selected and its the 1st day javascipt chokes. --grin 11:51, 1 September 2016 (UTC)

I'm assuming you're referring to Topviews. There's a new version of Topviews to be released soon and this bug will be fixed. Thanks for the report MusikAnimal (WMF) (talk) 16:24, 1 September 2016 (UTC)

Odd behavior

Over at RFD, the stats view link is behaving oddly. Clicking on "stats" for the first redirect, Trade and Industry, shows the page views as expected. But "stats" for the second redirect, Trade & Industry, gives instead the hits for the article Trade. I checked the markup; it looks fine. Is this because of the ampersand in the title of the second redirect? Gorthian (talk) 19:47, 2 September 2016 (UTC)

@Gorthian: After several very bad trial-and-error edits to a protected module, the issue is fixed :) Thanks for the report! MusikAnimal (WMF) (talk) 23:49, 2 September 2016 (UTC)
Very cool and very quick! Thanks! Gorthian (talk) 00:07, 3 September 2016 (UTC)

2016-09-02

Hello, where are the data of the Pageviews Analysis (german) of 2016-09-02, please? --Martin Geisler (talk) 09:19, 4 September 2016 (UTC)

Thank you. It's ok. --Martin Geisler (talk) 08:36, 5 September 2016 (UTC)

Topviews revamped

As of 8 September 2016, Topviews Analysis only shows data for a given month or a given day. Arbitrary date ranges are no longer supported.

Why this functionality was removed

The Pageviews API only provides the top 1000 pages for a given month or day. The old version of Topviews worked by querying for each day in the given date range, then giving you the sum of this data. This means that if a certain page was not in the top 1000 at some point during the given date range, the total views you saw might have been inaccurate. For the top 10 most viewed pages, this was usually a trivial difference, but the further you went down the list the more inaccurate the data might become.

In short, this was a hack that allowed some convenient functionality, but at the cost of providing potentially inaccurate data. The decision has been made to retire this hack and instead go directly off what the API provides.

How old links to the tool are handled

Old links that used the start and end parameters are automatically converted to showing either the month during which the date range falls in, or the first day of the date range, depending on how wide the range is.

Other improvements

The new "revamped" version also more accurately excludes pages that are not in the mainspace. This feature can be turned on and off as needed. See the Phabricator board for a list of other major improvements coming soon.


Any comments or concerns are most welcomed. Regards, MusikAnimal (WMF) (talk) 16:47, 8 September 2016 (UTC)

Bug? Can't find "Germán García Zacipa" om es.wikipedia.org

The article definitely exists on es.wikipedia.org at https://es.wikipedia.org/wiki/Germán_García_Zacipa . However, I'm unable to find it in Pageview Analysis. Unicode Bug? — The preceding unsigned comment was added by TuCove (talk)

@TuCove: Bad deploy. I've rolled it back, should be working now. Sorry about that! MusikAnimal (WMF) (talk) 18:41, 8 September 2016 (UTC)
No worries. Thanks for the super fast fix! --TuCove (talk) 18:45, 8 September 2016 (UTC)

Size of equatuions

Font size needs to bbe larger for many equaations Viewed on Samsung Note 10.1 with Androis Jelly Bean.

I'm not sure what you mean by "equations". Are you referring to the labels on the chart? MusikAnimal (WMF) (talk) 03:56, 18 September 2016 (UTC)

Does it work for any wiki?

None of the tools except Langviews seems to work for ro.wiki. Is this a known limitation or a bug? If the former, is there an ETA for introducing new projects? Thanks.--Strainu (talk) 22:32, 10 September 2016 (UTC)

@Strainu: All of the tools should work with any Wikimedia Foundation wiki, example. Is it not working for you? Or are there certain articles that aren't showing any data, when you believe they should? MusikAnimal (WMF) (talk) 21:53, 11 September 2016 (UTC)
It works now. This is the second wiki-related service that did not work for me Saturday. Probably some connection issue on my side.--Strainu (talk) 08:27, 12 September 2016 (UTC)

Congrats! Great Job

High team just entered new link settings in sw.wikipedia as proposed by MusikAnimal. Much better, great Job, thank you all!! 10:23, 12 September 2016 (UTC)

Thank you! And you are welcome :) MusikAnimal (WMF) (talk) 05:03, 14 September 2016 (UTC)

Error in Topview

Hi there. I noticed when looking at the last avataible daily topview for ca.wiki, link, that the top page is "xss" as I see it in my Chromium in Debian Jessie. This "xss" page does not exist in ca.wiki, so I guess something is not OK. Thanks. --Lluis tgn (talk) 22:44, 19 September 2016 (UTC)

@Lluis tgn: This is a "false positive", see the FAQ for more information. These have been showing up more and more lately, and the analytics team is working on it (see also T123442, T144715, T145043). Basically, as it stands now, you're likely to continue seeing pages like this :( For visualization, you can hover over the "xss" entry and click on the ✖ to exclude that page from view, and the list will be re-sorted (example). One tactic to identify false positives is to compare desktop views with mobile web. Mobile web views should be comparable if not higher than desktop, so if mobile web views are very low, it might be a false positive. Hope this helps! MusikAnimal (WMF) (talk) 04:49, 20 September 2016 (UTC)
OK! Many thanks for the links and explanations. Cheers. --Lluis tgn (talk) 10:42, 20 September 2016 (UTC)

Begin at zero

Hi, very useful feature. A small comment: in my opinion "Begin at zero" should be selected by default.

Oh, also, I've just noticed that the "Page view statistics" links from Wikipedia "View history" pages no longer seem to be working properly (previously they worked fine, as far as I recall). The identity of the source article does not seem to be automatically picked up any more; instead you are thrown into a blank chart and have to type the article name again. — The preceding unsigned comment was added by 86.185.70.239 (talk)

Begin at zero is off by default because for many articles it's difficult to see fluctuations in data. The begin at zero takes up a lot of real estate on the chart, so starting at some common figure amongst all dates means we can better illustrate how the pageviews have changed over time. If you want to always begin at zero, go to Settings and select "Always show the y-axis starting at zero".
The links on the View History page should still be working. Can you give me an example of a page where the link is broken? Is this on the English Wikipedia? Thanks MusikAnimal (WMF) (talk) 20:07, 20 September 2016 (UTC)
Also, what browser and operating system are you using (for example, Windows 10 with Chrome 55)? MusikAnimal (WMF) (talk) 20:11, 20 September 2016 (UTC)
Thanks ... Sure, be in no doubt that I understand the purpose of "Begin at zero = off". However, my view is nevertheless that it should be on by default, unless you specifically choose to turn it off. "Difficult to see fluctuations in data", if that is the case, actually shows the realistic picture -- that the fluctuations are negligible.
As far as the other point is concerned, it breaks for me on Win 10 with 'Edge' browser on all English Wikipedia pages that I have tried. It works for me on Win 10 with both Chrome and IE. I believe it used to work with 'Edge'. In the 'Edge' browser, to give one example, where the link from the "View history" page is
https://tools.wmflabs.org/pageviews?pages=Katakana&project=en.wikipedia.org
I actually get taken to the page
https://tools.wmflabs.org/pageviews/?project=en.wikipedia.org&platform=all-access&agent=user&range=latest-20&pages=
where it appears that the parameter "pages=" has been truncated for some unknown reason. 86.185.70.239 20:28, 20 September 2016 (UTC)
Thanks for the feedback! I will get this fixed on Edge very soon. For begin at zero, I will give your recommendation some thought and talk to some other folks about it. The tool attracts both casual users and those with a background in statistics, and it seems these two groups have conflicting views on how the data should be presented. Hopefully we can find a happy medium :) MusikAnimal (WMF) (talk) 21:10, 20 September 2016 (UTC)
Hmm, I tried this out on Windows 10 with Edge and the link worked as expected. What version of Edge are you using? I have version 20 (found by going to Settings and scrolling to the bottom) MusikAnimal (WMF) (talk) 18:56, 21 September 2016 (UTC)
Return to "Pageviews Analysis/Archives/2016/3" page.