I think it's blocking on the URL path /beacon/event. See https://easylist.to/easylist/easyprivacy.txt and T220627#5638168.

Just to note, we have the same problem for the new CentralNotice data pipeline, which uses EventLogging, as compared to the old pipeline, which uses a custom call to beacon/impression not blocked by AdBlock. In case it's useful: see T236834#5696044 (and the two comments after that).

In T236835#5682487, @Isaac wrote:

I'm not sure if this is at all pertinent, but we spent some time trying to debug a situation where we were missing about 10% of EventLogging data from people taking a survey served via the QuickSurveys tool. In essence, for 10% of readers, the tool was displaying the surveys correctly and we knew they had taken the survey but we never get the EventLogging that we should have. We ultimately decided that it was a mixture of adblock (which has settings that allow the javascript etc. to show the survey but blocks EventLogging) and, in our case, people could right-click off the page to take the survey and that wasn't triggered EventLogging as expected.

T220627#5641946

Windows for log samples:

Differences found in orphaned old pipeline events:

• 28% orphaned GET requests vs. 10% overall GET requests
• 63% orphaned Windows requests vs. 39% overall Windows requests

Just did one-to-one merges using web request logs in Hive, in both directions, using fairly large samples in both cases.

@elukey @Nuria Thanks so much!!!!!!!!!!!!!!!!!!!!!!!!

Here are some results:

In T238560#5682048, @Nuria wrote:

could you give some examples of issues you expect to see and troubleshoot (maybe some tickets from the past?)?

Hi all! Congrats to all for your work on this...

Windows for log samples:

Here's a summary of the situation regarding discrepancies between the new and old pipelines for Landing Pages (includes also measures obtained in T235284).

See also T237997: FRUEC: For legacy compatibility, empty language property should default to 'en' for LandingPage impressions.

See also T238023: FREUC: Check that empty or missing uselang or language URL parameter should default to 'en' language for Landing Pages.

FRUEC currently accepts LandingPage events with no language property in the JSON input. However, if the property exists and its value is an empty string, the event is marked invalid and not counted. However, in such a case, the legacy system (DjangoBannerStats) defaults the language to 'en'.

Matching on landing page, country, language, and other event fields, with old log timestamps always earlier than the new log timestamps, by at most 30 seconds, we get:

Trying different options for better matching... Just a small improvement by allowing new log timestamps that are closest to the new old log ones, that is, removing the requirement that the new log event be after the old log one. With this method, we get 136 unmatched events in new log, and 510 in the old one.

I've dug into this some more, improving filtering compared to what was done for T235284. I've got some more clarity about what the differences are, but it's still pretty ugly.

In T235845#5625873, @Christine_Domgoergen_WMDE wrote:

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

Scheduled to deploy in a few minutes...

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?

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.

Here's a patch!!! Apologies for the trouble...!

Note: the second bullet point from the task description has been spun out as T236845.

This task was about the large-scale discrepancy, which I think we can consider to be solved. There are still smaller unexplained differences between data we're getting from the old and new pipelines. I've created new tasks to investigate that: T236835 and T236834.

I've dug deeper into the Landing Page discrepancy, comparing sequences of log entries from the same IPs in both old and new pipelines.

So actually it seems the problem is not duplicate entries in the old logs, but rather a few IP addresses hammering on the site using some sort of script, which doesn't run client-side code, so it doesn't generate any client-side events.

Made some progress on figuring out what the difference is between old and new logs. It looks like there are a lot of duplicate entries in the old log files.