@Christine_Domgoergen_WMDE The campaign preliminary report, including all data from banner impressions, banner interactions, pageviews, user registrations, and user edits available until now:
- updated module crashed again: no type field vas received from the Wikidata API;
- fixing now.
@elukey All is fine, thank you very much!
Mon, Oct 19
@elukey Thank you, it worked.
@Christine_Domgoergen_WMDE A missing aggregate from the re-work of this report has caused this problem:
Sun, Oct 18
- freeze again; problem detected:
- MediaWiki API did not return one field (old_revid);
- action: potential bug fix, restart system, continue monitoring.
Thu, Oct 15
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).
Wed, Oct 14
@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).
Mon, Oct 12
The daily reporting for this campaign is completed: spreadsheet.
Fri, Oct 9
Wed, Oct 7
Tue, Oct 6
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.
Mon, Oct 5
@Christine_Domgoergen_WMDE Oh I almost forgot about this one and I knew there was something unanswered:
Sun, Oct 4
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.
Fri, Oct 2
@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.
Wed, Sep 30
User registration test (T262534#6504176) completed, found it:
The banner impressions test (T262534#6502096), testing exactly the following banners:
Tue, Sep 29
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 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.
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.
Tue, Sep 22
@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?
Mon, Sep 21
(B) rely on the assumption that its seen_by field reports the banner impressions data correctly while its clicked_by field reports incorrect data.
Sep 16 2020
Sep 15 2020
- 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:
Sep 12 2020
Here is the situation with the campaign data:
Sep 10 2020
Sep 6 2020
- 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.
Sep 4 2020
- Another type of failure for the news module detected;
- fixing now.
Sep 3 2020
Sep 2 2020
@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.
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.