Google Analytics Autotrack | Hacker News Reader

Google Analytics Autotrack

github.com

109 pointsmikeshaw29 comments

Analytics tracking code is a serious headache. You rarely know upfront what events you'll care about later, it's a pain to setup and maintain, and there's a principal-agent problem where the person implementing tracking (a dev) isn't the one getting value from it (a non-dev).

I think we'll start seeing teams adopt more automated approaches to analytics tracking over time.

Disclaimer: I founded Heap (https://heapanalytics.com/) with the idea that manual instrumentation should be the exception, not the norm.

+1 for manual instrumentation should be the exception, not the norm. However many time there is instinct to log everything that you don't pay enough attention to what one metric is most valuable to your business. And when you need it, its just too tough to get it + system slows down because of logging everything (if building inhouse).

Btw Autotrack is direct competitor to heap. How are you going to maintain differentiation? Or something for which heap gives 10x that autotrack doesn't?

You alluded to some of this already, but automatically capturing everything isn't just a feature you can tack on to an existing analytics system. You have to rethink everything from the ground-up in order to support it (the client-side SDKs, the infrastructure, the tools to organize the data, the analysis interface, etc).

This becomes obvious when you try both products side-by-side (and I encourage you to do so!). I haven't come across a single customer who sees this as a viable substitute for Heap.

Also, collecting everything doesn't mean you should pay attention to every possible metric all the time. It just makes it 1000x easier to hone in on the right metric at the right time.

That said, this is an awesome GA extension, and philipwalton deserves a lot of credit for building it.

Hey MatM. Big fan of Heap right here. In fact, just did a new install for a new project yesterday. Heap definitely makes life much much easier, but when there's a need to collect data from multiple sources, ie not just the website but lets say FB ads, Intercom etc to create a 360-degree customer view, it becomes harder to rely solely on Heap. Now, ordinarily we use Segment and pipe the data to a data warehouse but sending Heap data to a data warehouse is a very pricey option. I wish it wasnt so pricey.

Happy to hear that!

Could you email me at matin@heapanalytics.com? We're cooking up some features you might find useful.

Email sent (from kam [at] stratagem[.]io

I've looked at Heap before but the lack of pricing between free and “custom” has turned me off trying it.

Really hard to recommend it to anyone else either since there's no information about what it would end up costing (assuming that adding the Heap badge is out of the question).

Weird. I cannot star this repo in github with my ad blocker (u block origin) turned on. Apparently, the star request sends a request to this end point - https://www.google-analytics.com/collect which fails, which results in a github error saying "You cannot perform this action at this time".

Everything works fine, when adblocker was turned off in the page. Any ideas on why this behaviour?

This explains a lot, thank you :)

That request being blocked is fine.

The error is due to the star POST request on Github being blocked. The endpoint in question is https://github.com/googleanalytics/autotrack/star. Your ad blocker uses string matching to block URLs and sees "googleanalytics" (the repository name) in there and blocks it.

Thanks for the explanation. I'm still taken aback by Github's behaviour to communicate with outside apis for their internal star operation.

if you use any kind of 3rd party analytics service you need to communicate with outside api basically every (analytically relevant) action of your user... so it's pretty standard on web and native apps alike

If that is the case, why all the other the other repo's star operations is not communicated to google or other analytics platform? My point was, I was blocked from starring only for this repo and not all the other repos. It was not about how analytics works in general for every user action.

A sibilling comment was explaining it: basically your ublock (that I use too) is regularly blocking the request to google analytics everywhere, github code doesn't fail in that case, but since the repo contained the "googleanalytics" substring ublock was blocking the request (because it checks for words in the urls that get requested) to the github server thus making the starring function fail.

Other repo do not have "suspicious" strings in their url, so they pass through ublock, while the real google analytics call is blocked and github does not fail. You can check the network tab in the developer tools in chrome around github and see that calls to GA gets blocked and calls to github pass while on that specific page also the call to github fails

That's not what is happening. Your ad blocker thinks so because the URL contains a string it mistrusts, is all.

Would love to see a comparison of this and the set up posted last night:

https://philipwalton.com/articles/the-google-analytics-setup... (via https://news.ycombinator.com/item?id=13636884)

and the other set up linked from those comments:

https://github.com/thenextweb/gtm

The author of that article is the same author of autotrack. He actually mentioned it yesterday.

As dudus mentions: the GA article posted yesterday includes a recommendation to use this library.

As for a comparison of it vs. the GTM setup used by thenextweb, I briefly explain my thoughts on GTM in another comment here: https://news.ycombinator.com/item?id=13648771

Just from vaguely reading their shorthand documentation (correct me if I'm wrong) but there doesn't seem to be a way to associate this with goals you've set for each event (you'd normally do this within your own code;) which imo means you're going to collect a lot of junk data you don't want.

I guess you could find out how it outputs the event and then set a goal for it, but I doubt it would be pretty and you're still going to get a lot of junk in your real-time view. I hate having to set-up callbacks for outbound links, it's a real pain in the butt (especially if you're having to instruct someone else to place the code,) and sometimes it doesn't fire properly on certain browsers so this would be nice...but it could also be messy (from my quick look.)

I do like that GTM can do -most- of this now, which allows the marketing/PPC/Analytics team(s) to do things on the fly without having to bother me.

There is a way.

Every autotrack plugin that sends hits has two configuration options that enable full customization over exactly what fields get sent with each hit.

The options are `fieldsObj` and `hitFilter`: https://github.com/googleanalytics/autotrack/blob/master/doc...

Thanks

Has anyone used this or anything like this? Any notes on the extra js affecting page performance?

Have had major issues with reporting using this tool with an "infinite scroll" or single page app type of setup. Serious under-reporting of the history state change.

The maxScrollTracker documentation warns against using it with an infinite scroll type of page: https://github.com/googleanalytics/autotrack/blob/master/doc...

As for under reporting of history state changes, have you reported a bug? Also, how are measuring to confirm that there is under reporting?

The library is designed to be loaded async, so it shouldn't affect load performance. And it uses new APIs (e.g. IntersectionObserver) and techniques like throttle/debounce for all of its event tracking, so it will likely have no noticeable impact on runtime performance.

My question is since we have GTM. would it be much easier to just import GTM setting to new site you want to deploy? And it also will be easier to make modification to those "tracker plugin".

There are tons of things GTM can't do currently, unless you're willing to write custom code. And if you're writing custom code, I'd personally prefer that code to be in my app, under version control, and running through my test suite rather than in a GUI that can be modified by anyone with GTM access.

Here are a few examples off the top of my head of things you can't do with GTM today (without writing custom code):

- Tracking when (and how long) the page was in the visible vs hidden state.

- Tracking anything performance-related.

- Tracking when DOM elements are visible in the viewport (via IntersectionObserver).

- Tracking the active media query / breakpoint.

- Tracking social widget button usage.

- Tracking the use of service worker

- Tracking interactions with native web push notifications.

I think GTM is great for marketing websites, but for better understanding how someone is using a complex web app, I think it makes more sense to have that logic in the application code.

Lunametrics blog has a bunch of GTM recipes for most of the autotrack metrics.

I would LOVE for someone to create a version of this for Segment. It would CHANGE my life!

Reply on news.ycombinator.com