Last updated 18 Jan 2019: Added details about the free tier limitations, and showed how to avoid the Dataflow jobs auto-scaling out of control.
I’m (still) a huge fan of Snowplow Analytics. Their open-source, modular approach to DIY analytics pipelines has inspired me two write articles about them, and to host a meetup in Helsinki. In my previous Snowplow with Amazon Web Services guide, I walked you through setting up a Snowplow pipeline using Amazon Web Services.
If you’re a user of the free version of Google Analytics, and if you have a free Google Analytics property collecting hits exclusively from the Google Analytics Services SDK (Android or iOS), you might have recently received an email that looks like this (emphasis mine):
In a nutshell, Google is now starting the process of deprecating the “legacy” Google Analytics for Mobile Apps. This covers all data collection SDKs that do not have the word “Firebase” in them.
UPDATE 4 June 2020: Instead of copying the Custom HTML code from the article, please load it from the GitHub Gist instead.
Four years ago, I wrote an article on how to persist GTM’s dataLayer from page to page. Unfortunately, the solution was a bit clumsy, requiring you to give specific commands for the interactions, which made it really unwieldy in the long run. Google Tag Manager still doesn’t offer us a native way to persist the dataLayer array or its internal data model from one page to the other, so I thought it was about time I revisit this idea.
One of the difficulties of working with Google Tag Manager and the dataLayer structure is that GTM doesn’t preserve history of the items collected into its data model. Or, at least, it doesn’t preserve it in a manner that would let us access it.
This is typically a very niche problem, but it does surface every now and then. For example, say you wanted to query whether an event with some specific value has already been pushed into dataLayer.
While using the Google Tag Manager user interface around Halloween 2018, you might have noticed a new tab in Google Tag Manager’s Preview mode. The tab is named Errors and shows you the number of exceptions thrown by GTM’s tag templates on the page. In this short #GTMTips post, I’ll quickly walk you through what the tab shows.
Tip 90: The Errors Tab In Preview Mode The tab’s name is an apt description of what the tab shows.
Over 5 years ago, I wrote an article titled Track Adjusted Bounce Rate In Universal Analytics. It basically explored a number of different methods to tweak the Bounce Rate metric so that it becomes more meaningful in your Google Analytics reports.
Now, writing that article wasn’t necessarily my proudest moment. It’s not because the solution was poor, but rather because I was suggesting it makes sense to tweak a metric. The concept of “adjusted Bounce Rate” sounds like the analyst is fixing a metric to be more beneficial to their cause, rather than fixing the business problem that caused the metric to be poor in the first place.
Google Tag Manager offers us some nice built-in triggers so that we can automatically listen for specific user interactions on the website, reacting to them however we wish, though typically it would be to fire a tag. The tricky thing especially with the click triggers and form submission tracking is that the page has a nasty habit of redirecting you to the link or form target page before letting you see the respective data in Google Tag Manager’s excellent preview mode.