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.
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). Even though the feature set of Google Analytics for Firebase is still somewhat bare in the user interface, here’s a perk which might push you over the edge and give the new measurement model a shot.
Ah, Safari’s Intelligent Tracking Prevention - the gift that keeps on giving. Having almost milked this cow for all it’s worth, I was sure there would be little need to revisit the topic. Maybe, I thought, it would be better to just sit back and watch the world burn. But then Mr. Charles Farina, a good friend and so amicable he’s practically Canadian, tempted me into testing out a quick proof-of-concept web service that would give us back our first party cookies.
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.
- OLDER POSTS
- page 1 of 10