In https://phabricator.wikimedia.org/T226986#6467482 I wrote:

Huh, I'm pretty sure I discussed this with @BBlack or @ema when we were first setting up eventgate-analytics-external, and they preferred that the intake service got its own unique URL, rather than serving it in the wiki domains.

I can't find a public discussion of this in Phab, just https://phabricator.wikimedia.org/T233629#557637, so we must have discussed it in IRC or elsewhere.

Also relevant: T262996: Don't set cookies in traffic layer for non-user facing domains (avoid false third-party cookie warning)

Also relevant: T261340: 'skip_first' feature flag for gdnsd GeoIP plugin
Chris is making use of the fact that there is a separate endpoint to route logging events to the next nearest datacenter in case there is something wrong with the route to the nearest datacenter.

To instrument this, and gauge any background/side impact during page load, I'd recommend creating two speed-tests scenarios under wikipedia.org/speed-tests/ where one is simple like the current Banksy page, and another that performs a handful of sendBeacon() calls from inline scripts against a domain that requires a separate DNS resolution and TLS/TCP connection. Either intake-logging is it has already been configured this way by now, or a any different production URL that doesn't sharre the same dns target and tls cert with the canonical wiki domains.

Then to add both scenarios to our synthetic test config for a few days to compare them side-by-side:
https://wikitech.wikimedia.org/wiki/Performance/WebPageTest#Add_a_new_URL_to_test

Updated title to reflect to recognise that the original one of these (NEL: Network Error Logging) was intentionally done as a separate domain and DC for logicial seperation of networking problems when trying to have the browser notify us of networking problems.

However, for all first-party and in-page use of EventLogging/EventGate, this doesn't apply.