Hacker News Reader

Comment by acdx | Hacker News Reader

This is just an analysis of the snippet, not the script it loads (www.google-analytics.com/analytics.js).

If there is interest, I could analyze that. (I'm not the author of the article.)

Sure, there is interest!

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?

Google Analytics documentation on transport method: https://developers.google.com/analytics/devguides/collection...

GA does not store any data that persists from page to page other than the client ID cookie.

See here: https://developer.mozilla.org/en-US/docs/Web/API/Navigator/s...

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).

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.

There's no magic to tracking cookies, unless you don't care about regulation, why not use your own tracking cookies for 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.

it's dated, but still the best public resource on de-obfuscating gclid's.

https://deedpolloffice.com/blog/articles/decoding-gclid-para...

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.

Reply on news.ycombinator.com