One of the myths surrounding Google Analytics is that the first hit of a session should always be a pageview. It makes sense - sessions are initialized with a landing page, and thus need a page view to have one. However, in this article I want to show you empirically how this myth is just that - a myth. There is little discernible impact if the first hit of a session is an event, and GA is more than capable of stitching the first event together with the subsequent pageview into a session entity.
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.
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'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.
In Google Analytics, the concept of a session is the key aggregation unit of all the data you work with. It's so central to all the key metrics you use (Conversion Rate, Bounce Rate, Session Duration, Landing Page), and yet there's an underlying complexity that I'm pretty certain is unrecognized by many of GA's users. And yet, since this idea of a session is so focal to GA (to the point of being overbearing), it's annoying that the browser isn't privy to any of the sessionization parameters that Google Analytics applies to the hits sent from the browser to its servers.
Here we are, reunited with customTask. This time, we'll put this wonderful mechanism to work for a very, very good cause. One of the lesser known “features” of Google Analytics is that when the payload size (the request body that is actually sent to Google Analytics with each request) goes past a certain limit, specifically 8192 bytes, the hit is aborted without warning. This can come as a surprise, because there's no indication anywhere in Google Analytics that you are missing hits because of this.
After writing yet another customTask article on how to respect client-side opt-out using Google Analytics and Google Tag Manager, the analytics.js core library was enhanced with a new field that makes it all a lot easier to do. The field, allowAdFeatures, lets you either allow or block the request to DoubleClick that is initiated when Advertising Features have been enabled. In this very short article, I'll quickly show you what the field does and why it's useful.