K found it! Somehow in this case we're sending the event via the desktop URL when on the mobile site, and so this is being blocked by a security policy. (The error said "not allowed by Access-Control-Allow-Origin".) Checking out the exact how and why now...

Patch for review: https://gerrit.wikimedia.org/r/#/c/377538/

(Not sure why it didn't register automatically...)

Summary:

• I've been looking at this via webrequest logs in Hive and dev tools on an iPad simulator.
• Found an error that happens on mainly only mobile Safari (as mentioned in previous comment) and made a patch that fixes it.
• Still not sure of the exactly what changed to trigger this, though, and some numbers I'm seeing in Hive are also still confusing.

On the iPad simulator, I confirmed that the method of sending the logs used in the above patch works, and that the event data makes it to the webrequest log.

Apparently the problem with the old code is that we were using a POST request (maybe to prevent caching? Or that's how EL used to do it? Note sure...). That was triggering a CORS block on the mobile site, since the EventLogging URL uses the desktop host. Possibly the browser was sending a "preflighted" request before the real one.

After changing the dataType to script in the $.ajax() call , it seems to work fine.

The issue doesn't exist at all on most platforms. This code is only run for browsers that don't support sendBeacon. For those platforms, we use our special code to try to ensure the request is sent before navigating to Payments wiki.

The normal EventLogging method used for Safari and company is also working fine, data gets to Hive without any issue.

What's confusing is that the rate of events/total non-event webrequests on the mobile site is much lower for Mobile Safari than for other mobile browsers. Data and queries forthcoming...

Change 377538 merged by jenkins-bot:
[mediawiki/extensions/CentralNotice@master] BannerHistoryLogger: Fix ajax options for when sendBeacon is not available

https://gerrit.wikimedia.org/r/377538

Change 381047 had a related patch set uploaded (by AndyRussG; owner: AndyRussG):
[mediawiki/extensions/CentralNotice@wmf_deploy] BannerHistoryLogger: Fix ajax options for when sendBeacon is not available

https://gerrit.wikimedia.org/r/381047

Change 381047 abandoned by AndyRussG:
BannerHistoryLogger: Fix ajax options for when sendBeacon is not available

Reason:
Re-submitting with message about cherry-pick

https://gerrit.wikimedia.org/r/381047

Change 381047 restored by AndyRussG:
BannerHistoryLogger: Fix ajax options for when sendBeacon is not available

Reason:
Gerrit silliness

https://gerrit.wikimedia.org/r/381047

Change 381047 merged by jenkins-bot:
[mediawiki/extensions/CentralNotice@wmf_deploy] BannerHistoryLogger: Fix ajax options for when sendBeacon is not available

https://gerrit.wikimedia.org/r/381047

Mentioned in SAL (#wikimedia-operations) [2017-09-27T18:23:25Z] <catrope@tin> Started scap: SWAT: T176762, T175358, T172023, T174719, and add html5-misnesting to Linter

Mentioned in SAL (#wikimedia-operations) [2017-09-27T18:46:20Z] <catrope@tin> Finished scap: SWAT: T176762, T175358, T172023, T174719, and add html5-misnesting to Linter (duration: 22m 55s)

Confirmed via Hive that Safari on iOS is sending banner history logs at an approximately correct rate. For one day in the France FR campaign (2017-10-19), here are the ratios of BannerLoader requests vs. EventLogging requests to send sampled banner history logs, on the mobile site, for all major platforms:

Banner history samples  BannerLoader requests  Ratio    Browser         OS
337                     29450                  0.01144  IE Mobile       Windows Phone
283                     31335                  0.00903  Edge Mobile     Windows Phone
30188                   3415112                0.00884  Chrome Mobile   Android
492                     56437                  0.00872  Mobile Safari   iOS
681                     79616                  0.00855  Android         Android
3059                    385884                 0.00793  Chrome          Android
525                     102848                 0.00510  Firefox Mobile  Android

The logs are sampled at a 1%, so the expected ratio is 0.01. Mobile Safari is now close to that, similar to Chrome Mobile. (There is some variation among platforms, and a low rate for Firefox Mobile, which might bear investigation sometime, but for the most part the numbers look decent, I think.)

Here's the query: P6165

@Mpany do BH logs for iPads for the France campaign look OK to you?

Thanks!!! :D

@AndyRussG Thank you for all your sleuthing on this! The BH logs for iPad in the France campaign do indeed look OK to me now. They also look OK for the newest en6C tests. I will keep you in the loop as I keep monitoring them.