@Christine_Domgoergen_WMDE The campaign preliminary report, including all data from banner impressions, banner interactions, pageviews, user registrations, and user edits available until now:

@JAllemandou Fine.

@Christine_Domgoergen_WMDE Done: campaign spreadsheet.

• updated module crashed again: no type field vas received from the Wikidata API;
• fixing now.

@elukey All is fine, thank you very much!

@elukey Thank you, it worked.

@Christine_Domgoergen_WMDE A missing aggregate from the re-work of this report has caused this problem:

• freeze again; problem detected:
• MediaWiki API did not return one field (old_revid);
• action: potential bug fix, restart system, continue monitoring.

In the second last version of the report the numbers of impressions and closed-by in the tables 1.1.A and 1.2.1 A are different to the numbers in this last version (13500 vs. 67500).

@Lydia_Pintscher As of the English labels related problem (i.e. the dashboard reporting items without English labels while the same items do have English labels on Wikidata indeed), I was able to detect only cases where the label was created just very recently - and than it is natural that the dashboard reports an item revision but still can't find its label via the API.

• 18:59 CET bug fix - restarted the app.

The dashboard is live: http://datakolektiv.org:3838/WD_CurrentEvents/

• the dashboard is currently moving from prototype to 0.0.1
• it is "devirtualized" and will be run directly from a Shiny Server instance on the test server to
• enable for close monitoring of the possible failures (occasional "freezes" of the update cycle).

The daily reporting for this campaign is completed: spreadsheet.

@Christine_Domgoergen_WMDE @WMDE-leszek Here is the re-work of this campaign's final report:

@Christine_Domgoergen_WMDE @kai.nissen 87 registrations from this campaign thus far: daily update.

@Christine_Domgoergen_WMDE @kai.nissen Congrats, 38 user registrations from this campaign thus far... daily update.

As per your request in a recent e-mail:

The daily update is ready: we are still receiving user registrations while not observing any pageviews. Please check your campaign settings and advise because I am using the same code to track the pageviews as it was used in our previous campaigns - so I guess the problem is not in the analytics code. However, I think we better have everything checked. Thank you.

Please note that we are still not getting any pageviews data on the campaign pages as listed in T262534#6511503, while we are still getting user registrations from this campaign: daily report.

@Christine_Domgoergen_WMDE Oh I almost forgot about this one and I knew there was something unanswered:

As of the list of the pages that need to be tracked in this campaign - see T262534#6511503 - please take into your consideration the following:

We are still getting 14 different banners from the event.WMDEBannerInteractions schema, in contrast with six banners defined in the scope of this campaign.

@kai.nissen Please apply the fix then.

@kai.nissen Would that action result in six distinguishable banners as they were previously described in this ticket and as they are now found in the Banner Impressions tab (the wmf.webrequest data) of the campaign daily reporting spreadsheet?

Here is the campaign daily report: spreadsheet.

The daily reporting procedures for this campaign are on and I am running the first daily update right now.

User registration test (T262534#6504176) completed, found it:

The banner impressions test (T262534#6502096), testing exactly the following banners:

I assume the banner impressions will only be in the table once the campaign is up and running. Correct? Or is there any possibility to test this before?

@Christine_Domgoergen_WMDE @kai.nissen @WMDE-leszek A summary:

@Christine_Domgoergen_WMDE Disregard T262534#6501396, it's a page on https://www.wikimedia.de/ not wikipedia, Ok... so we will need the pageviews for the landing page measured in an alternative way - let me know which one will you choose and where will the data be served. Thanks.

@Christine_Domgoergen_WMDE As of T262534#6483268: from what I see the landing page is on https://de.wikipedia.org/ - so no offwiki pages in this campaign after all?

@Christine_Domgoergen_WMDE @kai.nissen Also, nothing is still found in event.WMDEBannerInteractions on these banners; testing postponed, we will wait for a few hours.

Well, nothing from the banners is currently found under /beacon/impression in the wmf.webrequest table, but I guess they were just recently put online so we will have to wait some time for the table to pick them up.

@Christine_Domgoergen_WMDE I am about to test the campaign banners now.

@Christine_Domgoergen_WMDE I think so, yes. I will make sure that it is done before the onset of the October 2020 campaign.

Yes that would be ideal, BUT: the landingpage is offwiki, so as I understand we cannot track page views from the wmf.webrequest table but have to rely on the banner clicks counted in the schema, even if it might be incorrect, this is our only possibility to track those. Correct?

@kai.nissen @Christine_Domgoergen_WMDE Are these the test banners for this campaign: T262670#6474604?

@Christine_Domgoergen_WMDE then finally, from T249617#6433362:

@Christine_Domgoergen_WMDE Please see: https://phabricator.wikimedia.org/T249617#6478906 which says:

(B) rely on the assumption that its seen_by field reports the banner impressions data correctly while its clicked_by field reports incorrect data.

• Wiktionary Cognate Dashboard now has a dedicated instance and runs from https://wiktionary-analytics.wmcloud.org/Wiktionary_CognateDashboard/
• All WDCM/Wikidata systems are containerized on a separate instance and running from https://wmdeanalytics.wmflabs.org/ as before; this web proxy will be changed to https://wikidata-analytocs.wmflabs.org
• Preparing a virtual instance for the New Editors team and migrating all campaign reports and other analytics for this team there.

2020/09/15 1:1 notes:

Here is the situation with the campaign data:

• Need to check one chart: Diversity of item re-use vs item quality - some changes following the introduction of optimized data production.

• Another bug fixed in respect to T259105#6436197;
• continuing monitoring & debugging.

• Another type of failure for the news module detected;
• fixing now.

@Addshore Following the introduction of Kerberos authentication, all Hive and Spark scripts needed for analytics in this case are run by analytics-privatedata. So there is no need for any Hive database for analytics-wmde user, I guess.

Let me know if extending the Pageviews per namespace from Wikidata dashboard for additional data feels like a possible way to solve for this one. The ticket is open since 2016.

@WMDE-leszek @Dydimusz Do we need anything else here?

Does our Wikidata Usage and Coverage in WMF Projects dashboard provide a solution for this? I think it does?

In focus until the end of 2020:

We will have further analytics requests within this project which I can specify on the 28th August after review with our ED. This again will have to be delivered within 2 weeks. We will take care to limit it to a few additional requests.

We can increase the limits for your current project to allow for 3 XL instances to support this.

That would be great, thank you. Would you like me to edit this ticket to match the format described on https://phabricator.wikimedia.org/project/profile/2880/? Please let me know.

• Gerrit repo requested.

Found three ways in which Q_CE_02-WDNews.R module - fetches news articles from NEWSRIVER.io - can fail;

• fixed all three;
• continuing to monitor.