@Christine_Domgoergen_WMDE

Hey, I am missing the assets required for this banner. Could you upload the 4 different resolutions of the "wikipedia community" image to Wikimedia Commons and link them in this ticket?

Last year, the following files were used but the image colors have changed so I cannot use these again (they appear black in the following links in some browsers, just click on the black image again to see the colors):

https://commons.wikimedia.org/wiki/File:1200-asset-vorort.svg
https://commons.wikimedia.org/wiki/File:900-asset-vorort.svg
https://commons.wikimedia.org/wiki/File:600-asset-vorort.svg
https://commons.wikimedia.org/wiki/File:320-asset-vorort.svg

The images should be SVG just like the old ones.

--Tim

Hi @Tim_WMDE, I asked the agency to provide the images and will link them here as soon as I get them...

@Tim_WMDE
Hi Tim,
here are the images:
https://commons.wikimedia.org/wiki/File:320-Wiki-Banner-Asset-Vorort.svg
https://commons.wikimedia.org/wiki/File:600-Wiki-Banner-Asset-Vorort.svg
https://commons.wikimedia.org/wiki/File:1200-Wiki-Banner-Asset-Vorort.svg
https://commons.wikimedia.org/wiki/File:900-Wiki-Banner-Asset-Vorort.svg

@Christine_Domgoergen_WMDE You can test the banner at this address now:

Desktop:
https://de.wikipedia.org/?banner=B19WMDE_neweditors_autumn_2019_lp1

Mobile:
https://de.m.wikipedia.org/?banner=B19WMDE_neweditors_autumn_2019_lp1m

I just realized that since this banner is shown for more than DE Wiki and since we do not want people to move from the mobile Wikipedia to the desktop one by clicking on the banner, I separated the banner into a mobile and desktop one.

@Tim_WMDE @Christine_Domgoergen_WMDE

I have tested the following

https://de.wikipedia.org/?banner=B19WMDE_neweditors_autumn_2019_lp1

approx. one hour ago: opend the page, closed the banner, opened the page, clicked the banner, opened again, clicked again.

However, I still cannot find any data on this test banner impressions from the /beacon/impression uri_path of the webrequest table.

I will repeat the query on the webrequest table later and report back.

Update, 14:08 CET: still no data on banner impressions.

We don't really have any code for that in place, right now I assume that CentralNotice will only count impression data for campaigns that are actually active which this one is not. The banner does not fundamentally differ from our other banners, so I assume this will all just magically start working once it's live. Maybe @Addshore knows more / thinks I am wrong with this assessment.

The EventLogging things we have added in also will not work until at least Thursday because that's when they will be deployed to production.

@Tim_WMDE Ok, makes sense. @Christine_Domgoergen_WMDE Than it does not make sense for us to meet today to test the campaign.

@GoranSMilovanovic @Tim_WMDE

Okay. I am confused, because last time we did a successful tracking test before Central Notice was live. Was last year's tracking test only about registrations or could you see impression data as well?

I created a test account (Test Banner Autumn 2019 01) to see if we can at least see if the tracking of the registrations works?

Edit: I found the Phabricator Task from the testing of the thank you banner in 2018 and it seems we could see page views and user registrations: https://phabricator.wikimedia.org/T210832

Hi @Christine_Domgoergen_WMDE

could you please let us know exactly which tag did you use for your test user registration from the following:

campaign tags
There will be banners on mobile and desktop as well as flyers (offline) and a newsletter.

banner: ?campaign=WMDE_neweditors_autumn_2019_bnr
newsletter - link 1: ?campaign=WMDE_neweditors_autumn_2019_nl_lp1
newsletter - link 2: ?campaign=WMDE_neweditors_autumn_2019_nl_lp2
flyer: ?campaign=WMDE_neweditors_autumn_2019_flyer

(taken from T236392 where the campaign tags are defined)?

The test code is in place (including user registration tests, pageviews tests, and banner impression tests) and we just need to know exactly what tag we are looking for.

The one you have provided in T235845#5615896:

I created a test account (Test Banner Autumn 2019 01)

does not seem to match any of the campaign tags mentioned before.

Thank you!

@GoranSMilovanovic I used the first tag ?campaign=WMDE_neweditors_autumn_2019_bnr, coming from the test banner. This "(Test Banner Autumn 2019 01)" is no campaign tag but the name of the test account.

@Christine_Domgoergen_WMDE

Found it:

2019    10  29   16    WMDE_neweditors_autumn_2019_bnr 3328487 Test Banner Autumn 2019 01

@GoranSMilovanovic great! Two questions:

1. Should I create accounts for the other tags as well, to check if they also work?
2. And could you solve the question of the page views?

@GoranSMilovanovic Hi Goran, here are the other test accounts:

https://de.wikipedia.org/wiki/Wikipedia:Wikipedia_vor_Ort?campaign=WMDE_neweditors_autumn_2019_nl_lp1 - Test Account: Test Banner Autumn 2019 nl lp1
https://de.wikipedia.org/wiki/Wikipedia:Wikimedia_Deutschland/LerneWikipedia?campaign=WMDE_neweditors_autumn_2019_nl_lp2 - Test Account: Test Banner Autumn 2019 nl lp2
https://de.wikipedia.org/wiki/Wikipedia:Wikipedia_vor_Ort?campaign=WMDE_neweditors_autumn_2019_flyer - Test Account: Test Banner Autumn 2019 flyer

@Christine_Domgoergen_WMDE Unfortunately, I can't find any of the test users mentioned in T235845#5618859 registered (tested at approx. 14:55 CET).

@GoranSMilovanovic @Tim_WMDE Okay, how can we find out why the data is not (found) in the database? Who can investigate and how?

@Christine_Domgoergen_WMDE

Once again, I can only read what is already in our databases, and cannot write a single thing there. So I am afraid that I cannot tell why the data are not present when they are not present.
However, I will double check the user registrations data.

In the meantime, I have tested the pageviews:

"","Tag","Page","Pageviews","date","campaign"
"1","WMDE_neweditors_autumn_2019_bnr","/wiki/Wikipedia:Wikimedia_Deutschland/LerneWikipedia",4,"2019-10-29","ABC2019"
"2","WMDE_neweditors_autumn_2019_bnr","/wiki/Wikipedia:Wikipedia_vor_Ort",11,"2019-10-29","ABC2019"
"3","WMDE_neweditors_autumn_2019_flyer","/wiki/Wikipedia:Augsburg/Aktionstag_Wikipedia_2019",1,"2019-10-29","ABC2019"
"4","WMDE_neweditors_autumn_2019_flyer","/wiki/Wikipedia:Hannover/Aktionstag_Wikipedia_2019",1,"2019-10-29","ABC2019"
"5","WMDE_neweditors_autumn_2019_flyer","/wiki/Wikipedia:K%C3%B6ln/Aktionstag_Wikipedia_2019",3,"2019-10-29","ABC2019"
"6","WMDE_neweditors_autumn_2019_flyer","/wiki/Wikipedia:Kontor_Hamburg/Aktionstag_2019",2,"2019-10-29","ABC2019"
"7","WMDE_neweditors_autumn_2019_flyer","/wiki/Wikipedia:Ober%C3%B6sterreich/Wikipedia_vor_Ort_2019",1,"2019-10-29","ABC2019"
"8","WMDE_neweditors_autumn_2019_flyer","/wiki/Wikipedia:Ruhrgebiet/Wikipedia_vor_Ort_2019",2,"2019-10-29","ABC2019"
"9","WMDE_neweditors_autumn_2019_flyer","/wiki/Wikipedia:Wien/Wikipedia_vor_Ort_2019",1,"2019-10-29","ABC2019"
"10","WMDE_neweditors_autumn_2019_flyer","/wiki/Wikipedia:Wikipedia_vor_Ort",17,"2019-10-29","ABC2019"
"11","WMDE_neweditors_autumn_2019_nl_lp1","/wiki/Wikipedia:Augsburg/Aktionstag_Wikipedia_2019",22,"2019-10-29","ABC2019"
"12","WMDE_neweditors_autumn_2019_nl_lp1","/wiki/Wikipedia:Bodensee/Wikipedia_vor_Ort_2019",4,"2019-10-29","ABC2019"
"13","WMDE_neweditors_autumn_2019_nl_lp1","/wiki/Wikipedia:Frankfurt/Wikipedia_vor_Ort_2019",89,"2019-10-29","ABC2019"
"14","WMDE_neweditors_autumn_2019_nl_lp1","/wiki/Wikipedia:Freiburg_im_Breisgau/Wikipedia_vor_Ort_2019",40,"2019-10-29","ABC2019"
"15","WMDE_neweditors_autumn_2019_nl_lp1","/wiki/Wikipedia:Hannover/Aktionstag_Wikipedia_2019",46,"2019-10-29","ABC2019"
"16","WMDE_neweditors_autumn_2019_nl_lp1","/wiki/Wikipedia:K%C3%B6ln/Aktionstag_Wikipedia_2019",49,"2019-10-29","ABC2019"
"17","WMDE_neweditors_autumn_2019_nl_lp1","/wiki/Wikipedia:Kontor_Hamburg/Aktionstag_2019",62,"2019-10-29","ABC2019"
"18","WMDE_neweditors_autumn_2019_nl_lp1","/wiki/Wikipedia:L%C3%B6rrach/Aktionstag_Wikipedia_2019",6,"2019-10-29","ABC2019"
"19","WMDE_neweditors_autumn_2019_nl_lp1","/wiki/Wikipedia:Ruhrgebiet/Wikipedia_vor_Ort_2019",32,"2019-10-29","ABC2019"
"20","WMDE_neweditors_autumn_2019_nl_lp1","/wiki/Wikipedia:Wien/Wikipedia_vor_Ort_2019",2,"2019-10-29","ABC2019"
"21","WMDE_neweditors_autumn_2019_nl_lp1","/wiki/Wikipedia:WikiB%C3%A4r/Aktionstag_Wikipedia_2019",68,"2019-10-29","ABC2019"
"22","WMDE_neweditors_autumn_2019_nl_lp1","/wiki/Wikipedia:Wikimedia_Deutschland/LerneWikipedia",10,"2019-10-29","ABC2019"
"23","WMDE_neweditors_autumn_2019_nl_lp1","/wiki/Wikipedia:WikiMUC/2019-11-10_Wikipedia_vor_Ort",68,"2019-10-29","ABC2019"
"24","WMDE_neweditors_autumn_2019_nl_lp1","/wiki/Wikipedia:Wikipedia_vor_Ort",1050,"2019-10-29","ABC2019"
"25","WMDE_neweditors_autumn_2019_nl_lp1","/wiki/Wikipedia:WikiWedding/Wikipedia_vor_Ort_2019",58,"2019-10-29","ABC2019"
"26","WMDE_neweditors_autumn_2019_nl_lp2","/wiki/Wikipedia:Wikimedia_Deutschland/LerneWikipedia",34,"2019-10-29","ABC2019"

So it seems that we do get to see the pageviews data quite nicely.

@Christine_Domgoergen_WMDE In the meantime, you will most probably enjoy to learn that I've found all the test user registrations in the respective databaseL

Test Banner Autumn 2019 01
Test Banner Autumn 2019 nl lp1
Test Banner Autumn 2019 flyer
Test Banner Autumn 2019 nl lp2

So it must be that it takes a bit more time for the system to log the registrations now when everything is in our Big Data storage.
Anyways: the user registrations work.

Now let's see what can be done with this banner impressions.
@Addshore has provided an independent test and confirmed to @Tim_WMDE and me that the banner impressions from our test banner do not hit the /beacon/impression path in webrequest at all.

@Christine_Domgoergen_WMDE We have just looked into this very extensively and we think this will just start working once the banners go live. We have temporarily turned the campaign on on a dead wiki so that Goran can test this tomorrow. However, since we have not really changed anything in the code and this has never been a problem, I strongly assume everything will be fine on go-live.

@Christine_Domgoergen_WMDE @Tim_WMDE @Addshore

Testing will commence tomorrow morning from the centralnoticeimpression schema in the event Hadoop database:

• the test banner has been successfully tracked by @Addshore in the Central Notice processing pipeline;
• the test was conducted on the aawiki wiki;
• the data are still not found in the centralnoticeimpression table; moreover, there are no data in that table for anything on Oct 30 2019.

So we wait until tomorrow and then try to find our banner impressions there.

@GoranSMilovanovic @Tim_WMDE @Addshore Great about page views and user registrations! Thanks for investigating into the banner impressions.

@Christine_Domgoergen_WMDE @Tim_WMDE @Addshore

The test banner impression produced yesterday (October 30, 2019) on aawiki is not found in our databases; from stat1004, use event;, then:

select event from centralnoticeimpression where year=2019 and month=10 and day=30 and wiki='aawiki';

returns 0 rows; moreover,

select event from centralnoticeimpression where year=2019 and month=10 and day=30;

also returns 0 rows.

Analytics Is there something that we do not know or understand about event.centralnoticeimpression?

@GoranSMilovanovic @Tim_WMDE @Addshore
Okay, thank you for checking Goran. How could this be solved, do you have any idea @Tim_WMDE @Addshore ?

@Addshore Could you please share the beacon path in wmf.webrequest where you saw the test banner impression previously? Thanks.

In T235845#5623174, @GoranSMilovanovic wrote:

@Addshore Could you please share the beacon path in wmf.webrequest where you saw the test banner impression previously? Thanks.

It is /beacon/event

https://github.com/wikimedia/operations-mediawiki-config/blob/dafb66538fd955f487358c5b67114c4180ba1b23/wmf-config/CommonSettings.php#L3254

But we probably don't want to read data from that / from webrequest as it would be a much bigger query than getting it from the event logging table.

@Addshore Many thanks.

Those queries are correct. It looks like there's either a very long delay before the impressions make it to Hadoop, or something is terribly wrong:

select day, count(*) from event.centralnoticeimpression where year=2019 and month=10 group by day order by day limit 100;

day     _c1
1       817243
2       685482
3       484943
4       190083
5       185017
6       214520
7       194657
8       156987
9       320377
10      155087
11      147680
12      152987
13      177927
14      167010
15      170665
16      326759
17      314734
18      136418
19      216551
20      163496
21      151462
22      176093
23      307527
24      61827
25      711
26      325
27      177
28      141
29      58

Pinging more people who might know what's happening with this pipeline: @AndyRussG @EYener @jkumalah

@awight Thanks for pointing this out.

@AndyRussG Sorry to spam you, but I noticed that 6db58dee755aed4d95407020109e0c6c3f852a7d would have been deployed with the train last week, on the 24th. Exactly the day we see the drop in impressions...

FWIW, the campaign we're looking at was set to show only on aawiki at 100%, with 100% impression sampling. No URL parameters were passed. I saw the eventlogging beacon request sent from my browser... so it's weird that a CentralNotice change could have had any impact on whether this impression would land in EL! *ah* is it possibly an invalid schema?

Here's the request I captured yesterday:
https://aa.wikipedia.org/beacon/event?%7B%22event%22%3A%7B%22country%22%3A%22DE%22%2C%22region%22%3A%22BE%22%2C%22anonymous%22%3Atrue%2C%22project%22%3A%22wikipedia%22%2C%22db%22%3A%22aawiki%22%2C%22uselang%22%3A%22aa%22%2C%22device%22%3A%22desktop%22%2C%22debug%22%3Afalse%2C%22randomcampaign%22%3A0.20957917015163774%2C%22randombanner%22%3A0.24794050711291515%2C%22recordImpressionSampleRate%22%3A0.01%2C%22impressionEventSampleRate%22%3A1%2C%22campaignStatuses%22%3A%22%5B%7B%5C%22statusCode%5C%22%3A%5C%226%5C%22%2C%5C%22campaign%5C%22%3A%5C%22WMDE_Authors_Campaign_2019_Germany%5C%22%2C%5C%22bannersCount%5C%22%3A2%7D%5D%22%2C%22status%22%3A%22banner_shown%22%2C%22statusCode%22%3A%226%22%2C%22campaign%22%3A%22WMDE_Authors_Campaign_2019_Germany%22%2C%22campaignCategory%22%3A%22WMDE_Authors_Campaign_2019_Germany%22%2C%22campaignCategoryUsesLegacy%22%3Afalse%2C%22bucket%22%3A0%2C%22banner%22%3A%22B19WMDE_neweditors_autumn_2019_lp1%22%2C%22bannerCategory%22%3A%22WMDE_Authors_Campaign_2019_Germany%22%2C%22result%22%3A%22show%22%7D%2C%22revision%22%3A19108542%2C%22schema%22%3A%22CentralNoticeImpression%22%2C%22webHost%22%3A%22aa.wikipedia.org%22%2C%22wiki%22%3A%22aawiki%22%7D

Is it possible whatever sends these events has stopped sending them? I don't see any errors and the throughput in Kafka for this topic has dropped to 0:

https://grafana.wikimedia.org/d/000000018/eventlogging-schema?orgId=1&var-schema=CentralNoticeImpression&from=1569938432122&to=1572530432122

In T235845#5623288, @Ottomata wrote:

Is it possible whatever sends these events has stopped sending them? I don't see any errors and the throughput in Kafka for this topic has dropped to 0:

https://grafana.wikimedia.org/d/000000018/eventlogging-schema?orgId=1&var-schema=CentralNoticeImpression&from=1569938432122&to=1572530432122

I saw an event hit the /beacon/event endpoint yesterday correctly, and end up in kafka and with all the other webrequests, so sounds like something between the webrequest beacon and the eventlogging table to me?

Running against a local eventlogging server, I see,

Error: Additional properties are not allowed ('campaignStatuses' was unexpected)

This field isn't present in even the latest version of https://meta.wikimedia.org/wiki/Schema:CentralNoticeImpression , maybe it was introduced in code accidentally?

Related is T236627: CentralNotice: Adapt impression event schema for campaign fallback and T236285: CentralNotice: Adapt banner history for campaign fallback

Thanks so much for flagging this, and many apologies for the noise!! There's now a patch in review for T236627: CentralNotice: Adapt impression event schema for campaign fallback.

(Note that there shouldn't be any similar issues for banner history, T236285, since the data being sent on the event has not yet changed.)

Great, thank you everyone! @GoranSMilovanovic Can you now get the impression data or do you need anything else?

May I take this moment to say... This is a problem with the existent EventLogging system that Modern Event Platform aims to solve. Schemas will be versioned in the same way that code is (in git) and will be decentralized. EventLogging's centralized on-meta-wiki schemas means that devs have to make changes to the production schemas WHILE developing their code, crazy! :) :)

In T235845#5623892, @Christine_Domgoergen_WMDE wrote:

Great, thank you everyone! @GoranSMilovanovic Can you now get the impression data or do you need anything else?

The (very minor) change to CentralNotice still needs to be approved and deployed to production. I can get back to you a bit later about when we could do that... hopefully today... Thanks for your patience!!

Okay, thank you for the information and for fixing this!

@Tim_WMDE @GoranSMilovanovic Is this or should this in some form prevent us from starting the campaign tomorrow 10am as planned?

Scheduled to deploy in a few minutes...

Okay, great, thank you for the update! @GoranSMilovanovic @Tim_WMDE Does it work now?

In T235845#5625873, @Christine_Domgoergen_WMDE wrote:

Okay, great, thank you for the update! @GoranSMilovanovic @Tim_WMDE Does it work now?

Just to note, because of a wee mistake of mine, a working version wasn't deployed until around 23:30 UTC yesterday. I was able to verify on the Analytics cluster that valid CentralNotice impression events were being sent to the corresponding Kafka stream. Please don't hesitate to reach out if there are any issues Thanks much :)

I've tested the campaign banner impressions today, and they are found on the beacon/impression path, test day: November 01, 2019:

banner                              impressions date      campaign
B19WMDE_neweditors_autumn_2019_lp1      3575086 2019-11-1 ABC2019
B19WMDE_neweditors_autumn_2019_lp1m     7359700 2019-11-1 ABC2019

Unfortunately, I could not find anything in the event.centralnoticeimpression table, query:

SELECT event.anonymous, event.device, event.country, event.region, event.recordimpressionsamplerate,
event.impressioneventsamplerate, event.campaign, year, month, day, hour 
FROM event.centralnoticeimpression
WHERE year=2019 AND month=11 AND day=1;

results in:

anonymous       device  country region  recordimpressionsamplerate      impressioneventsamplerate       campaign        year    month   day     hour
NULL    NULL    NULL    NULL    NULL    NULL    NULL    2019    11      1       0
NULL    NULL    NULL    NULL    NULL    NULL    NULL    2019    11      1       1
NULL    NULL    NULL    NULL    NULL    NULL    NULL    2019    11      1       10
NULL    NULL    NULL    NULL    NULL    NULL    NULL    2019    11      1       11
NULL    NULL    NULL    NULL    NULL    NULL    NULL    2019    11      1       12
NULL    NULL    NULL    NULL    NULL    NULL    NULL    2019    11      1       13
NULL    NULL    NULL    NULL    NULL    NULL    NULL    2019    11      1       14
NULL    NULL    NULL    NULL    NULL    NULL    NULL    2019    11      1       15
NULL    NULL    NULL    NULL    NULL    NULL    NULL    2019    11      1       16
NULL    NULL    NULL    NULL    NULL    NULL    NULL    2019    11      1       17
NULL    NULL    NULL    NULL    NULL    NULL    NULL    2019    11      1       18
NULL    NULL    NULL    NULL    NULL    NULL    NULL    2019    11      1       19
NULL    NULL    NULL    NULL    NULL    NULL    NULL    2019    11      1       2
NULL    NULL    NULL    NULL    NULL    NULL    NULL    2019    11      1       20
NULL    NULL    NULL    NULL    NULL    NULL    NULL    2019    11      1       21
NULL    NULL    NULL    NULL    NULL    NULL    NULL    2019    11      1       22
NULL    NULL    NULL    NULL    NULL    NULL    NULL    2019    11      1       23
NULL    NULL    NULL    NULL    NULL    NULL    NULL    2019    11      1       3
NULL    NULL    NULL    NULL    NULL    NULL    NULL    2019    11      1       4
NULL    NULL    NULL    NULL    NULL    NULL    NULL    2019    11      1       5
NULL    NULL    NULL    NULL    NULL    NULL    NULL    2019    11      1       6
NULL    NULL    NULL    NULL    NULL    NULL    NULL    2019    11      1       7
NULL    NULL    NULL    NULL    NULL    NULL    NULL    2019    11      1       8
NULL    NULL    NULL    NULL    NULL    NULL    NULL    2019    11      1       9

So, I will be tracking the banner impressions from this campaign through beacon/impression, as it was done in all our previous campaigns.

@Christine_Domgoergen_WMDE Just to confirm, this means we have the pageviews data, the banner impressions data, and the user registrations data all tested. Reporting will continue on daily basis in T235839. The final report will be delivered as soon as the campaign ends.

@GoranSMilovanovic I can confirm what you're seeing in event.centralnoticeimpression, that data looks corrupt and I have no idea why.

I'm concerned that beacon/impression is also unreliable for the campaign you're looking at, however. From the code responsible for sending either a beacon or an EventLogging message, your campaign should not be sending anything to beacon/impression unless the "legacy hiding and banner impression support" feature is enabled for the campaign, and it is disabled. Maybe this is related to the bug causing corrupt EL data, so when it's fixed you will lose the legacy data.

One option would be to enable legacy banner impressions for that campaign, and hope for the best?

Another unrelated detail worth some investigation is that we're getting a lot of schema validation errors for the WMDEBannerInteractions EventLogging schema, probably a simple fix: https://logstash.wikimedia.org/goto/f546fc987d4419544b061f7810875564

@awight Thank you for your assessment of the problem.

I'm concerned that beacon/impression is also unreliable for the campaign you're looking at, however.

Could you please explain, without making references to any code, in what sense the data obtained from the beacon/impression path would be unreliable for this campaign, please?
I do get the data for the campaign banners as defined for this campaign from there. Now, the question: what is unreliable: the numbers themselves? The banner impressions are accidentally found there? How do the banner impression data show up there at all if the feature to send them there is switched off? Please elaborate. Thanks a lot.

Maybe this is related to the bug causing corrupt EL data, so when it's fixed you will lose the legacy data.

I am not sure if I understand this: what data exactly will we lose and why? When will we lose the data - the webrequest data are purged after 90 days (I think)?

Thanks again.

@Christine_Domgoergen_WMDE As of tomorrow, the pageviews and user registrations data will be reported on daily basis in T235839, starting from November 1, 2019, and the banner impression data will be reported once this issue is resolved.
I will keep on collecting the banner impression data from the standard beacon/impression path. If it turns out the data are corrupted - in whatever sense, I am waiting to learn what that means exactly in this context - well, we will have to rely on some other data source for the banner impressions then. Let's wait and see which one.

In T235845#5629761, @GoranSMilovanovic wrote:

I'm concerned that beacon/impression is also unreliable for the campaign you're looking at, however.

Could you please explain, without making references to any code, in what sense the data obtained from the beacon/impression path would be unreliable for this campaign, please?

Good point, my "Sunday opinion" was quite breezy, in fact I see that it was wrong. Even when the "legacy" feature is disabled for a campaign, we still record impressions to the beacon/impression path at a default 1% sample rate. I'm hoping @AndyRussG can confirm or deny this :-) If this true, then we can rely on the legacy impression counts, and we should leave the legacy feature disabled for WMDE campaigns (disclaimer: unless our banners include Javascript to hide the banner explicitly, circumventing CentralNotice "impression diet" features—but we never do this?).

Apologies for the FUD!

Just one more sanity check: maybe @DStrine can share whether default, legacy impression counting is slated for deprecation any time this or next year?

@awight Thank you!

@GoranSMilovanovic Some last notes from a conversation with @AndyRussG: WMF is still using the beacon/impression numbers, so we can rely on them for this year's campaign.

As for the new eventlogging stream, they're consuming the events directly from Kafka. Pulling this data from Hive is currently unsupported, it might sometimes work but they don't have anyone monitoring or assigned to keep it working. All this to say, your earlier conclusions are solid and we should continue using the old metrics for the time being.

@awight Thank you for helping to sort this out. Then we wait until the new eventlogging is ready and use the beacon/impression path in webrequest until then. We've learned something.