Not too long ago, Google announced a new consent mode for Google tags. It allows you to build a mechanism where Google’s tags parse, react, and respond to the consent status of your site visitors. Consent Mode with a custom Google Tag Manager template In short, consent mode is a beta feature, which lets you determine whether or not Google’s advertising tags (Ads and Floodlight) and analytics tags (Universal Analytics, App + Web) can utilize browser storage when sending pings to Google’s servers.
With the enforcement of SameSite settings in the latest versions of Google Chrome, it’s become a mad scramble to get cookies working across first-party and third-party contexts. I’ve covered this phenomenon before in my SameSite article, as well as in my guide for setting up cookieless tracking for iframes. Recently, Google Analytics updated its libraries (App+Web, gtag.js, and analytics.js) with a new setting: cookieFlags (analytics.js) or cookie_flags (App+Web and gtag.js).
One of the hard-and-fast rules in Google Analytics is that once hits have been collected and processed into your data properties, those hits are untouchable. This means that if you mistakenly collect duplicate or incorrect transactions, PII traffic, or referral spam, for example, it’s extremely difficult, if not downright impossible, to purge or change this data in Google Analytics. Another staple of Google Analytics’ strict schema is that displacing hits in time is also very difficult.
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.
There are lots of different readability formulas out there, which seek to provide an index on how readable any given excerpt of text is. Typically, these formulas output a grade-level score, which indicates, roughly, the level of education required to read the text excerpt with ease. Any “quality index” that seeks to reduce the complexity of something as multi-faceted as reading should be subject to scrutiny. This is true for Bounce Rate, this is true for Time On Page, and this is true for a readability score.
There are thousands upon thousands of bots, crawlers, spiders, and other creepy-crawlies out there doing nothing but crawling through websites and harvesting the content within for whatever purposes they have been fine-tuned to. While Google Analytics provides a bot filtering feature to filter out “spam” and “bot traffic” from views, this is far from comprehensive enough to tackle all instances of bot traffic that might enter the site. You might have noticed bot traffic in your data even if you have bot filtering toggled on.
Update 7 October 2020: BigQuery Export can now be configured via the property settings of Google Analytics: App + Web, so you don’t need to follow the steps in this article. Check out Charles Farina’s guide for how to do this. Here’s yet another article inspired by the fairly recent release of Google Analytics: App + Web properties. This new property type surfaces Firebase’s analytics capabilities for websites as well, when before they were restricted to mobile apps only (see my guides for iOS and Android).
- OLDER POSTS
- page 1 of 10