Thu, Mar 22
Tue, Mar 20
- Change the layout and the y-axis scale of the paulscore graph. Explorer's paulscore is statistically significantly higher!
- Deleted records with super large load time
@dcausse CTR was not impacted by ZRR. We removed all the zero-result searches when computing CTR.
I excluded data on 3/16 since there were very few records comparing to other days (only 6357 events).
Mon, Mar 19
Thu, Mar 15
Thanks @EBernhardson ! Don't worry about it. I can extract the data from searchsatisfaction on HDFS using R interface to Spark.
Mon, Mar 12
Sat, Mar 10
Fri, Mar 9
Thu, Mar 8
Thank you very much @dcausse !
Wed, Mar 7
If you click on the thumbnails, media viewer will open; if you click on the text, then the file page will open:
@mpopov I think it's ok because the EL used here is MobileWikiAppFeedConfigure which is sampled 100%. Uploaded the code for reference: https://github.com/wikimedia-research/App-Android-Baseline_Metrics/tree/master/T184093
But feel free to redo this if you want! :)
Good job @MNeisler !
@Abit If you go to your "Preference", click on the "Appearance" tab, under the "Files" section, you can enable media viewer. Also if you log out and do the search again, clicking on the thumbnails will open the media viewer. I think it's because media viewer is enabled by default for all Wikimedia sites (I tested on English Wikipedia too). But my experience was the same as you at first and I had to change my preference setting too. Maybe it's not the default setting for log-in users?
After discussing with @MNeisler today, we think it is very possible that after the change on Dec 14, users are more likely to find the multimedia files they are looking for and view the files on search result page via Media Viewer. So the clickthroughs to the file page drops. To verify this assumption, we will:
Tue, Mar 6
iOS monthly metrics for Feb 2018 is updated.
Fri, Mar 2
Thu, Mar 1
Wed, Feb 28
Tue, Feb 27
Thanks @EBernhardson ! We will see if the drop happened around that date.
Good job @MNeisler !
Mon, Feb 26
No objection from me, since I never do cross-wiki joins on Mysql. Plus, sqoop works great so far.
Fri, Feb 23
@Tbayer Could you provide some information about the metrics we could look at? Thanks! :D
Feb 21 2018
We found that sampling in MobileWikiAppSessions is not working as we expected, and there might be other data quality issues as well (see T186682 for more details). Move this ticket to stalled/waiting column.
Feb 20 2018
Thanks @mpopov for the review!
Feb 12 2018
Feb 9 2018
Having the per-country unique app stats in production would be very helpful for future work, given our annual planning put more focus on geographies and languages.
Thank you very much @Dbrant !
Feb 8 2018
@Charlotte, according to the breakdown tables above, some Android os/versions are over-represented and some are under-represented in our Eventlogging tables -- MobileWikiAppSessions and possibly others as well. This means the data we collected is not representative of the whole population of our users.
Feb 7 2018
Feb 6 2018
Great job @MNeisler !
Feb 3 2018
As of February 6 2018, only 26.87% of users who open the feed customization screen change the settings. Among them, 71.8% disabled at least one feed card, 39.84% change the order of cards, and 11.64% do both.
Feb 1 2018
@TJones Yes, all the metrics that require interaction with results only calculated on searches that actually got results, including CTR, first clicked position, max clicked position and Search Abandon Rate.
Link to previous discussion: https://etherpad.wikimedia.org/p/search-metrics