In T215664#4955259, @kostajh wrote:

Storing reading there seems OK but not great. We could consider a new property on the schema like impression_mode and set that to "edit" or "view". @nettrom_WMF do you have a preference?

@MMiller_WMF : We should document the questions we have around this variation, similarly as we did for search. I think at this point, my main interest is behaviour across namespaces, in other words: how do users who see the help panel in the Help & Wikipedia namespaces differ in behaviour from those who see it when editing? We'll be able to answer that because we track the page namespace. While it might be interesting to know if certain pages are more likely to lead to questions being asked, I suspect we might also learn about that from the questions that are asked? It could also be something we consider looking into if we start seeing questions flow in.

Apart from "recommendations work", I'm not sure which parts of SuggestBot are relevant :) Maybe that at we did attempt to simplify the process of getting suggestions for newcomers through WP:Teahouse/Suggestions. It's still complicated, though, partly because we were operating within the constraints of MediaWiki and SuggestBot's infrastructure.

In T213974#4938729, @kostajh wrote:

I assume you prefer to just have [obfuscated page title string] and not [obfuscated surrounding elements and page title string]. In other words, don't include the surrounding elements in the string that's going to be obfuscated, but purge them entirely. Is that right?

One potential way to find articles to recommend is to search for articles in given task categories. For example, on the English Wikipedia there is a category called All articles needing copy edit. You can pass that as a parameter to search to restrict articles to that category, e.g. find articles about electric guitars that need copy editing.

The first set of responses has been exported. Reassigning to @MMiller_WMF to follow up with the ambassadors.

There's now a draft up on mw.org. Handing it off to @MMiller_WMF for review.

@JAllemandou : Thanks for meeting up with me during All Hands to discuss this, and also giving me handy tips on working with the Data Lake, I really appreciated that! One thing we discussed was whether there is a need to support both blocks on IP ranges as well as single addresses. I looked into that and found that @TBolliger and I discussed it, and we're only interested in blocks of single IPs.

After much discussion, we are proposing to not store data for EditorJourney beyond 90 days. There is not currently a compelling use case that requires that we retain data.

While I'm closing this, I'll also thank @Neil_P._Quinn_WMF for pointing me to the right wikis, and for having the underlying data readily available, which made the work easy.

@MMiller_WMF : checked the data in the database, and from what I can tell it looks good to me.

Based on the data logged in the Data Lake, this is no longer a problem. There are very few events with editor_interface set to other, typically one or two, some days none at all.

Confirmed that the schema data in the Data Lake does not contain the page_token field. As far as I'm concerned, the schema development is now complete, so I'm reassigning to @MMiller_WMF so he can review/close as needed.

I defined "mobile edits" as edits made through both the mobile site and the apps (since the request mentions iOS), and used the canonical list of mobile-heavy wikis. I removed edits by users with a bot flag. Comparing Oct–Dec 2017 with Oct–Dec 2018, I get the following:

We have done our initial analysis and published our initial report. That completes this work, so I'm closing this.

This analysis has been done, and a short writeup of the results is now available. Our conclusion is that we do not see a significant difference in activation rate between users who get the survey, and users in the control group.

I gathered data from the Welcome survey from the Czech and Korean Wikipedias between 2018-11-19 and 2018-12-25, so as to use whole weeks and avoid dates where the spambot attack affected registrations. Here's what I found:

I verified that there is data flowing into the Data Lake also from Vietnamese Wikipedia, with 57 events currently recorded. Closing this ticket as this work is now completed.

I went ahead and deleted all tables starting with "nettrom_" except the four tables referenced in T190434#4085830.

I wrote many of the queries during testing, but also found that things don't necessarily translate easily between the MariaDB testing environment we have for EventLogging, and the Data Lake where the production data ends up. Something to note for future projects, while we wait for a fully functional staging environment.

We've QA'ed as much as we can, closing this for now.

I was working on another ad-hoc analysis case a couple of days ago where I needed information about when a specific abuse filter was in effect. This abuse filter is hidden, meaning I couldn't access its history on-wiki, but I have access to that information in the MW database. In this case, it was also a recently updated filter, meaning having access to up-to-date information was needed.

I ran a couple of queries of the EditorJourney data in the Data Lake, and there are no events there with user ID 0 that aren't log out events from before the fix was put in place. Neat to be able to verify that there wasn't a quality issue there, thanks for checking that @Etonkovidova ! And thanks @kostajh for identifying the fix!

@kostajh During my meeting with @MMiller_WMF today we discussed storing the HelpPanel data, and when I was walking through the schema I noticed that we do not have a session identifier that we can store (we have page_token and session_token in the schema, but those cannot be stored indefinitely). I would like to have an identifier that allows us to combine all interaction with the help panel that occurs during the same editing session, and that we can store for the duration of our Help Panel experiment. Looking at EditAttemptStep, I noticed that has an editing_session_id field. Could we add something like that to the HelpPanel schema? Might be possible to reuse it for all I know, I'll leave the implementation details to you.

Here's another use case that came up during the analysis of the survey results. I was asked if I could figure out what proportion of users who didn't supply an email address at registration added one in the survey.

I've discussed this with both the Product Analytics team as well as @MMiller_WMF and we've decided that the experiment with Variation C will depend on the outcome of our A/B test of Variation A, specifically how the survey affects editor activation rate (which is measured in T212799).

In T212172#4842701, @Neil_P._Quinn_WMF wrote:

In T212172#4840377, @Milimetric wrote:

First, I agree with @Nuria that ideally we would find one good solution for surveys and stick with it as a rule. EventLogging seems to work well for other surveys, would it work for you? If so, we could do a one-time import of all the relevant rows from user_properties into the schema.

The ultimate purpose of collecting this data is to personalize new users' experiences based on their background and interests (hence the name "personalized first day" 😁), so the data will need to be accessible to MediaWiki. That's why they're using user_properties rather than EventLogging.

During our check-in with @Nuria today, I briefly mentioned the current use case I have for getting data from MariaDB. Let me describe that use case and how it's connected to what the Growth Team is doing.

@aezell I'm using it within JupyterLab (on SWAP).

@kostajh : as far as I can see from looking up the Helpdesk pages in the data from the EditorJourney schema, we don't obfuscate those as they're in the Wikipedia namespace on both Czech and Korean? Or did I miss something?

I've created a GitHub repo where I'll put notebooks and graphs for analysis: https://github.com/nettrom/AHT-block-effectiveness-2018

After discussing this with @Neil_P._Quinn_WMF, we propose to remove the information that identifies what page the user was attempting to edit. I've updated the patch so that the page_id, page_title, and revision_id fields are deleted.

In T209982#4802085, @Catrope wrote:

That also reminds me: would it be a good idea to enable oversampling of EditAttemptStep events when the help panel is enabled? On the one hand, it seems useful to be able to cross-reference to that schema; on the other hand, I don't think that anything that's been requested requires that, and the increase in the number of events would be more substantial than that done by EditorJourney.