Thanks to the intrepid detective work of Jørn Reidel and Ahmed Marof, it looks like one of the big hurdles for doing a full migration from using the legacy Google Analytics and Google Tag Manager SDKs to the latest Tag Manager + Firebase SDK is now a non-issue. The issue is, of course, Product-scoped Custom Dimensions or more specifically the lack of support thereof. Until now, I’d been holding against recommending the migration to anyone with Enhanced Ecommerce tracking set up simply because the documentation didn’t mention the possibility of sending these custom definitions to Google Analytics.
Perhaps you didn’t know this, but there’s a really handy demo account for Google Analytics you can use to check out how Google Analytics works in a real business context (the data is from the Google Merchandise Store). However, you can access the account with nothing more than read-only access. This is annoying if you wanted to customize the setup. Worry not, I have a solution for you! Harnessing the awesome power of customTask, you can create a duplicate of the data collected on any website where you can modify the tracking (e.
One of the big problems in Google Analytics’ data model is the immutability of historical data. Once a row of data is written into the data table, it is there practically for good. This is especially annoying in two cases: spam and bogus ecommerce hits. The first is a recognized issue with an open and public data collection protocol, the latter is an annoyance that can explode into full-blown sabotage (you can use the Measurement Protocol to send hundreds of huge transactions to your competitor’s GA property, for example).
Scope in Google Analytics’ Custom Dimensions refers to how the value in the Custom Dimension is extended to all hits in the same scope. Hit- and product-scoped Custom Dimensions apply to the given hit alone - they are not extended to any other hits in the session or by the same user. Session-scoped Custom Dimensions apply the last value sent during the session to all the hits in that session.
If you are enjoying the Element Visibility trigger as much as I am, you’ll be glad to know of a very simple tip that might make your life easier when using Google Tag Manager. The tip is this: If you’ve activated the built-in Click variables, they will be automatically populated with details about the element that caused the Element Visibility trigger to activate! Tip 92: Use Built-in variables to analyze the visible element Yes, it’s confusing they’re still named Click variables, especially since they’re duplicated in the Form variables, and even more so since they can be used with the Element Visibility trigger to identify which element became visibility.
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.