One of the glaring omissions in the Enhanced Ecommerce reports of Universal Analytics is the ability to calculate cart value for products. Cart value, here, is the value that has been added to the cart. This value can be used to query for products that have the highest discrepancy between cart value and generated revenue. These are missed opportunities of the highest caliber. With some Custom Metrics magic, we can, however, get cart value into our reports, and we can find our most and least “effective” products with just a glance:
Enhanced Ecommerce is a very nice improvement to the pretty lame, transaction-based Ecommerce tracking in Universal Analytics. Instead of staring blindly at what happens on a receipt page, Enhanced Ecommerce expands your entire webstore into one large funnel labelled “Shopping Behavior”, and you’re able to zoom in on the Checkout funnel as well. Also, the addition of product-scoped tracking is incredibly useful, and it’s enabled us to think of any asset (our content, for example) on our site as something we could track through the Enhanced Ecommerce reports.
Wait. What? Why write an article about something that should work by default in Universal Analytics? I mean, here’s a screenshot from the guide I just linked to in the previous sentence: There it is. Clear as day: “Tracking users across subdomains does not require any additional configuration.” Also, some of the recent, excellent guides to cross-domain tracking, written by E-Nor and Lunametrics enforce the same: you just need a default Universal Analytics Tag in Google Tag Manager.
Here’s a tip that’s especially important to anyone working with a single-page application. Google Tag Manager persists items in its data model until you either manually delete the variable and/or its value from the data model, or until the user browses away from the page. There’s nothing as annoying as the example in the image below, where a value that was set for an earlier Tag is resent with a new Tag, even though the purpose was to leave it out.
PII (Personally Identifiable Information) is something we need to actively combat against when using Google Analytics, as the platform explicitly forbids sending PII to Google Analytics properties in any size, form, or shape. One of the most common ways of accidentally passing PII to a property is via query parameters. Many email platforms out there, for example, see no problem in including the user’s email address in the query string, especially when the user follows a link in a newsletter.
According to their website, SoundCloud is “the world’s leading social sound platform where anyone can create sounds and share them everywhere”. For artists, it’s a channel for distributing previews of their tracks, and for people like me it’s a nice way to do some API tinkering. To each their own, I guess! I saw a number of requests in the Google+ Google Tag Manager community about a SoundCloud integration, so I decided to look into it to see if I could just build one.