Update beacon support to handle "gotchas"

[yalisassoon]

https://robertsahlin.com/analytics-beacon-transport-mechanism-gotchas/

[ScottyMJacobson]

thanks for catching this Yali (@yalisassoon)! i suppose we might have noticed the discrepancy once we were in production, but I'm working on a mitigation for our setup - i'll let you know if it looks like something that would work in the s-j-t codebase

[ScottyMJacobson]

after some discussion internally we'd rather send a dummy xhr request on init on iOS devices rather than abandon sendBeacon() altogether or send the first request as pure POST. our implementation will use this workaround - let me know what you guys think of the different options w/r/t workaround method

[yalisassoon]

Thanks for sharing Scotty Jacobson (@ScottyMJacobson). I'll discuss with Michael Hadam (@mhadam) and let you know how we plan to update the JS tracker to handle the issues raised by Robert Sahlin (@robertsahlin).

[paulboocock]

v2.13.0-M2 is the first milestone release that incorporates this updated Beacon API implementation. We have taken the approach to send the first request always with POST. This appears to have had a significant effect on the differences in the numbers of events we have captured with Beacon in Safari.
We are going to continue testing this new functionality but we are making this Milestone release available for others to test and feedback if this wish.

[ScottyMJacobson]

I should have updated here earlier, but I also just wanna give a heads up that it looks like Beacon on iOS will start failing again at some point, even after you've sent a POST beforehand to warm up / authenticate the CORS.

we observed this in our web app that sends a lot of requests to different sites at runtime, so my theory is that there's some sort of limited cache of sites with TLS/CORS approval, and we blow up the cache with the number of requests we're making, and then by the time the next snowplow beacon comes around, iOS has "forgotten" that it's allowed to communicate with our collector

this theory isn't supported by any knowledge of the webkit codebase or anything, but i also prefer this explanation over "it just randomly stops working" which is how it felt

(edit: our original solution involved sending a POST and a Beacon for every beacon on iOS, but looking back at our codebase, we actually abandoned that strategy for a only-send-beacon-when-we-really-need-it (i.e. for dropoff events))

[paulboocock]

Thanks for the extra context Scotty Jacobson (@ScottyMJacobson)
Our current tracker architecture doesn't really support changing the send method per event, although this is certainly something to consider going forward.
We've done some initial testing with the "POST Preflight" concept and have seen a huge reduction in the difference between POST vs Beacon (6.3% to 0.8% difference) and for many browsers we are now seeing more events with Beacon which is what you would actually expect if browsers were behaving properly.
We have some further tests underway at the moment and depending on the results of those, then we'll make a call on whether to merge this into 2.13.0 or not.