Here I am, back with <iframe> and cross-domain tracking. I've published a couple of articles before on the topic, with my upgraded solution being the most recent one. These articles tackle the general problem of passing the Client ID from the parent to the <iframe>. By doing so, the <iframe> can take the Client ID from the frame URL and create the _ga cookie in the <iframe>, allowing hits from the parent and the <iframe> to use the same Client ID.
One of the most prominent features of Google Tag Manager since the dawn of time (actually, late 2012) is the Custom HTML tag. This little piece of magic lets Google Tag Manager inject an HTML element to the page. Since time immemorial (still late 2012), it's allowed us to turn Google Tag Manager from a sandboxed prisoner of the native tag templates to a no-holds-barred client-side content management solution. In this article, we'll discuss how the Custom HTML tag works, and what you might be tempted to use it for.
My latest custom tag template tackles a use case I've referred to a number of times before, especially in my article on sending weather data to Google Analytics. The problem is two-fold: How to fetch the user's IP address into dataLayer How to get latitude and longitude (as well as other geographical) data into dataLayer For this purpose, I've created a new Google Tag Manager custom tag template that leverages the IP Geolocation API service.
Universal Analytics utilizes two components (by default) to attribute a browser session to a specific campaign: query parameters in the URL and the referrer string. The page URL is sent with every hit to Google Analytics using the Document location field, which also translates to the &dl parameter in the Measurement Protocol. The referrer string is sent with a hit to Google Analytics using the Document referrer field, as long as the referrer hostname does not exactly match that of the current page and the referrer string is not empty.
Google Tag Manager introduced the capability to add tests to your Custom Templates. Tests, in this context, refer specifically to unit tests that you write in order to make sure your template code works in a predictable way. Unit tests are also used to drive development, ensuring that you have added contingencies for all the different scenarios that the template, when coupled with user input, might introduce. In this guide, I'll introduce how the Tests feature works.
In Google Analytics: App + Web, you collect events. One event differs from another event by the name it uses. An event with the name page_view is different from, say, an event with the name file_download. This is all run-of-the-mill stuff. You know this. However, the fundamental change that App + Web introduces, when compared to Universal Analytics, is how event parameters are collected and processed. This gets more complicated than it should be.
- OLDER POSTS
- page 1 of 25