Tbayer (Tilman Bayer)
User

Today

  • Clear sailing ahead.

Tomorrow

  • Clear sailing ahead.

Tuesday

  • Clear sailing ahead.

User Details

User Since
Oct 20 2014, 11:21 PM (173 w, 5 d)
Availability
Available
IRC Nick
HaeB
LDAP User
Unknown
MediaWiki User
Tbayer (WMF)

Recent Activity

Yesterday

Tbayer updated subscribers of T187244: English Wikivoyage traffic spike possible bot.

BTW, Alexa has noticed this too:

Sat, Feb 17, 3:42 AM · Analytics-Kanban
Tbayer added a comment to T181297: Instrument print to PDF button.

Great, thanks! Were you also able to check that the events contained the correct value for each field as described in the schema? (In particular, the session token should be the same for each of these three events, and generally for all events sent during that browser session.)

Sat, Feb 17, 2:29 AM · MW-1.31-release-notes (WMF-deploy-2018-01-16 (1.31.0-wmf.17)), Patch-For-Review, Readers-Web-Kanbanana-Board, Proton, Readers-Web-Backlog

Thu, Feb 15

Tbayer added a comment to T187244: English Wikivoyage traffic spike possible bot.

Out of curiosity I took a quick peek at various dimensions in Pivot. (BTW, we should write up some kind of playbook on efficient initial investigations of such pageview anomalies, as this kind of thing comes up fairly regularly - see e.g. T180621 for another recent example. I may take a stab at this at some point.) Don't have time right now for a more detailed writeup or further investigation, but here are the takeaways so far:

Thu, Feb 15, 7:30 AM · Analytics-Kanban
Tbayer added a comment to T182314: Analyze results of enwiki and dewiki page previews a/b test.

(work log, switching back to the main task for now, the part that's independent of the timing questions ;)
We now also have a sizable amount of data from the new test launched in December (which ran a bit longer than anticipated, but is soon to be deactivated in T185973). I repeated the calculation of the difference in pageviews (per session) from T182314#3896974 for this new data.

Thu, Feb 15, 6:01 AM · Readers-Web-Kanbanana-Board, Readers-Web-Backlog, Reading-analysis, Page-Previews

Wed, Feb 14

Tbayer added a comment to T187277: Should it be possible for a schema to override DNT in exceptional circumstances?.

Furthermore, let's keep in mind that the preview EL event being discussed here (T184793) would always be immediately preceded by the existing API request for the preview content, which is already being logged in the webrequest table (for both DNT users and non-DNT users). In other words, the privacy benefits of not registering previews seen by DNT users would be minimal.

Wed, Feb 14, 7:32 PM · Analytics-EventLogging, Analytics
Tbayer added a comment to T187277: Should it be possible for a schema to override DNT in exceptional circumstances?.

How will the EventLogging client side javascript know if an event is a "page view like" or the more common UI interaction measurement?

As outlined in the task description (1.), the instrumentation code generating such an event could pass an override parameter to the standard function responsible for sending it, making it easy to audit the code to ensure that only the few applicable schemas use it.

Wed, Feb 14, 7:25 PM · Analytics-EventLogging, Analytics
Tbayer added a comment to T187277: Should it be possible for a schema to override DNT in exceptional circumstances?.

And for context, the overarching issue here is that EventLogging's main use case has been studying UI interactions, where excluding DNT makes sense (no one wants to change that as far as I know). But now we want to use it for a different purpose, tallying content consumption, which, as @Tgr and I pointed out in last month's discussion already, is a different matter. In the 2015 task linked above (T98831#3107001 ), @Nuria expressed the same point as follows:

EL data is most of the time about user behaviour when using the site. That data is of different nature than data that js just used to agreggates counts. For example: "number of pageviews on italian wikipedia coming from italy".

Wed, Feb 14, 5:26 PM · Analytics-EventLogging, Analytics
Tbayer updated subscribers of T187277: Should it be possible for a schema to override DNT in exceptional circumstances?.

The question is whether something that tracks page-view-like things should be consistent with how we collect page views (which does not respect DoNotTrack). :)

See: https://phabricator.wikimedia.org/T98831 for requests about pageviews abiding to DNT, there are several of these, this is just one of the most modern ones.

Wed, Feb 14, 5:19 PM · Analytics-EventLogging, Analytics
Tbayer added a comment to T187244: English Wikivoyage traffic spike possible bot.

The Zimbabwe page shows an increase of 1000-2000 per day per
https://tools.wmflabs.org/pageviews/?project=en.wikivoyage.org&platform=all-access&agent=user&range=latest-20&pages=Zimbabwe - surely not enough to explain the >100k/day increase for the entire project?

Wed, Feb 14, 3:18 AM · Analytics-Kanban

Tue, Feb 13

Tbayer added a comment to T182314: Analyze results of enwiki and dewiki page previews a/b test.

Thanks @Jhernandez, very interesting! I'll need some time to fully read and digest your findings; but one response inline for now:

Tue, Feb 13, 6:03 PM · Readers-Web-Kanbanana-Board, Readers-Web-Backlog, Reading-analysis, Page-Previews
Tbayer moved T179915: Determine expected amount of usage of mobile print to PDF button per browser from Next Up to Blocked on the Reading-analysis board.
Tue, Feb 13, 3:41 AM · Reading-analysis, Readers-Web-Backlog
Tbayer closed T185963: Update Audiences page and Key Product Metrics with January 2018 Readers data as Resolved.
Tue, Feb 13, 3:41 AM · Reading-analysis

Mon, Feb 12

Tbayer updated subscribers of T184793: Instrument page interactions.

The instrumentation should ignore DNT. Requests with the DNT header set are included in our webrequest_raw, webrequest, and pageviews (aggregated) tables and this instrumentation is to be considered analogous.

We will probably be evaluating how wide is the spread of DNT across our users in the mid term rather than rolling back our DNT support. In the case of eventlogging if DNT is enabled no DNT events are sent.

I don't think anyone asked for "rolling back our DNT support" in general. Supporting DNT makes sense for EL's main use case of studying UI interactions. But as @Tgr and I pointed out in last month's discussion, tallying content consumption - i.e. this instrumentation - is a different matter. We have long resolved to not ignore DNT traffic in our pageview data, and the preview data needs to be consistent with that.

Mon, Feb 12, 10:53 PM · Patch-For-Review, Readers-Web-Kanbanana-Board, Page-Previews, Readers-Web-Backlog
Tbayer updated the task description for T184793: Instrument page interactions.
Mon, Feb 12, 8:37 PM · Patch-For-Review, Readers-Web-Kanbanana-Board, Page-Previews, Readers-Web-Backlog
Tbayer added a comment to T184793: Instrument page interactions.

Given we're not creating anything that we want to "measure"

Don't see this in schema, but you are tracking how long someone spends viewing before sending the event? You could send a measure_view_seconds or something? Just another idea :)

The idea is to send the event as soon at the 1000ms threshold has been reached (and to not record events if less than 1000ms were spent viewing), so that wouldn't be very informative.

Mon, Feb 12, 8:32 PM · Patch-For-Review, Readers-Web-Kanbanana-Board, Page-Previews, Readers-Web-Backlog
Tbayer added a comment to T186180: Move non-critical monthly jobs to the nice queue.

@Tbayer : maybe you can help us identify here what is not critical ?

We could schedule jobs for app sessions later in the month for example, this data does not seem that is looked at much. Would that work?

No, we still would want to have that data as soon as possible - just avoid it interfering with more timely one-off queries when these queries run.

Mon, Feb 12, 6:08 PM · Analytics-Kanban, Patch-For-Review, Analytics-Cluster
Tbayer added a comment to T186180: Move non-critical monthly jobs to the nice queue.

@JAllemandou This is not what the task was about; how about we create a separate one for the Clickstream job

Mon, Feb 12, 6:06 PM · Analytics-Kanban, Patch-For-Review, Analytics-Cluster
Tbayer renamed T186180: Move non-critical monthly jobs to the nice queue from Move Clickstream job to later in the month to Move non-critical monthly jobs to the nice queue.
Mon, Feb 12, 6:05 PM · Analytics-Kanban, Patch-For-Review, Analytics-Cluster
mpopov awarded T186180: Move non-critical monthly jobs to the nice queue a Like token.
Mon, Feb 12, 5:47 PM · Analytics-Kanban, Patch-For-Review, Analytics-Cluster
Tbayer updated subscribers of T187014: Investigate drop in Opera Mini traffic in Nigeria on February 6.

Actually it looks like the Nigerian Opera Mini traffic was just rerouted (or reclassified in a Maxmind update), first to an "Unknown" geolocation, then (since yesterday, February 11), the US.

@Ottomata, @Milimetric I suppose we didn't roll out Maxmind updates at either of these two times (February 6 between 20:00 and 21:00 UTC, and February 11 ca. between 1-3am UTC)?

Mon, Feb 12, 10:48 AM · Readers-Web-Backlog (Tracking), Mobile, New-Readers
Tbayer added a comment to T187014: Investigate drop in Opera Mini traffic in Nigeria on February 6.

Actually it looks like the Nigerian Opera Mini traffic was just rerouted (or reclassified in a Maxmind update), first to an "Unknown" geolocation, then (since yesterday, February 11), the US. Also from several countries besides Nigeria, including Indonesia and (although not to the same extent) India:


Source: Pivot

Mon, Feb 12, 5:43 AM · Readers-Web-Backlog (Tracking), Mobile, New-Readers
Tbayer renamed T187014: Investigate drop in Opera Mini traffic in Nigeria on February 6 from Investigate drop in Opera Mini traffic in Nigeria in February 6 to Investigate drop in Opera Mini traffic in Nigeria on February 6.
Mon, Feb 12, 4:53 AM · Readers-Web-Backlog (Tracking), Mobile, New-Readers
Tbayer created T187014: Investigate drop in Opera Mini traffic in Nigeria on February 6.
Mon, Feb 12, 4:50 AM · Readers-Web-Backlog (Tracking), Mobile, New-Readers

Fri, Feb 9

Tbayer claimed T182314: Analyze results of enwiki and dewiki page previews a/b test.

I'm inclined to believe that this is not a bug but an artefact of the resolution of JS timers, which apparently varies by browser and OS.

Fri, Feb 9, 10:01 PM · Readers-Web-Kanbanana-Board, Readers-Web-Backlog, Reading-analysis, Page-Previews
Tbayer awarded T186682: Bug in user sampling for MobileWikiAppSessions a Evil Spooky Haunted Tree token.
Fri, Feb 9, 7:51 PM · Patch-For-Review, Wikipedia-Android-App-Backlog, Discovery-Analysis
Tbayer closed T186130: Hive EventLogging tables not updating since January 26 as Resolved.
Fri, Feb 9, 7:45 PM · Analytics-Kanban, Analytics-EventLogging
Tbayer added a comment to T186130: Hive EventLogging tables not updating since January 26.

BTW, I believe this should be fixed, please tell me if otherwise.

Thanks! The checks from T186130#3939824 look good now (feel free to adapt these queries next time something like this needs to be tested).

Fri, Feb 9, 7:44 PM · Analytics-Kanban, Analytics-EventLogging

Thu, Feb 8

Tbayer closed T185965: Report and analyze core metrics for Q2 Readers Metrics presentation as Resolved.

Slides: https://commons.wikimedia.org/wiki/File:Wikimedia_Foundation_Readers_metrics_Q2_2017-18_(Oct-Dec_2017).pdf

Thu, Feb 8, 10:22 PM · Reading-analysis
Tbayer awarded T186833: Include X-Client-IP in EventLogging data and geocode during Hive JSON Refinement a Hungry Hippo token.
Thu, Feb 8, 10:21 PM · Patch-For-Review, Analytics-Kanban
Tbayer updated subscribers of T186728: Record and aggregate page previews.

@Ottomata @Nuria Since it looks from the discussion at T184793 that there wasn't yet full clarity around this:
Please take a look at this list of required fields; we should make sure that your team will be able to implement this aggregation table based on the client-side approach currently proposed in T184793 (in a reasonable timeframe), before @phuedx and the web team go ahead with it.

Thu, Feb 8, 8:02 PM · Patch-For-Review, Analytics-Kanban
Tbayer added a comment to T184793: Instrument page interactions.

Responded on thread, this place is better though, so I will paste here:

(right, thanks for moving things here)

If you only need country (or whatever is in the cookie), then likely whatever the output dataset would only include country when selecting from pageviews. If you need more than country (it sounded like you didn’t), then we can look into doing the IP Geocoding in EventLogging, but there are some technical complications here, and we’d prefer not to have to do this if we don’t have to.

Country was just an example. Again, it was said clearly early on that the goal is to record previews in the same way as we do pageviews; concretely that means the same information as in pageview_hourly. I would have thought the AE team is aware that this includes various other fields (subdivision, say, which is not present in the GeoIP cookie, but also non-geolocation information like agent_type). Please have a look at the detailed requirements list at T186728 if you haven't already done so.

Thu, Feb 8, 7:56 PM · Patch-For-Review, Readers-Web-Kanbanana-Board, Page-Previews, Readers-Web-Backlog
Tbayer added a comment to T182314: Analyze results of enwiki and dewiki page previews a/b test.

Here is yet another view which may be the most instructive way to look at the issue - basically a magnifying glass aimed at a part of the graph from T182314#3949885 (that between 1.00 and 1.20 seconds), likewise in the original millisecond resolution instead of the 1/100 second buckets. Looks like the periodicity may indeed be close to 16⅔ ms (12 repetitions in this 200ms timespan).

Thu, Feb 8, 2:39 AM · Readers-Web-Kanbanana-Board, Readers-Web-Backlog, Reading-analysis, Page-Previews
Tbayer added a comment to T184677: Measure impact of Singapore data center on Wikimedia usage.

What's the current timeline for this? (I assume there is a general tracking task for the switchover?) I'll be happy to weigh in with details on those metrics that we could look at.

Thu, Feb 8, 12:47 AM · Discovery-Analysis (Current work)
mpopov awarded T180651: Calculate Android app daily active users from Nigeria a 100 token.
Thu, Feb 8, 12:38 AM · New-Readers, Reading-analysis
Tbayer added a comment to T186768: Add client timestamp to MobileWikiAppSessions.

Also a note that we should strive to make its format compatible with the general client-side timestamp planned as part of the extended app capsule in the upcoming general app analytics framework.

Thu, Feb 8, 12:32 AM · Wikipedia-Android-App-Backlog

Wed, Feb 7

Tbayer reassigned T182314: Analyze results of enwiki and dewiki page previews a/b test from Tbayer to phuedx.

As discussed in kickoff today, reassigning this temporarily to @phuedx for some engineering attention on the above timing issues (rather than breaking them out into a new task).

Wed, Feb 7, 10:16 PM · Readers-Web-Kanbanana-Board, Readers-Web-Backlog, Reading-analysis, Page-Previews
Tbayer added a comment to T184793: Instrument page interactions.

As discussed on the thread, we should not be using the GeoIP cookie because this would result in data incompatible with the existing geolocation data for pageviews (where we have chosen to derive this from the IP instead).

Wed, Feb 7, 5:14 PM · Patch-For-Review, Readers-Web-Kanbanana-Board, Page-Previews, Readers-Web-Backlog
Tbayer updated the task description for T184793: Instrument page interactions.
Wed, Feb 7, 5:11 PM · Patch-For-Review, Readers-Web-Kanbanana-Board, Page-Previews, Readers-Web-Backlog
Tbayer added a parent task for T184793: Instrument page interactions: T186728: Record and aggregate page previews.
Wed, Feb 7, 5:02 PM · Patch-For-Review, Readers-Web-Kanbanana-Board, Page-Previews, Readers-Web-Backlog
Tbayer added a subtask for T186728: Record and aggregate page previews: T184793: Instrument page interactions.
Wed, Feb 7, 5:02 PM · Patch-For-Review, Analytics-Kanban
Tbayer updated the task description for T184793: Instrument page interactions.
Wed, Feb 7, 5:02 PM · Patch-For-Review, Readers-Web-Kanbanana-Board, Page-Previews, Readers-Web-Backlog
Tbayer created T186728: Record and aggregate page previews.
Wed, Feb 7, 4:59 PM · Patch-For-Review, Analytics-Kanban
Tbayer added a comment to T185584: Understanding main page traffic around Hindi video campaign.

By the way, if we want to take "new readers" literally and try to quantify them, it may be worth looking at the Last-Access cookie. (If it is not set, the user has never visited Wikipedia before with that device. Well, or deleted their cookies, or visited only in a past incognito browsing session... but changes in the relative frequency of such views should still give us meaningful information.)

Wed, Feb 7, 3:40 AM · Reading-analysis
Tbayer added a comment to T185584: Understanding main page traffic around Hindi video campaign.

Do we already have an update on when the campaign may launch?

Wed, Feb 7, 3:34 AM · Reading-analysis
Tbayer updated the task description for T185584: Understanding main page traffic around Hindi video campaign.
Wed, Feb 7, 3:33 AM · Reading-analysis

Tue, Feb 6

Tbayer awarded T60763: Flow: no "Redirected from" and mediawiki.action.view.redirect on Flow pages. a Cup of Joe token.
Tue, Feb 6, 11:56 PM · Collaboration-Team-Triage, StructuredDiscussions
Tbayer updated subscribers of T186180: Move non-critical monthly jobs to the nice queue.
Tue, Feb 6, 9:28 PM · Analytics-Kanban, Patch-For-Review, Analytics-Cluster
Tbayer updated the task description for T182314: Analyze results of enwiki and dewiki page previews a/b test.
Tue, Feb 6, 8:47 PM · Readers-Web-Kanbanana-Board, Readers-Web-Backlog, Reading-analysis, Page-Previews
Tbayer updated the task description for T182314: Analyze results of enwiki and dewiki page previews a/b test.
Tue, Feb 6, 8:31 PM · Readers-Web-Kanbanana-Board, Readers-Web-Backlog, Reading-analysis, Page-Previews
Tbayer added a comment to T182314: Analyze results of enwiki and dewiki page previews a/b test.

And to be clear, the concern here is not about precision per se - for the purposes of evaluating the A/B test, and to generate this histogram, a resolution of 50ms would be quite OK. Rather, the concern is that the cause fpr the comb pattern could be a bug like (wild paranoid imagination) some user agents logging a multiple of the true value.

Tue, Feb 6, 8:11 PM · Readers-Web-Kanbanana-Board, Readers-Web-Backlog, Reading-analysis, Page-Previews
Tbayer added a comment to T182314: Analyze results of enwiki and dewiki page previews a/b test.

So since it looks that that weird comb structure has a periodicity of 5 (hundredths of a second), I took a look at the distribution mod 50ms, in the original resolution of 1ms (and limited to >=500s so as not to distort the result with the huge spike below that):


This is all a bit strange, in particular considering that the opened event doesn't' seem to exhibit the same pattern (only dwelledButAbandoned and dismissed), and that 50 is not divisible by 3.

Tue, Feb 6, 8:06 PM · Readers-Web-Kanbanana-Board, Readers-Web-Backlog, Reading-analysis, Page-Previews
Tbayer added a comment to T182314: Analyze results of enwiki and dewiki page previews a/b test.

...

I generated histograms of the link interaction timing by action type again. As noted at the time of the previous A/B tests, we didn't quite have enough data yet back then for an entirely smooth plot (the graphs looked choppy because of random variation). This is no longer a concern with the last two experiments (Oct/Nov and Dec/Jan). However, there a kind of comb structure visible now which seems to be point to some kind of rounding issue, perhaps only for some browsers. I may re-generate this with a different bucket size once I have a better sense how the timing the browsers send are quantized.

PS: in any case, it doesn't seem to be due to last month's Meltdown/Spectre mitgation changes that reduced the resolution of the performance.now() timer in all major browsers: The histogram from the October/November experiment (still need to post it) looks similarly comb-like.

Here it is; the pattern is the same, with a periodicity of 5:

Tue, Feb 6, 6:23 PM · Readers-Web-Kanbanana-Board, Readers-Web-Backlog, Reading-analysis, Page-Previews
Tbayer updated subscribers of T182314: Analyze results of enwiki and dewiki page previews a/b test.

...

I generated histograms of the link interaction timing by action type again. As noted at the time of the previous A/B tests, we didn't quite have enough data yet back then for an entirely smooth plot (the graphs looked choppy because of random variation). This is no longer a concern with the last two experiments (Oct/Nov and Dec/Jan). However, there a kind of comb structure visible now which seems to be point to some kind of rounding issue, perhaps only for some browsers. I may re-generate this with a different bucket size once I have a better sense how the timing the browsers send are quantized.

PS: in any case, it doesn't seem to be due to last month's Meltdown/Spectre mitgation changes that reduced the resolution of the performance.now() timer in all major browsers: The histogram from the October/November experiment (still need to post it) looks similarly comb-like.

Tue, Feb 6, 5:54 PM · Readers-Web-Kanbanana-Board, Readers-Web-Backlog, Reading-analysis, Page-Previews

Mon, Feb 5

Tbayer added a comment to T182314: Analyze results of enwiki and dewiki page previews a/b test.

...

I generated histograms of the link interaction timing by action type again. As noted at the time of the previous A/B tests, we didn't quite have enough data yet back then for an entirely smooth plot (the graphs looked choppy because of random variation). This is no longer a concern with the last two experiments (Oct/Nov and Dec/Jan). However, there a kind of comb structure visible now which seems to be point to some kind of rounding issue, perhaps only for some browsers. I may re-generate this with a different bucket size once I have a better sense how the timing the browsers send are quantized.

PS: in any case, it doesn't seem to be due to last month's Meltdown/Spectre mitgation changes that reduced the resolution of the performance.now() timer in all major browsers: The histogram from the October/November experiment (still need to post it) looks similarly comb-like.

Mon, Feb 5, 8:22 PM · Readers-Web-Kanbanana-Board, Readers-Web-Backlog, Reading-analysis, Page-Previews

Sun, Feb 4

Tbayer added a comment to T154735: Investigate rise in iOS app pageviews since around December 20, 2016.

Epilogue: Over a year later, there still seem to be some faulty clients out there, generating 10-20k spurious pageviews per day. (Concretely: In January 2018, the effect of the correction in T154735#3212581 was still around 2%, whereas from Dec 1-Dec 18 2016 - right before the bug occurred - it had between 0.7-0.9%, as an estimate of the overcorrection involved.) But that's low enough now that I'm stopping to use this correction for our general pageview data from January on.

Sun, Feb 4, 4:59 AM · iOS-app-v5.4.1-Patchy-Boot, Wikipedia-iOS-App-Backlog, iOS-app-feature-Analytics

Sat, Feb 3

Tbayer added a comment to T186130: Hive EventLogging tables not updating since January 26.

Ping - I seem to recall someone saying that we only have one week's worth of data buffered in Kafka for this. Considering that it's now already one week after the gap started to occur, does this mean that the data is already starting to become irretrievably lost from the Hive perspective?

Sat, Feb 3, 1:00 AM · Analytics-Kanban, Analytics-EventLogging

Fri, Feb 2

Tbayer added a comment to T184089: Understand Android app usage by market.

Regarding "We are very close to the median visit-to-install conversion rate across the whole Play Store":
Is that reference rate really across the whole Play Store, or rather in the "Books & Reference" category ?
Again it might be useful to link the corresponding Play Store analytics page, which suggest the latter.
BTW, it also shows (click "For 1 day" etc.) that our retention rates are way above the benchmark.

Fri, Feb 2, 1:56 AM · Discovery-Analysis (Current work)
Tbayer added a comment to T184089: Understand Android app usage by market.

A suggestion: How about linking each part to the corresponding interactive visualization/report that Google provides in the Play Store?
E.g.:

etc.

Fri, Feb 2, 1:47 AM · Discovery-Analysis (Current work)
Tbayer added a comment to T186130: Hive EventLogging tables not updating since January 26.

Ok, still not sure why that one job was stuck, but after killing it, the next scheduled run seemed to have work. @Tbayer, let us know if it is looking better now for ya.

Well yes, all the days since January 29 look good now, but we are still missing all events from between January 26 4:00 and January 28 17:00 UTC it seems:

Fri, Feb 2, 1:12 AM · Analytics-Kanban, Analytics-EventLogging
Tbayer added a comment to T172581: Set up mechanism for archiving Google Search Console data.

FWIW, Google is currently rolling out a new version of the Search Console that (among other changes) makes some data available for a longer timespan - 16 months: https://webmasters.googleblog.com/2018/01/introducing-new-search-console.html
(E.g. right now we can look up clicks, impressions, CTR and position for https://es.wikipedia.org since September 30, 2016.)
According to the annoucement post, "In the near future, this data will also be available via the Search Console API", so perhaps we should extend/modify Mikhail's tool to ingest that data too.

Fri, Feb 2, 12:20 AM · Discovery-Analysis (Current work), Discovery, SEO, Reading-analysis

Thu, Feb 1

Tbayer added a comment to T182314: Analyze results of enwiki and dewiki page previews a/b test.

(Leaving this here for want of a better place:)

Thu, Feb 1, 5:04 PM · Readers-Web-Kanbanana-Board, Readers-Web-Backlog, Reading-analysis, Page-Previews
Tbayer moved T182314: Analyze results of enwiki and dewiki page previews a/b test from Triage to In progress on the Reading-analysis board.
Thu, Feb 1, 7:03 AM · Readers-Web-Kanbanana-Board, Readers-Web-Backlog, Reading-analysis, Page-Previews
Tbayer moved T184227: Measured impact of SVG optimizations from Triage to Blocked on the Reading-analysis board.
Thu, Feb 1, 7:00 AM · Reading-analysis, MW-1.31-release-notes (WMF-deploy-2018-01-02 (1.31.0-wmf.15)), UI-Standardization
Tbayer added a comment to T184227: Measured impact of SVG optimizations.

(This task is mostly done and the result was used in the Contributors team's quarterly check-in, but we are keeping it open to extend the result to all languages - it looks like it's easy to extend the above query using a regex - and to hold off until after some further optimization work @Volker_E is doing.)

Thu, Feb 1, 7:00 AM · Reading-analysis, MW-1.31-release-notes (WMF-deploy-2018-01-02 (1.31.0-wmf.15)), UI-Standardization
Tbayer updated the task description for T186180: Move non-critical monthly jobs to the nice queue.
Thu, Feb 1, 1:42 AM · Analytics-Kanban, Patch-For-Review, Analytics-Cluster
Tbayer created T186180: Move non-critical monthly jobs to the nice queue.
Thu, Feb 1, 1:37 AM · Analytics-Kanban, Patch-For-Review, Analytics-Cluster

Wed, Jan 31

Tbayer added a comment to T186130: Hive EventLogging tables not updating since January 26.

Also, as noted earlier at https://phabricator.wikimedia.org/T185952#3930033 ([2]), the MySQL tables seem up to date.

Wed, Jan 31, 10:29 PM · Analytics-Kanban, Analytics-EventLogging
Tbayer added a comment to T179540: Timestamp format in Hive-refined EventLogging tables is incompatible with MySQL version.

I talked with Timo and with the A-team, and we decided it'd be best to remove timestamp altogether in favor of dt. This will make future maintenance and transitions (possibly off of python based EventLogging code) easier, as there will be fewer special cases.

I still think such a large breaking change should have been discussed with a wider group of affected users. But to go forward:

Wed, Jan 31, 9:15 PM · Analytics-Kanban, Analytics-EventLogging
Tbayer created T186155: Provide MediaWiki timestamps in Hive-refined EventLogging tables via UDF.
Wed, Jan 31, 9:14 PM · Patch-For-Review, Analytics-Kanban, Analytics-EventLogging
Tbayer added a comment to T185952: EventLogging broken in beta.

Thanks @elukey - yes, this was just a guess, based on the fact that the Hive tables stopped updating on the same day (January 26). To be precise, the latest timestamp in event.navigationtiming is 2018-01-26T03:59:59 right now. @Ottomata , should we open a separate bug for this?

Wed, Jan 31, 5:53 PM · Analytics-Kanban, User-Elukey, Beta-Cluster-Infrastructure, Analytics-EventLogging
Tbayer created T186130: Hive EventLogging tables not updating since January 26.
Wed, Jan 31, 5:52 PM · Analytics-Kanban, Analytics-EventLogging

Tue, Jan 30

Tbayer added a subtask for T176211: Page Previews could load less JS on pageload: T186016: Analyze time to first link interaction.
Tue, Jan 30, 4:54 PM · MW-1.31-release-notes (WMF-deploy-2018-02-06 (1.31.0-wmf.20)), Performance-Team (Radar), Readers-Web-Backlog, Page-Previews
Tbayer added a parent task for T186016: Analyze time to first link interaction: T176211: Page Previews could load less JS on pageload.
Tue, Jan 30, 4:54 PM · Readers-Web-Kanbanana-Board, Readers-Web-Backlog, Page-Previews, Reading-analysis
Tbayer created T186016: Analyze time to first link interaction.
Tue, Jan 30, 4:53 PM · Readers-Web-Kanbanana-Board, Readers-Web-Backlog, Page-Previews, Reading-analysis
Tbayer updated subscribers of T185952: EventLogging broken in beta.

Thanks @elukey - yes, this was just a guess, based on the fact that the Hive tables stopped updating on the same day (January 26). To be precise, the latest timestamp in event.navigationtiming is 2018-01-26T03:59:59 right now. @Ottomata , should we open a separate bug for this?

Tue, Jan 30, 4:45 PM · Analytics-Kanban, User-Elukey, Beta-Cluster-Infrastructure, Analytics-EventLogging
Tbayer added a comment to T185952: EventLogging broken in beta.

The problem seems to be more general: it appears that all the EventLogging tables in Hive (in the new "event" database) are likewise lagging behind, with their last update dating to January 26, e.g. [1]. On the other hand, things look up to date in MySQL.[2]

Aren't [1] and [2] related to Prod? I didn't get the connection sorry :(

Tue, Jan 30, 5:46 AM · Analytics-Kanban, User-Elukey, Beta-Cluster-Infrastructure, Analytics-EventLogging
Tbayer added a comment to T185952: EventLogging broken in beta.

The problem seems to be more general: it appears that all the EventLogging tables in Hive (in the new "event" database) are likewise lagging behind, with their last update dating to January 26, e.g. [1]. On the other hand, things look up to date in MySQL.[2]

Tue, Jan 30, 3:17 AM · Analytics-Kanban, User-Elukey, Beta-Cluster-Infrastructure, Analytics-EventLogging
Tbayer created T185973: [Config] Disable Page Previews EventLogging instrumentation.
Tue, Jan 30, 12:41 AM · Readers-Web-Kanbanana-Board, Wikimedia-Site-requests, Readers-Web-Backlog, Page-Previews

Mon, Jan 29

Tbayer moved T185963: Update Audiences page and Key Product Metrics with January 2018 Readers data from Triage to Blocked on the Reading-analysis board.
Mon, Jan 29, 11:23 PM · Reading-analysis
Tbayer moved T185964: Update Audiences page and Key Product Metrics with February 2018 Readers data from Triage to Blocked on the Reading-analysis board.
Mon, Jan 29, 11:23 PM · Reading-analysis
Tbayer created T185965: Report and analyze core metrics for Q2 Readers Metrics presentation.
Mon, Jan 29, 11:22 PM · Reading-analysis
Tbayer created T185964: Update Audiences page and Key Product Metrics with February 2018 Readers data.
Mon, Jan 29, 11:19 PM · Reading-analysis
Tbayer created T185963: Update Audiences page and Key Product Metrics with January 2018 Readers data.
Mon, Jan 29, 11:18 PM · Reading-analysis
Tbayer closed T180870: Update Audiences page and Key Product Metrics with December 2017 Readers data as Resolved.
Mon, Jan 29, 11:17 PM · Reading-analysis
Tbayer closed T180869: Update Audiences page and Key Product Metrics with November 2017 Readers data as Resolved.
Mon, Jan 29, 11:17 PM · Reading-analysis

Fri, Jan 26

Tbayer added a comment to T184841: CSS loaded twice under Firefox on mobile.

BTW, as Ian pointed out, the log entry for the second load of this CSS file has the little JS icon next to it (see screenshots above), meaning it was loaded by some JavaScript code. Here is a screenshot of the stack trace:

Fri, Jan 26, 7:16 PM · Performance-Team (Radar), Upstream, Readers-Web-Backlog (Tracking)
Tbayer added a comment to T184841: CSS loaded twice under Firefox on mobile.

@Imarlier and I just looked at this again on my laptop, reproducing the issue again (in case of this page) and saving the page from the browser:

Fri, Jan 26, 7:09 PM · Performance-Team (Radar), Upstream, Readers-Web-Backlog (Tracking)
Tbayer added a comment to T185350: Vet reliability of the response_size field for data analysis purposes.

Thanks @BBlack , these assessments are really useful! It would still be interesting how issue 3. (weird video request patterns as in T185350#3913932 ) and issue 4. (HTTP 200 requests for smaller files where the response size doesn't match the file size either) can be explained. But at this point it looks we can conclude with reasonable confidence that erroneous logging of the response_size field is not the cause.

Fri, Jan 26, 12:11 AM · Traffic, Operations, Analytics-Data-Quality

Thu, Jan 25

Tbayer added a comment to T185350: Vet reliability of the response_size field for data analysis purposes.

Interesting! So with a ratio in:out of approximately 25:1 (based on January's figures), this means that we could estimate the other direction to be around 80TB. So the total estimated in+out would be 2018+80 = 2098TB, compared to the actual (as received from LibreNMS) 2300TB, which is… 10% off. Not too bad!

The LibreNMS figure would include HTTP headers and, as Brandon points out, the TCP/IP and TLS overhead, right?

Thu, Jan 25, 9:15 PM · Traffic, Operations, Analytics-Data-Quality

Tue, Jan 23

Tbayer added a comment to T185350: Vet reliability of the response_size field for data analysis purposes.

Regarding 1.: We haven't yet heard back from @Milimetric about what the issue was back then, but after looking at the code that generated this data, my hunch is now that this may simply have referred to the fact that only some webrequests were counted for this response_size sum (e.g. only URLs of the form .../wiki/...).

Tue, Jan 23, 1:48 AM · Traffic, Operations, Analytics-Data-Quality
Tbayer added a comment to T185350: Vet reliability of the response_size field for data analysis purposes.

@Ottomata notes that the response_size field should correspond to the "Size of response in bytes, excluding HTTP headers" output from Varnish documented under %b at
https://varnish-cache.org/docs/4.0/reference/varnishncsa.html .

...and I understand the log formatting parameters documented there are referred to in this line of our logging code.
(E.g.: %b Size of response in bytes, excluding HTTP headers --> %{@response_size!num?0}b
and %m Request method --> %{@http_method}m )

Tue, Jan 23, 1:13 AM · Traffic, Operations, Analytics-Data-Quality
Tbayer added a comment to T185350: Vet reliability of the response_size field for data analysis purposes.

Same for November (ulsfo):

Tue, Jan 23, 12:34 AM · Traffic, Operations, Analytics-Data-Quality

Mon, Jan 22

Tbayer added a comment to T185350: Vet reliability of the response_size field for data analysis purposes.

@faidon: The ulsfo result for December is 2018 (decimal) terabytes. Plausible?

Mon, Jan 22, 10:58 PM · Traffic, Operations, Analytics-Data-Quality
Tbayer added a comment to T185350: Vet reliability of the response_size field for data analysis purposes.

OK, I just launched the below query for ulsfo - will report the result here once it has completed.

Mon, Jan 22, 10:05 PM · Traffic, Operations, Analytics-Data-Quality
Tbayer added a comment to T185350: Vet reliability of the response_size field for data analysis purposes.

In the meantime, I ran a query to estimate how much data was transferred in the download direction last month overall *if* the response_size field can be relied upon.
The answer is 6200 (decimal) Terabytes, with 25 kilobyte per request on average.

Mon, Jan 22, 8:06 PM · Traffic, Operations, Analytics-Data-Quality
Tbayer added a comment to T185350: Vet reliability of the response_size field for data analysis purposes.

@Ottomata notes that the response_size field should correspond to the "Size of response in bytes, excluding HTTP headers" output from Varnish documented under %b at
https://varnish-cache.org/docs/4.0/reference/varnishncsa.html .

Mon, Jan 22, 7:58 PM · Traffic, Operations, Analytics-Data-Quality
Tbayer added a comment to T185350: Vet reliability of the response_size field for data analysis purposes.

What is the argument for assuming that this data is correct?

The data for the pdf file transfer looks as you would expect if you had a transfer encoding that is initiated several times by the client. So the sizes noted on the response_size field were transmitted, they way that is done is client dependent. Thus my comment on "hard to interpret".

Sorry, I'm not sure I'm following. The transfer encoding is part of the header (e.g. Transfer-Encoding: chunked or Transfer-Encoding: gzip), so what does it mean that it is "initiated several times by the client"? Also, is the encoding set by the server or the client?

Mon, Jan 22, 4:25 PM · Traffic, Operations, Analytics-Data-Quality
Tbayer updated the task description for T185350: Vet reliability of the response_size field for data analysis purposes.
Mon, Jan 22, 3:54 PM · Traffic, Operations, Analytics-Data-Quality
Tbayer added a comment to T185350: Vet reliability of the response_size field for data analysis purposes.

...

it is likely that for media downloaded in chunks the field doesn't reflect file size, it should however reflect file size in files that are not downloaded in chuncks (everything but media pretty much)

Even if that is true (cf. below), not being able to count media downloads would be a big limitation for many data analysis questions (e.g. estimating our total download traffic in bytes).
Concretely, if we assume that all response_size data is correct, media requests from upload.wikimedia.org alone (i.e. ignoring media files on other domains) make up the vast majority of traffic already: 76% on January 19.[1]

Mon, Jan 22, 1:03 AM · Traffic, Operations, Analytics-Data-Quality

Sat, Jan 20

Tbayer added a comment to T185350: Vet reliability of the response_size field for data analysis purposes.

...

253193 bytes matches the gzipped size of this PDF, and 0 denotes empty "304 Not Modified"s responses. But I can't see how the API would produce a result with the other sizes for this request.

PS: In theory these could have come from HTTP 206 (partial) requests, but that wasn't the case here - apart from the empty ones, these were all normal HTTP 200 (apart from a single 504 gateway timeout).

Sat, Jan 20, 3:47 AM · Traffic, Operations, Analytics-Data-Quality