In T239672#5729650, @Nuria wrote:

@Neil_P._Quinn_WMF
Indeed it makes sense to include things such us Special:Book. Can you outline the set of pages that you think denote content consumption? (which is a different thing that pages such us Special:Version or "Special: pages that the user purposely navigates to", to my knowledge it was never the intent for those to be counted and were the cause of many spikes on the old pageview definition.

In T221566#5732913, @Iflorez wrote:

Thank you @Neil_P._Quinn_WMF
I'll take a look at #2 in the Data Issues section later today and will reach back with questions on the other data issues items.
I have some questions on the Data Styling portion. I'll dig into that tomorrow.

@Iflorez, sorry for the delay. Here's the full list of issues I've noticed.

I discussed this with @Pginer-WMF today, and we do want to prioritize this above other Language work. We are not currently doing any development work, but there will be more community conversations as Google expands Toledo to new languages, so we want this data to be publicly available.

@Nuria I don't understand the logic of whitelisting only those three special pages (Search, RecentChanges, and Version). The definition page of Meta says that "On the other hand, special pages that users purposefully navigate to, like Special:RecentChanges or Special:Version, are included." (I did write that line, back in 2016, but that was intended as better phrasing of what the page said before, that "automatically-called special pages are excluded").

The other thing I was wondering about was the December 2017 data. The monthly unique devices data is exactly identical to the June 2018 data, which shouldn't happen, and I'm wondering what's going on there.

@Iflorez, @cchen, we shouldn't call this done until we've updated the formatting to make all the sheets consistent (I suggest we follow the Jun 2018 sheet, which I spent a lot of time on!) and sent out an announcement to the interested departments (Product and the teams formerly known as Community Engagement). I'm happy to do that if you'd rather not :)

@mpopov, have you thought about the possibility of instead using "standard" Gerrit repos, which would get automatically mirrored to GitHub/wikimedia? I don't have much experience with this, but it seems like a good idea to use the standard set-up unless we have some strong reason for doing otherwise. That way, we can more easily get contributions from other Wikimedians and more easily apply our experience to contributing to other Wikimedia code (e.g. the analytics repos, instrumentation code).

I've finished this up; the data is in the same spreadsheet. I've highlighted some insights for Stephane and Angie in various meetings and emails; I was planning to summarize them here, but I don't think it's worth the time.

In T223339#5690873, @Alsee wrote:

There are a number of reasons why an edit init might not reach edit ready. However I cannot think of ANY scenario where it would be appropriate to penalize the quick-loading wikitext editor with an edit fail while discarding the data for a VE edit fail. Calculating edit completion rate using ready misleadingly inflates the success percentages for VE.
I am likely to cite this data at some point during community discussions. Some community members might not be inclined to grant the Foundation an assumption of good faith on this. Can someone please either fix the data to use init, or provide a really really good explanation why we shouldn't log a VE edit fail when a particularly slow VE load causes the user to quit on us?

In T221566#5687918, @Iflorez wrote:

Hi @Neil_P._Quinn_WMF, for clarity, can you rename the current "June 2018" tab in the Wiki Segmentation dataset? That sheet is locked for me.
Rename it to "0717–0618_OLD" or "0717–0618_BROKEN" ?
Also, I think it will be wise to change the color of the mobile edits [column p] on this sheet, to reflect the same rosy color used on the administrator's tab. This because the measure definition (the bot identifying and filtering that goes into the query) has been updated.

In T238971#5691517, @ppelberg wrote:

We are aligned in wanting to make sure the interventions do not promote vandalistic comments.

In T221566#5685146, @Iflorez wrote:

However, we'll probably have to think about how we'll handle changing definitions. For example, if we redefine active editors in a couple years, will we will put two active editors entries in the definition tab, with some method of explaining which applies to which tab?

That sounds reasonable.

In T221566#5685146, @Iflorez wrote:

I like the idea of producing snapshots for every calendar year from now on; since we tend do our annual planning in the Feb-May timeframe, that means we'd have recent data available for those planning cycles.

By calendar year, do you mean January - December?

@Iflorez, @cchen let me know if you need anything else from me.

@SBisson I think we're planning to use this same schema for KaiOS app events too; if so, we should probably change the os field to something like`platform` and have kaios-web and kaios-app as possible values.

Thinking about sections made me think of another thing: our operating system filter will still catch Android and iOS tablets where the sections are big enough to be opened by default. The experience on these devices isn't really relevant to KaiOS, so I feel like we should use a screen-size filter to limit our data collection to phones only. @AMuigai, @SBisson what do you think?

@SBisson is currently implementing this in T238029.

In T238029#5682200, @SBisson wrote:

I've added section_count and opened_section_count. It's a unique count. I think it tells us more about the "depth" of their interaction with the page.

Thank you for the quick responses, @SBisson!

Now that I've added the wiki names to the dataset, along with some other fixes, (commit 817dc0d), this is all finished.

@SBisson I looked over the patch and the schema and I have a number of changes to suggest:

• My intention for the time_on_page field was to know the amount of time the user had the page visible/focused, but currently it just gives the absolute amount of time from page load to page unload. If it's feasible to track visibility time, could we add that as page_visible_time (and maybe rename time_on_page to page_open_time)?
• I just saw your comment about sections being open by default on mobile web; on Chrome for Android, I see them closed by default. Were you using the mobile website on a desktop browser? I think that when the screen size is tablet-size or higher, sections are opened by default, so they'd be closed by default for KaiOS devices. If that's the case, perhaps we can add a field like section_open_count which tracks the number of sections opened (ideally we'd track first time opens/unique section opens only, but it's fine if it's just a raw count with multiple opens of the same section included). This would also require a count of the number of sections on the page to contextualize.
• The dt field that's recorded by default will give the time that the event is received by the EventLogging server. Since we'll be holding events until the page unload, we should have a client_dt or load_dt field that gives the actual time the page was loaded so we can do our sessionizing accurately.
• The schema in its current form won't explicitly tell us if the user is on Special:Search. The fact that the page namespace will be -1 will be a strong signal, but is there any reason not to include an is_search_page variable?

I too am requesting Kerberos credentials for the stat and notebook machines. My username is neilpquinn-wmf.

This isn't urgent, but we should still do it in the next month or so.

The current draft dashboard is available at https://analytics.wikimedia.org/published/notebooks/WMF-Language/key-metrics.html (code at . Some notes:

1. The new/experienced user classification is incorrect, producing a false decline in translations by new users (T237788).
2. The dashboard currently needs to be manually updated and depends on the monthly mediawiki_history snapshots, so even if it were automatically updated it would only should new data once per month.

This turned out to be due to a change in our retention of ServerSideAccountCreation data (T238283), not any real decline in new user translation.

@Iflorez and @cchen ran into some issues using this data from the wiki segmentation (T221566). So this week, I'm going to work on updating the dataset to:

1. Remove deleted wikis, which will require basing this on something other than than the MediaWiki sites table.
2. Include the full wiki name

In T234046#5669844, @Alsee wrote:

I edited the wikipage item for "Junior Contributors" to add a criteria of "at least one article page edit". You may want to revise this to "at least one article page edit that has not been reverted".
The history of the Article Feedback Tool should make it clear that talk-comments with zero-article-edits is not considered contribution. Chatter by non-editors has negative value on average.
I strongly suggest that the team add a separate metric to track talk-comments-with-zero-article-edits. I expect many or comments like that would be as IP. The team should track the percentage IPs that comment on talk without article-editing.
See the research finding that Wikia's attempt to deploy an easier talk system resulted in decreased article contributions by new users. The community would consider that very bad. If the new interface were to negatively impact our inflow of new users successfully joining us as active article editors, I expect the community would seek to modify or disable the interface to protect the ongoing health and successes of the project. If the new interface were to increase commenting by non-editors, without a compelling increase in article-contributors, I expect the community would seek to modify or disable the interface due to the costs and disruption of non-editors.

I'm now mostly finished; I've put a bunch of data into this spreadsheet [WMF only], which now contains:

• Pageviews and unique devices by country
• Indian pageviews by state
• Top user agents
• Top viewed pages in India
• Top viewed projects in India
• Referrer types in India
• Top referring sites in India

Assigning to remind you!

@kzimmerman send me the photos of our sticky notes 😁

Stats about Firefox OS pageviews by Indian state are done and in this spreadsheet [WMF only]). I still need to rerun those numbers, limited to Wikipedias only.

In T235494#5620618, @Ottomata wrote:

Must be because I get a dir listing! :)

In T235494#5620453, @Ottomata wrote:

https://analytics.wikimedia.org/published-datasets/ was never a URL, it was always https://analytics.wikimedia.org/datasets/

Currently, https://analytics.wikimedia.org/published-datasets/ is returning 404. Any idea what's going on?

@Ottomata thank you! This looks like a great plan 😁

In T212367#5615061, @Ottomata wrote:

Looks good! Since Growth doesn't want the data anymore

Ha, oh ok.

In T159170#5613776, @Ottomata wrote:

I've backfilled the last 90 days of data for ChangesListHighlights from MySQL. This schema doesn't have any whitelist defined, so that should be all we got! Now that ChangesListHighlights is in Hive, assuming that it does not block this task.

@nettrom_WMF/@Catrope, something for the two of you? 😁

Looks good! Since Growth doesn't want the data anymore, I filed T236770: Retire the ChangesListHighlights data stream, which we can deal with separately.

In T212355#5613779, @Ottomata wrote:

@Neil_P._Quinn_WMF, now that T212367 is unblacklisted, can we close this (and that) task?

The ChangesListHighlights schema is still active (1,221 events in the past week), but is still blacklisted from Hive refinement (T212367).