(UPDATE 28 Sep 2016: The official recommendation has finally caught up with the times. Now the correct placement for the JavaScript methods of the container snippet is, indeed, in <head>.)
I want to address something I’ve been confused about from the very first day since I started using Google Tag Manager. Why on earth would an asynchronously loading JavaScript library be recommended to place in the beginning of <body>, when the logical place to start loading dependencies is as early as possible in the document load process?
There might be many reasons you’d want to fire a single Tag multiple times in Google Tag Manager. The most common one is when you want to deploy multiples of a single tracking point on the web. Perhaps you have a roll-up account you want to send the hits to, in addition to the site-specific tracking property.
Quite a while ago, I gave a solution for this with a specific focus on Google Analytics Tags.
A while ago I wrote a blog post about how to install Google Tag Manager for iOS using the Swift programming language (you can read the article here). I’ve been doing a lot of work with Swift lately, and I’m more and more convinced that GTM is actually a very powerful utility for running in your iOS app instead of the Google Analytics SDK.
Why? Because it abstracts a lot of the nitty-gritty you’d otherwise need to explicitly manage in your GA installation.
You might have noticed that the Referral Exclusion List in Google Analytics is difficult to maintain. You can’t copy a list from one property to another, the list is a wildcard match for domain names (so all subdomains are automatically excluded), and it’s just about the clunkiest user interface we’ve seen since ERP tools from the 1990s. A while ago, I wrote of a solution which lets you manage referral exclusions using Google Tag Manager, and it’s still a neat trick, as it’s way more flexible than said clunky UI.
Google Tag Manager, our favorite free tag management solution, has always struggled with its enterprise-worthiness. There are many features still lacking, most of which have to do with working in multi-user environments. Now, grab the last word of that sentence (see what I did there), and hug it tightly, for GTM just introduced a new, enterprise-friendly feature: Environments.
These Environments are actually browser cookies, which you use to link a Google Tag Manager container state with the browser of the user who needs to or wants to view that particular state.
NOTE! This solution has been upgraded, and the new approach can be found here.
If you’re unfamiliar with the lingo, cross-domain tracking is a hack used by Google Analytics to circumvent the web browser’s same-origin policy. Essentially, the policy dictates that browser cookies can only be shared with a parent domain and all its sub-domains. In other words, domainA.com and domainB.com do not share cookies.
Since Google Analytics calculates sessions and users by using a cookie, this is problematic.
I’ve been meaning to write about Google Tag Manager for mobile apps for such a long time. Finally, I have some great use cases to share, as well as some useful examples for implementing GTM for iOS. That’s right, this is an iOS guide, and, to be more specific, geared towards a successful Swift implementation.
If you didn’t know, Swift is a relatively new programming language, developed by Apple for iOS and OS X programming.