Google Analytics

Comparing GA3 and GA4 Metrics in Reporting

Google Analytics 4 (GA4) is replacing Universal Analytics (GA3). To prepare everyone for the change, I’ve created a series of blog posts to help users understand the difference between the two versions. Today’s post is a guide to helping you compare your GA3 reporting with your GA4 reporting. You’ll learn how increases and decreases of certain metrics may be more representative of your shift to GA4, rather than optimizations you made as a marketer.

Sessions

Sessions are calculated differently in GA4 than in GA3. Your sessions may be lower in GA4 because:

  1. Session Timeout: While the automatic session duration is defaulted to 30 minutes in both versions of Google Analytics, GA4 allows you to extend that session timeout to 7 hours and 55 minutes. GA3 had a maximum timeout of only 4 hours. That means if you extended your session timeout to GA4’s maximum, someone that stepped away from your website for five hours would be counted as two sessions in GA3, while in GA4 they would be counted as one.
  2. Midnight Restart: In GA3, all sessions break at midnight. In GA4, this isn’t the case. This midnight cutoff is based on the time zone you set within your Google Analytics settings. For example, let’s imagine you’re an ecommerce vendor who gets a lot of traffic from across the U.S. on Thanksgiving. While your fellow East Coast residents have likely gone to bed at midnight, it’s only 9:00 p.m. on the West Coast, and people may still be up shopping. Any session that spans both 8:59 p.m. PST and 9:00 p.m. PST will appear as though you’ve gotten 2 sessions in GA3. In GA4, the session will persist and more accurately reflect the one session. 
  3. New Campaign Parameters: If someone encountered two of your campaigns within a short time frame while browsing the web, each of those campaigns would cause a new session to start in GA3. However, in GA4, the session won’t break. For example, if someone first clicks on a paid ad, goes to your website, immediately goes back to Google and clicks on your Google Business Places profile, GA3 would count that as two sessions. In contrast, GA4 would only count that as one session. 
  4. Automatic Bot Filter: GA4 has a bot filter that removes known bots and spider traffic from your website. Google populated this list based on their own research and the International Spiders and Bots List. GA3 did not have such a filter.

There’s one reason, however that your GA4 numbers may be higher than your GA3 numbers:

  1. Manual Filters: At the time of writing this post, GA4 does not allow for filters beyond IP filters. This lack of filters means that if you were filtering out hostname traffic in your GA3 property settings instead of configuring your Google Analytics tag within Google Tag Manager, your unwanted hostnames will appear in GA4.

Conversions

GA3 groups all website activity within a session. In doing so, Google also deduplicated any conversions within that session. If someone filled out a form 8 times, Google Analytics counted that as one goal completion. Conversely, GA4 isn’t a data model based on sessions. As a result, in GA4, those 8 form fills would be counted as 8 conversions. This difference means you will likely see an uptick in GA4 conversions compared to GA3, whether or not you make any website optimizations.

It’s also important to point out that because of this lack of deduplication, the transition to GA4 is a great time to test the validation on your forms. If your conversion event fires when you click a “submit” button without ever filling out a form, you likely need to tighten up your event logic to more accurately reflect your lead count.

Average Session Duration

To calculate the average time on page metric in GA3, Google would subtract the time you visited page 1 from the time you visited page 2. The inherent flaw was that Google Analytics had no way of measuring the time someone spent on your exit page because there was no subsequent pageview from which to subtract. 

Because Google could never figure out the length of time someone spent on an exit page, GA3 always undercalculated average session duration. Sometimes this was undercounted by mere seconds. Other times, it was under calculated by 10 minutes or more. 

GA4 measures time differently by sending a timestamp with every event. I dive deeper into the comparison in another blog post, but the bottom line remains the same. When you compare your average session duration metrics in GA3 to GA4, GA4 will likely have the higher number.

Bounce Rate

GA3’s bounce rate metric was largely influenced by the amount of event tracking you added to your Google Analytics account. The more events you had, the less bounces you likely had. As a result, there is a good chance anyone with lots of event tracking would naturally have a lower bounce rate in GA3. In contrast, account owners that did not implement any custom event tracking would naturally have a higher bounce rate.

In another blog post, I explain why GA4 bounce rate is a little harder to inflate. With GA4, event tracking will only decrease your bounce rate if you count that event as a conversion. The result is that if you had a super low bounce rate in Universal Analytics due to lots of event tracking, your GA4 bounce rate will likely be higher. Inversely, if your bounce rate was incredibly high in Universal Analytics, don’t be surprised if it lowers in GA4.

Summary

Below is an easy takeaway of what you should expect when you compare your GA3 to your GA4 reporting.

MetricResults in GA4 Reporting
SessionsLikely lower than GA3, but it depends
ConversionsLikely higher than GA3
Average Session DurationLikely higher than GA3
Bounce RateIt depends

Make sure to take this new measurement into consideration when doing analysis so you don’t inadvertently make an optimization decision based on incorrect assumptions. GA4 is continuously rolling out new features. Check back for updates or dive into other comparisons of Universal Analytics and GA4.

Comparing GA3 Behavior Flow and GA4 Path Exploration Reports

Google Analytics 4 (GA4) is replacing Universal Analytics (GA3). To prepare everyone for the change, I’ve created a series of blog posts to help users understand the difference between the two versions.  Today I’m diving into the four main differences between the Behavior Flow report in Universal Analytics and the Path Exploration report in GA4.

Background

Released in 2011 under the name “Visitors Flow,” the Behavior Flow report was one of the few opportunities in Universal Analytics to view a customer’s journey throughout one session on your website. Despite the promise for true customer insights, the lack of customization and clumsy aggregation made analysis with this report often difficult. With the introduction of GA4, the Behavior Flow report got a new name – Path Exploration – and new functionality. Below I’ll talk about the four main differences between the Behavior Flow report and the Path Exploration report.

Difference # 1 – Explore More Than Six Paths 

One major limitation of the Behavior Flow report in GA3 was that you could only get a detailed look at the top six interactions that occurred after a starting point of your choosing. For these top six interactions, you could see the next page path (or event) and continue to follow along to find the next eleven steps in the user journey. Beyond those top six interactions, though, data was limited. For the top seven interactions and beyond, you could only see the percentage of traffic a subsequent page received and that page’s drop off rate. Unlike the top six interactions, you couldn’t get any insight into the next three, four, or eleven steps in the customer journey.  

With GA4 and the Path Exploration report, the limit of events you can explore is much higher. Instead of looking at the top six interactions, you can explore up to nineteen of your top interactions and the steps that followed those interactions.

GA3 Behavior Flow Report
GA4 Path Exploration Report

Difference # 2 – Filtering Out Events

I previously mentioned the lack of configurability within the Behavior Flow report, and filtering out events was no exception to that rule. To provide more insightful analysis, sometimes you needed to exclude events within your customer journey. Even with strategic event tracking, some events only provide thought-provoking data in certain circumstances. For example, if you’re tracking scroll depth, that could be a great way to measure engaged on your blog. However, including this event in the Path Exploration could result in unwanted noise that distracts from a larger goal, such as the key CTAs someone used before submitting a lead form.

With GA4, the pencil icon appears next to each step, allowing you to filter out events you don’t believe are relevant to your particular analysis.

The pencil icon allows you to filter out certain events in the GA4 Behavior Flow report

Difference # 3 – Exploring Paths in Two Different Directions

GA3 limited the Behavior Flow report to one direction – forwards. While you could tell the steps someone took to prior to completing a goal with the aptly named Reserve Goal Path report, this was even more limited than the Behavior Flow report. With the Reserve Goal Path report, you could only see the three previous steps to completing a goal. Furthermore, this was limited to pages that someone visited prior to completing a goal – there was no granular drill down into custom events you may have tracked.

GA4’s Path Exploration report provides greater flexibility, allowing you to analyze different user paths based on either a starting or ending point. This means you can tell the paths someone tool after they visit your landing page, or you can tell what pages or CTAs someone interacted with prior to submitting a form.

GA4 allows you to choose an ending point instead of a starting point within the Behavior Flow report.

Difference # 4 – Exploring Paths Across Sessions

One of the main selling points of GA4 was a new data model that was event based instead of GA3’s session based data model. This meant that any report you viewed would not be constricted by sessions like it was in GA3. Instead, you could see the full customer journey, regardless of how long it took. 

We see this logic applied within the Path Exploration report, which shows the customer journey across sessions. In contrast, GA3’s the Behavior Flow report only included activity within one session.

GA4 allows you to explore user behavior across sessions, as evidenced by the multiple “session_start” events

Summary

The Path Exploration report in GA4 is a huge upgrade from the Behavior Flow report in GA3, with more visible data, no session limitations, filtering, and the ability to analyze events from a starting or ending point. GA4 is continuously rolling out new features. Learn more about GA4 reporting metrics with the blog articles below:

Comparing the Measurement of Time GA3 vs. GA4

Google Analytics 4 (GA4) is replacing Universal Analytics (GA3). To prepare everyone for the change, I’ve created a series of blog posts to help users understand the difference between the two versions.  Today I’m going to walk through how time is measured in GA3 with the average session duration and average time on page metrics and compare that to how time is measured in GA4 with the average session duration and average engagement time per session metrics.

Measuring Time in GA3

With Universal Analytics (GA3), the average time on page and average session duration metrics were wildly inaccurate. This is because time measurement in GA3 was inherently flawed. Instead of collecting timestamps intermittently throughout a session, a timestamp was only recorded with a pageview. To calculate the average time on page metric, Google would subtract the time you visited page 1 from the time you visited page 2. The inherent flaw was that Google Analytics had no way of measuring the time someone spent on your exit page because there was no subsequent pageview from which to subtract.

Now, many marketers are big-picture thinkers. Sure, the number may not have been 100% accurate, but it gave us a starting point, right? Wrong. Numerous blog articles go into this in-depth, providing real-life examples, but it took a metaphor before I truly understood how inaccurate and misleading GA3 time metrics could be. 

The way Google Analytics measured time in GA3 was similar to measuring the distance it takes to get somewhere using stoplights. While most of us encounter stoplights when we drive, think about the exceptions to the rule. For example, this method doesn’t account for highways, which don’t have stoplights. It also doesn’t account for the time it takes you to drive to a business that’s located right off the highway. It also doesn’t account for the fact that sometimes you’re driving across the state (or across several states for my non-Texan readers). Below is a graphic that measures the time to get from Houston to the DFW airport realistically vs. using GA3’s time measurement logic.  

Measuring Time in GA4

Measuring time in GA4 is leaps and bounds more accurate. Not only is a timestamp sent with every pageview, but it’s also sent with each event that occurs. And with GA4’s out-of-the-box events, such as outbound links, file downloads, and form fills, you’re already halfway to a more accurate measure of time.

Even beyond the events you can configure for your GA4 property, Google sends some automatic events. One of these automatic events is a user_engagement event that is dispatched with the page onunload event. This means that Google Analytics understands if a user closes their browser or navigates away from the page, giving us another layer of insight into how users engage with your website that was never available in GA3.

Now let’s compare the two with real numbers. In GA3, if someone opened your webpage, browsed for 1 minute, then spent 30 minutes on another website before coming back to your website and visiting a second page. After 10 minutes on the second page, they exit the website. With GA3, their average session duration and their average time on page would be 31 minutes. In GA4, the session engagement time (the time your website was in the foreground) would be 1 minute and the average session duration would be 11 minutes (1 minute on the first page, plus 10 minutes on the second page).

Below is a comparison of the two time-based metrics in Universal Analytics (GA3) compared to GA4’s time metrics. GA4 released the average session duration metric on November 29, 2022.

Average Time on PageAverage Session DurationAverage Engagement TimeAverage Session Duration
GA3GA3GA4GA4
The timestamp of one pageview, subtracted from the timestamp of the subsequent pageview.
If there is no subsequent pageview, the time on page will be measured as 0.		The average duration (in seconds) of users’ sessions, regardless if your webpage is in the foreground or background.
This excludes the time on page for the last visited webpage.		The average time that your webpage is in the foreground. The average duration (in seconds) of users’ sessions, measured from the initial session start to the unload event.

Based on the differences in measurement, it is highly likely that your average session duration will increase when you switch to GA4 due to the underreporting in GA3. As such, I highly recommend you don’t compare the two numbers.

Summary

Time measurement is another major upgrade you can expect from GA4, giving you more insight into which content actually engages users. GA4 is continuously rolling out new features. Learn more about GA4 reporting metrics with the blog articles below:

Comparing Engagement Rate in GA4 and Bounce Rate in GA3

Google Analytics 4 (GA4) is replacing Universal Analytics (GA3). To prepare everyone for the change, I’ve created a series of blog posts to help users understand the difference between the two versions. Today I’m comparing the difference between engagement rate in GA4 and bounce rate in Universal Analytics.

How Bounce Rate Was Calculated In Universal Analytics

Every time data was sent to Universal Analytics (GA3), it was called a “hit.” There were different types of hits, such as page hits, event hits, and ecommerce hits. Pageviews (page hits) and events (event hits) by default in GA3 were counted as an “interaction” hit. In contrast to a “non-interaction” hit, an interaction hit signifies to Google that the action occurred was of significance. Whenever a user only has one interaction hit in their session, it’s considered a bounce – someone left your website without completing two significant interactions. As a result, bounce rate is the percentage of sessions that did not have a second interaction hit.

Based on this calculation, any Google Analytics account owner who had a large amount of event tracking on their website would naturally have a lower bounce rate. Account owners that did not implement any custom event tracking would naturally have a higher bounce rate.

How Engagement Rate in GA4 Is Different

When GA4 was first released, bounce rate wasn’t even included as a metric. This was done in an effort to put the focus on customers who actively consuming your website and contributing to your bottom line instead of focusing on users who abandoned your website. In short, GA4’s focus was all about engagement.

Unlike bounces, engagements had stricter rules. A session can only be considered engaged if a user had 2+ pageviews, a conversion, or a time threshold of your choosing, ranging from 10 to 60 seconds. This means that you can’t add event tracking in GA4 to lower your bounce rate, unless you count that event as a conversion. 

Engagement rate is the rate of engaged sessions over total sessions. Due to increasing public pressure, Google finally released bounce rate in July 2022. However, the calculation is slightly different from the definition in Universal Analytics. In GA4 bounce rate is now just 1 – engagement rate.

Because bounce rate was so easy to inflate in Universal Analytics, if you had a super low bounce rate in Universal Analytics, don’t be surprised if it gets higher when you make the transition to GA4. Inversely, if your bounce rate was incredibly high in Universal Analytics, don’t be surprised if it lowers in GA4.

Looking Beyond Engagement Rate – Active Users & Session Engagement Time in GA4

Engagement within GA4 didn’t stop at engagement rate. Google also used this concept to help define two new dimensions – active users and session engagement time. The active users dimension describes those users who have had an engaged session at any point. This metric is helpful if you’re trying to separate out bot traffic from actual users.

Session engagement time sounds very similar to average session duration, but it’s important not to confuse the two metrics. Unlike Universal Analytics, GA4 is able to measure when a user closes their tab, navigates to another website, or reloads the current page. More simply, Google knows when you’re actively engaging with a website versus when that website is in the background. GA4 uses this information to give us session engagement time – the time a user actively had your website in the foreground.

Summary

The shift from bounce rate to engagement rate is a big one, but a good one. Lean into the change and begin focusing on users who are driving your bottom line with engagement related metrics. GA4 is continuously rolling out new features. Learn more about GA4 reporting metrics with the blog articles below:

When to Use Funnels vs. When to Use Path Exploration in GA4

Google Analytics 4 (GA4) is replacing Universal Analytics (GA3). To prepare everyone for the change, I’ve created a series of blog posts to help users understand the difference between the two versions. Today’s post is a brief comparison of the Funnel report and the Path Exploration report in GA4. Both reports provide you with insight into a customer’s journey throughout your website; however, there are times when it’s better to use one report over the other.

9 Reasons to Use the Path Explorations Report 

  1. I want to learn more about the customer journey in general, regardless of whether someone completes the action I want them to complete. 
  2. I want to see when someone starts and ends a session throughout their journey on my website. 
  3. I have a specific ending point I want for a user, but not necessarily a specific starting point. 
  4. I want to learn about the wide variety of paths someone took to complete a desired action. 
  5. I have a specific starting point I want for a user, but not necessarily a specific ending point. 
  6. When looking at how a user progresses through the website, I want to easily switch between visualizations of different breakdowns. 
  7. I want to see the count of events, not just active users. If one user completes an event twenty times, that’s okay with me. 
  8. I want to compare how the total users progress through the website and compare it to active users. I realize this may include some bot traffic.
  9. I want to see where someone goes on my website whenever they’re not completing the action I want them to.

9 Reasons to Use the Funnel Report 

  1. I have a specific list of actions I want a user to complete in a specific order. 
  2. I want to quantify drop offs in a multi-step process by pulling metrics such as abandonment rate and completion rate. 
  3. The analytics terminology sometimes loses me – I want to change the name of “Step 3” to “Fill Out Name” in my report. 
  4. I want to understand how drop off in a multi-step process differs between session campaigns. 
  5. I want to understand how drop off in a multi-step process differs between session sources. 
  6. I want to understand how drop off in a multi-step process differs between first acquisition campaigns. 
  7. I want to see the time elapsed between each step in a multi-step process, even though it may extend beyond one session. 
  8. I want to timebox my desired actions – I only care about people that went from Step 1 to Step 2 in a certain about of time. 
  9. I want to see an exact date that drop offs in a multi-step process sharply increased or decreased.

Summary

The Path Exploration report and the Funnel report have a lot of overlapping features. Still, it’s important to know why you default to using one report instead of the other. GA4 is continuously rolling out new features. Check back for updates or dive into other comparisons of Universal Analytics and GA4.

4 Reasons You Shouldn’t Use Google Analytics UX Metrics

I heart Google Analytics. Really. There is so much benefit in using it across departments to understand gaps in your content, design, development, and user experience. However, as versatile as Google Analytics may be, in some cases it’s better used as a supplemental diagnostic tool instead of your primary diagnostic tool. Given the overabundance of articles that highlight “X Ways You Can Use Google Analytics to Improve UX,” I wanted to provide a different viewpoint – 4 Reasons You Shouldn’t Use Google Analytics UX Metrics”

You Can’t Accurately Tell Demographics

Google Analytics launched the Demographic and Interests reports in 2013. These reports allowed you to see user demographics by enabling advertising reporting features for your Google Analytics property. Google collects demographic information three ways: Third-party DoubleClick cookie, Android Advertising ID, or IDFA (for users who specifically opt in or haven’t yet upgraded to iOS 14). With the continuing deprecation of third-party cookies and the increasing privacy restrictions around mobile device identifiers, it’s important to note that this reporting only shows a subset of your users. Even in Google’s test Google Analytics property, reporting shows for 40% of all users.

The fact that you’re only receiving a portion of demographic information doesn’t seem completely detrimental to your UX analysis. However, having that extra demographic information can be beneficial. As personalization comes to the forefront of every marketer’s roadmap, understanding how user behavior differs between segments will allow you to provide more meaningful personalization and a more meaningful A/B testing roadmap. A tool specifically designed to measure UX may offer the user the ability to self-identify, giving you that granular segmentation data.

Scroll Depth Doesn’t Allow for Analysis At Scale 

Scroll depth is one of GA4’s enhanced measurement metrics. Enhanced measurement means this particular reporting feature can be enabled with just the click of a button. This dimension gives marketers a layer of insight they never had before with no additional coding, but it has limitations. With enhanced measurement, the scroll depth event will only fire when a user has reached 90% of the way down a page. While this doesn’t render the feature completely useless, it doesn’t give you any indication of people actively engaged and willing to scroll 60% or 80% the way through your content. 

The 90% limitation also makes UX analysis at scale a little tricky. For example, 90% of a page scrolled on desktop may only be 50% of the same page scrolled through on mobile. Even within mobile devices, content on your iPhone pro-max will look a little different than your iPhone mini. This issue gets compounded with your different content lengths. While some pieces of your content are lengthy 1,000+ word blog articles, other content pieces could be your short and succinct 250 word “Contact” page. 

Before I go further, I’d like to demonstrate the context word count adds with a chart. Below are four blog posts and the percentage of users who scrolled 90% of the way down the page.

Page NamePercent of users who 90% Scrolled (Desktop)Percent of users who 90% Scrolled (Mobile)
/blog-post-185%70%
/blog-post-230%15%
/blog-post-340%20%
/blog-post-475%65%

Based on the data, you’d say that blog posts 2 and 3 are uninteresting to users. This may not necessarily be the case, though. Let’s look at the same data set with a “Word Count” column.

Page NameWord CountPercent of users who 90% Scrolled (Desktop)Percent of users who 90% Scrolled (Mobile)
/blog-post-1250 words85%70%
/blog-post-21,000 words30%15%
/blog-post-3900 words40%20%
/blog-post-4400 words75%65%

Unlike the first chart, it’s obvious to see that users don’t like to read more than 400 words. The length gave us additional context on the user experience not built into Google Analytics UX metrics. 

Now, in order to get around the first two issues with the scroll depth event, it’s possible to build your own custom scroll event (you’d have to anyways if you were using a Single Page Application like react). It’s also possible to add a custom dimension that t-shirt sizes your articles (small, medium, large, etc.). These custom events will get you closer to understanding how people consume your content, but it still leaves a gap when analyzing the UX on your page. 

What if people spend 4 minutes on paragraph five and 6 seconds on paragraph two? Where did people stop reading your content? Do they always leave the page when your Newsletter Subscription pop up appears? Are the ads in the middle of your blog article a deterrent? Unfortunately, these aggregated UX insights can’t be built into Google Analytics UX metrics.

Average Time on Page Is Unusable

I wrote another blog post comparing the measurement of time in GA3 vs. GA4. To calculate the average time on page metric in GA3, Google would subtract the time you visited page 1 from the time you visited page 2. The inherent flaw was that Google Analytics had no way of measuring the time someone spent on your exit page because there was no subsequent pageview from which to subtract. This flaw meant average time on page was always underreported or not reported at all.

While GA4 stepped up their game in how they measured time, average time on page, at the time of writing this, is still inaccessible to the average user with the GA4 interface. Advanced users who have knowledge of BigQuery can calculate the difference between pageview timestamps, but those without SQL knowledge have to use built-in GA4 metrics, like engagement rate.

In GA4, engaged users are ones who a) had a visit longer than 10 seconds b) visited 2+ pages or c) completed a conversion event. This metric doesn’t allow for more granular UX analysis, though. You’re either engaged or you’re not. A user who commits to reading your blog for 11 seconds is considered just as “engaged” as a user who reads your blog for 10 minutes. Instead of relying on time metrics in Google Analytics, a heatmapping software can provide more accurate UX metrics.

Unable to Determine Where Clicks Occurred

Within Google Tag Manager, you can fire a Google Analytics event on every single click that happens on your website. This is powerful for those analysts who get the question “How many people clicked this random button on this specific page?”. This feature is supercharged when developers standardize their code and you insert dynamic variables into your event names, such as link text, button classes, IDs, and form elements into those events. 

As much data as the All Click Events tag collects, it has limitations when trying to perform aggregated reporting on UX metrics. The main limitation is that users don’t always click within specific buttons or areas of your website. This is best illustrated with an example. If you have a large image on your homepage (your website hero), it could have a standardized class of “class=background.” Because your hero is such a large image though, you won’t be able to tell the difference between a click in the top left of the hero and the bottom right of the hero. 

Another example of the limitations faced with click tracking is when users try and click on text on your website. If someone is trying to click on text within a paragraph that isn’t clickable, your event tracking would only show that someone clicked on the paragraph, not that a specific word is misleading someone into thinking it’s a link. In contrast, using a heatmapping tool will give you a better picture of where people are clicking, faster, with less work.

Summary

Google Analytics is a fantastic tool, but take caution when using it to analyze your user experience. The lack of segmentation, aggregation, context, and granular insights can mislead you into thinking something is working, when it’s actually hurting the customer experience and your website conversion rate. I recommend always supplementing your Google Analytics data with a heatmapping tool like Hotjar to resolve the gaps in data mentioned above and help give you a more holistic view of user experience on your website. I’ve used both the free and business plans for over 6 years now, and I’m proud to now be part of their partner program. Sign up for Hotjar using this link and get an extended business trial. By signing up using this link, I may receive a commission at no cost to you.

Why Is An Old Google Analytics Code Bad?

I’ve been in the world of SEO for nearly seven years now, becoming a self-proclaimed expert Googler on everything from Excel formulas to home improvement hacks. However, when faced with the challenge of telling a client why having Classic Google Analytics on their website was not optimal, the only search terms that came to mind were “Why Is An Old Google Analytics Code Bad?” 

After my ever-so-sophisticated search, I found myself getting lost in Google Analytics developer documents that were way over my head and articles that hadn’t been updated since Universal Analytics first made its debut out of beta. My loss, however, is your gain.

This guide will give you a high-level look at the different iterations of Google Analytics and why you really should update your Google Analytics code. If you’re looking for a detailed Google Analytics timeline, I highly recommend this Google Analytics article by BCS Blog.

Google Analytics Infancy: Urchin + Google

Google Analytics did not start at Google. It was started by Urchin Software Corp, which Google acquired in 2005. If the name “Urchin” sounds familiar, that’s because it should. Urchin is the “U” in UTM Coding (you can read more about UTM Coding here).  

How Can I Tell If I’m Using urchin.js?

The easiest way to see if you’re using Urchin is to search the source code for google-analytics.com/urchin.js– don’t be surprised if you don’t find it, though. BuiltWith estimates that only 7,212websites still use Urchin for their analytics.

Google Analytics Childhood: Classic (Legacy) Google Analytics

In April 2007, Google released the first version of ga.js, a synchronous script that was faster, more secure, and gave users access to more features than its Urchin predecessor. In addition to the library released in 2007, there were two ga.js upgrades released in 2009 and 2012. In 2009, Google updated the tracking script to be asynchronous, preventing it from slowing down other resources on a website. In 2012, Google updated the ga.js script to allow for better targeting of Display ads. All versions of ga.js are now referred to as Classic Google Analytics or Legacy Google Analytics because the library is now a legacy library.

How Can I Tell If I’m Using Classic Analytics?

The easiest way to see if you’re using Legacy Google Analytics is to search the source code for google-analytics.com/ga.js. BuiltWith estimates that 6.8 millionwebsites still use Legacy Google Analytics. If you deploy your Google Analytics code through Tag Manager, check inside Tag Manager for a Classic Google Analytics tag.

Classic Google Analytics in Google Tag Manager

Why Should I Change from urchin.js to ga.js?

Note: MoreVisibility wrote an excellent article on this that goes into this in much more detail. I highly recommend checking it out here:

  1. Faster.When implementing your tracking script, you’ll notice that both the Urchin and Google Analytics code reference a script source. When you load urchin.js (https://www.google-analytics.com/urchin.js), you’ll notice the code is near 700 lines. In contrast, when you load ga.js (https://www.google-analytics.com/ga.js), you’ll notice the code is much smaller – only 84 lines!
  2. More Secure.Google Analytics doesn’t store any PII (Personally Identifiable Information). However, it does need to distinguish User 1 from User 2. By increasing the safety of their namespace, this means it’s harder for Google to tell that you’re you.
  3. Access to More Features.  Event tracking, real-time reporting, multi-channel funnels, flow visualizations, data import, custom alerts, custom reports, and data import are a few of the new features that came with the migration to Classic Google Analytics. 

Google Analytics Adolescence: Universal Analytics

Although we may use Universal Analytics and Google Analytics interchangeably now, Universal Analytics was considered very different from previous iterations of Google Analytics when it was first announced in October 2012 and then released from Beta in March 2013. Universal Analytics opened up a world of possibilities for website owners and allowed for more customization of our website analytics than ever before.

How Can I Tell If I’m Using Universal Analytics?

Much like Classic Google Analytics, there are two ways to check if you’re using Universal Analytics. The first way is to see if you’re using Universal Analytics is to check if you have the Universal Analytics tag within Google Tag Manager.

Universal Analytics in Google Tag Manager

If your Analytics account is more than six years old, there’s a strong chance you started with Classic Google Analytics. If this is the case, your transition would be a two-step process, and you’ll want to check more than your website code. When you open up the Google Analytics interface, you want to make sure it doesn’t give you a warning that the Universal Analytics transfer hasn’t started. If you don’t see the warning below, you’re good to go!

Image courtesy of Google

Why Should I Change from ga.js to analytics.js?

With the release of analytics.js, Google not only allowed users more configuration of existing elements but also more advanced integrations with offline data.

  1. Adjust Your Time Outs & Exclusions: With analytics.js, you get to customize the time outs for your campaigns and your sessions. By default, a campaign times out at six months, and a session times out at 30 minutes. You also get to add search engines so it doesn’t appear as referral traffic, exclude search terms so the traffic is attributed as direct instead, and exclude referral sources so you can better prevent self-referrals. 
  2. Better Tracking Across Domains: In Classic Google Analytics, tracking across subdomains required additional configuration because the Google Analytics cookie wasn’t set to the highest possible level. Google fixed this with the automatic cookie domain configuration in Universal Analytics, and now users can track across subdomains without any extra work. 
  3. Better Tracking Across Devices: The introduction of the User-ID allowed any website with a login to start tracking users across devices. While you still needed a developer to implement this feature, this gave a better picture of the customer journey.
  4. More Custom Data, Less Manual Work: Classic Google Analytics gave us data import and custom variables. Universal Analytics gave us V2 of those features. With the measurement protocol, we wouldn’t have to manually import outside data anymore, it could be done via a feed. Universal Analytics also transformed custom variables into custom metrics and custom dimensions, which meant easier reporting and easier implementation for website owners (a nice custom variables vs. custom dimensions list can be found here).

Google Analytics Awkward Post-Grad Years: Global Site Tag

A history of Google Analytics wouldn’t be complete without talking about gtag.js, the fourth library used by Google Analytics. This library was released in beta in August 2017 and is now the recommended Google Analytics library, unless you’re deploying Google Analytics through Google Tag Manager.

Admitted author bias: When I discovered the benefits of deploying my tags through Google Tag Manager, I ignored any new Google Analytics libraries. After looking at BuiltWith trends, however, it appears I am in the minority. 12.2 million websites use the Global Site Tag, while only 9.3 million websites use Google Tag Manager. If you are hesitant to switch over to Google Tag Manager, I totally understand, but I implore you to dig deep within and find the courage to make the switch. Even Google recommends Google Tag Manager over the Global Site Tag. I have an introductory piece on GTM here that should make it a little less scary.

How Can I Tell If I’m Using the Global Site Tag?

The easiest way to see if you’re using the Global Site Tag is to search the source code for www.googletagmanager.com/gtag/js.

Why Should I Change from analytics.js to gtag.js?

Again, I really recommend you go straight to Google Tag Manager, but if you insist on carrying on without it, I can’t stop you. Here’s why gtag.js could be a nice upgrade from analytics.js for you:

  1. One Tag For All Google Products: Unlike previous libraries, gtag.js isn’t a library solely for Google Analytics. Rather it’s a wrapper library that contains your analytics.js (Google Analytics) script, your conversion.js (Google Ads) script, and other Google scripts. This helps consolidate tracking because now all Google products will use the same event command.
  2. Grouping For Multiple Websites: The Global Site Tag makes it easier to send analytics hits to multiple accounts at once without duplicating tags, by providing a feature called “grouping.” Grouping is exactly what it sounds like – you can place multiple accounts into one group and can instruct Google to send hits to everyone in that group.
  3. DataLayer: The dataLayer was previously only used by one Google product –  Google Tag Manager. With the introduction of the Global Site Tag, the vendor-agnostic data container is now available to a wider audience, and developers can now avoid the DOM scraping that was previously needed to achieve the same results.

Summary

Outdated code is not only less reliable, but it often means you miss out on new and cool features. If you’re still currently using urchin.js, ga.js, or analytics.js, there’s reason to upgrade to the latest implementation of Google Analytics, whether its through the use of the Global Site Tag or Google Tag Manager. Both will help better prepare you for the next iteration of Google Analytics, Google Analytics 4, which was released in beta in October 2020.

Can I Use CIDR Notation in Google Analytics?

 

In your quest for the utmost data integrity, you’ve begun to filter out IP addresses. Filtering our IP addresses is a simple but effective way of making sure that your dataset is as accurate as possible. But what happens when your IT team gives you an IP range you don’t recognize? Read below to see how to handle IP addresses with slashes in them (CIDR notation) in Google Analytics. 

IP Addresses with Slashes: CIDR For Dummies 

The IP range that you’re probably used to seeing is something like XXX.XXX.XXX.XXX, where each XXX is what’s called a “class.” The first XXX is class A, the second class B, the third class C and the fourth class D. Each class contains a number 1-255. 

For those of us at home, we most likely have only one IP address. Your single IP address might look something like this: 10.0.0.0. For larger organizations, it’s likely that you have a range of IP addresses. The range for your organization could look something like this: 10.0.0.0-10.0.0.255. 

As you can guess, this number is a pain to write over and over, so it’s no wonder that developers created a shorthand for ranges like this called CIDR. CIDR (pronounced cider) stands for Classless Inter-Domain Routing. 

Truthfully, CIDR is more complex than I’m making it out to be. More than just a nice shorthand, CIDR was developed as a new way to allow network administrators more flexibility when assigning IP addresses. This flexibility was important in making sure that there weren’t unused IP addresses like there was before. In our example above, the IP range would be abbreviated as 10.0.0/24. 

Does Google Analytics Support CIDR? 

As of right now, no Google does not support CIDR. 

How To Handle CIDR in Google Analytics 

While CIDR notation helps network administrators lighten their workload, it adds a little bit to our workload. First, you’ll need to convert your CIDR notation into a range of IP addresses. 

Your next step is to take your range and convert it to RegEx, which Google does support. I personally like this website because it does both for you in one step: https://d-fault.nl/CIDRtoRegEx. If you’re unfamiliar with RegEx, I’ve got a handy article on regex 101 here. 

Summary 

If your IT team gives you an IP address range that has a slash in it, don’t place it directly into Google Analytics. You’ll want to convert the CIDR notation (IP addresses with slashes) to RegEx so that Google can understand it and you can make sure you’re filtering out the right IP addresses. 

 

Stay in the know with email updates!

* indicates required

What Kind of Regular Expression Engine Does Google Analytics Use and Can I Use Negative Regex in Google Analytics?

 

You’ve started delving into regex. You either (understand it)|(don\’t understand it), but chances are, if you were able to read that joke, you’re in the know. Congrats! Now that you know a little bit about regex and how it works, you’re probably wondering how you can apply it to Google Analytics, Google Tag Manager, Google Data Studio, and any other Google product you can get your hands on. 

While your basic knowledge of regex will no doubt take you far, if you start to get more in depth into regex, you’ll need to know your limitations when it comes to Google products. I’ll start off with a background on regex, so easy a caveman could understand it! Then I’ll go into what kind of regular expression Google uses and whether or not you can use negative regular expressions in Google Analytics goals. 

An Introduction to Regex Commonly Used Terms 

A long, long time ago in a world very far away, I thought there was only one type of regex. Boy was I wrong. As I began reading more and more, I was running into words like regex flavors, regex engines, and regex syntax. After hours and hours of research, I think the best way to explain regex flavors, regex engines, and regex syntax is with pets. 

Disclaimer: With the below metaphor, we’re going to have to assume that there are no outliers among dogs. That’s right, your dog who acts like a cat, your calm Jack Russell terrier, and your golden retriever who absolutely hates people all don’t count here. 

I love dogs. There are many different breeds of dogs. I love regex. There are many different flavors of regex. Each breed of dog has a different look. Some have long hair that you have to groom constantly, others have short oily hair, some coats are all one color, while other coats are different colors.

Overall, dogs have four legs, a tail, paws, and similar body shapes. That’s not to say a Great Dane looks like a Maltese, but from far away you can tell they’re both dogs.  Regular expressions, similarly, have different syntaxes. That is to say, some have long hair that you have to groom constantly…just kidding. In all seriousness though, although the regex can be arranged differently, you still can kind of tell from afar that it’s a regular expression. 

In addition to looking different, different breeds have different characteristics. A Jack Russell Terrier has more energy than a bulldog, golden retrievers are known for being incredibly kid friendly, beagles howl something wonderful/terrible and still other breeds of dogs are known for being a little bit more particular about who they choose to get along with. Often when describing a breed, you’re also describing the way they act and look. When I mention that I have a chocolate lab, you understand that it is brown in color, approximately 60 – 70 lbs., and loves water. In the same way that breeds have characteristics, different regular expression flavors support different behaviors. 

In the beginning we associated dog breeds with flavors of regex, but we didn’t get into the technical definition. The technical definition of a flavor is the syntax and behavior supported by a particular regex engine, where a regex engine is just the “machine” that processes the regex. Going back to our dog example, each breed is going to look a different way and have different characteristics.

Unfortunately for my extended metaphor, there’s no way to compare a regular expression engine to a dog. A regular expression engine is what actually processes your regular expression.

I’m going to finish my metaphor with a common-sense reminder. Some breeds don’t get along with other breeds. There’s a reason why there’s a big dog section and a small dog section in every dog park. Sure, some can live in harmony with each other (we’ve all seen that one little dog that just loves to play with big dogs), but others can’t. Similarly, different regular expressions are not always compatible with each other. 

What kind of regular expression does Google Analytics use? 

This is the kind of question that you don’t care about until you need to know the answer and can’t find any Google help document to guide you to it. Google’s regular expression engine of choice is RE2, sometimes referred to as ‘golang’ regex. If you’re using very simple regular expressions, this doesn’t matter. Here’s why it became a problem for me though: it doesn’t support negative regular expressions. 

For example, if you’re setting up a destination goal and you want to capture any time someone submits a thank you form, EXCEPT for the help/support thank you form, you are sore out of luck. RE2 does not support negative regular expressions at the time of writing this article. So if you’re looking for the answer for “Can I exclude something with Regex in Google Analytics Goals?” The answer is no. 

Summary 

A regular expression engine is the actual processor of your regular expression. The syntax is how your regular expression looks and the flavor is a combination of the syntax and the different behaviors associated with a regular expression engine. Unfortunately, the flavor used by Google Analytics doesn’t support negative regular expressions, so you can’t use negative regular expressions in your Google Analytics goals. 

 

Stay in the know with email updates!

* indicates required

How Do I Name My Event Tracking?

Now that you know what event tracking is and what you should and shouldn’t be tracking, the next step is to start setting up naming conventions for your event tracking. Each event consists of three to four attributes – a category, an action, a label, and sometimes a value. Selecting the right naming conventions is important for both organization and setting up any event-based goals in Google Analytics, so I’ve outlined pointers for each of the three mandatory attributes and a friendly word of caution. 

Naming Your Event Category 

A category should be a broad attribute, able to cover a number of different interactions. For example, if on your website you’re tracking email clicks, phone calls, and a form submission, a good category might be “Contact.” Another example is if on your website you’re tracking two different sales inquiry forms, a general contact form and a support form, a good category might be “Form.” 

You’ll see that in both of these examples, each of these categories was able to be applied to three or more types of interactions. While there isn’t a hard and fast rule for the number of interactions that need to fit under your category, aim for both scalability and accuracy. For example, If you know you’re going to have a number of people watching a video on your website, the best category may be simply “Video” 

Naming Your Event Action 

The next attribute you’ll need to assign to your event is an action. Many people default to the standard action of “click,” but I want to remind you that there are more actions to complete on your website than just a click. Someone can buy, call, email, download, watch a video, fail to submit a form, succeed in submitting a form, get directions, click a CTA, click an external link, and more! While there’s more wiggle room to be specific here, my main takeaway is to make sure the name you give your action accurately describes the action the user is performing. 

Naming Your Event Label 

Your label is going to be your most specific attribute. You can specify which video someone watched, which CTA they clicked on, who they emailed, which form they submitted and more. It’s important to get very specific here, because without your specificity, your event tracking may be all for naught.

Depending on the skill of the developer implementing your event tracking (or your own skills with Google Tag Manager), your event label can even contain a user’s response within the checkboxes and radio buttons on your website forms. This can serve especially helpful when you’re looking to retarget users who have filled out a form. 

Don’t Collect Personal Identifiable Information (Collecting PII) 

I mentioned this briefly in my post about what not to track with event tracking, but it’s important to reiterate that when creating your event category, action, and label, you should make sure you don’t store information from any form fields that could hold any personally identifiable information (PII).

First and foremost, collecting PII is against Google’s terms of service, and as a result Google could wipe out all the data in your Google Analytics account. Secondly (although much less important), there are so many other databases, such as marketing automation programs and CRMs that can hold this information in a much more useful way. 

Summary 

Naming your event tracking correctly is key to having useful, actionable data. By ensuring you have a broad enough category, an accurate action, and a specific label, all while avoiding PII, you can help set up your business for scalable data collection. 

Stay in the know with email updates!

* indicates required