Using 1-character variable names saves a small amount of network bandwidth on a massive scale (for every site that uses Google Analytics). You then might as well make the 1-character variable names spell out a word, and that word has to be an "isogram" in order to provide unique variable names.
I'm interested. I built something to track events for analytics long ago ~7 years. Constantly surprised it's stood the test of time. Coincidentally the loading portion is similar to the GA loading portion analyzed in the article.
Lots of questions, I would love to understand how GA are capturing events that are sometimes trapped and not allowed to bubble, etc. Are they capturing events at document.body level, etc? What type of IDs do they use to bring sessions together, do the ID events similarly? Do they queue up events to batch them or do they trickle them in. How do they deliver events when unloading a page, etc.
Google Analytics does not capture any DOM events. Data gets into the "Events" report in the GA interface when a developer explicitly makes a function call like `ga('send', 'event', Category, Action, Label);`. Google Tag Manager can automatically add tracking to several types of DOM interactions. GTM captures events at the document.body, and you would generally need a work-around if something is screwing with event bubbling.
Nowadays, connecting Sessions and Users are handled by storing an ID in a first-party cookie named _ga. There is no such thing as an Event ID in Google Analytics, unless you implement one manually in a Custom Dimension. The Event report has Total Event and Unique Event metrics, and it's up to the user to choose whether they want to pay attention to deduplicated Events or not.
On the web, hits are not batched, they are handled as they come in (except for a throttling limit). The Android and iOS SDK batch hits by default.
On pageload, queued hits can be sent with the "beacon" protocol, which is a HTML standard that exists specifically to solve this exact problem. In browsers that do not use the beacon protocol, the hit is simply dropped.
Any reference to the beacon protocol? I've never seen or heard of this. I've implemented mechanisms to periodically drain queues and clean up onbeforeunload for single page apps. Does GA's event queue span pages?
The "protocol" is just a deferred HTTP POST request that does not block page unload. Please use this as it is widely supported and provides better UX (page is not blocked by sync XHR).
I've reverse-engineered most of their minified code, and it's a huge pain. Since they use closure compiler, there's a huge object pool that gets referenced for every single thing. It's supposed to make the source a little smaller, but geez.
Unless I'm misremembering, something that I found interesting was that the cookie wasn't randomized, it was a fingerprint based on a large number of params.
If you could analyze the old ga.js and figure out a way to accurately duplicate the way the old utmz cookie was created, you could probably make some money off your effort. I've yet to see a great solution to this.
How old is "old", and what do you need it for? I've written code to parse the utmz cookie and separate code to recreate the whole organic/referral/utm attribution model in GA using first party log data. The only major drawback AFAIK is that adwords utm parameters are obfuscated and Google doesn't provide a way to resolve glclids to their campaign's utm params.
They still aren't "full" view controllers, though. I don't think any of the controller callbacks are executed. I would be surprised if custom drawing is possible. This feature mostly seems to let you leverage autolayout and size classes, which is probably enough for most people
Yep, that's basically it. You can't link any code to it. I think it was added just to make your launch screen look as similar as possible to your app's first screen.
