The Internet Marketing Driver

How To Use Scroll Depth Tracking, Adjusted Bounce Rate, and Average Time On Page As A Proxy For User Engagement and Content Quality

By Leave a Comment

How to use scroll depth tracking to understand user engagement.

I was helping a company a few months ago that got hit hard by recent algorithm updates. When digging into the audit, there were a number of problems that were surfaced, including content quality problems, technical SEO problems, user experience issues, and more. From a content quality perspective, the site had an interesting situation.

Some of the content was clearly lower-quality and needed to be dealt with. But they also had a tricky issue to figure out. They target a younger audience and a lot of the content was long-form. And I mean really long-form… Some of the articles were over three thousand words in length. I asked my client if they did any type of user testing in the past to determine if their target audience enjoyed their long-form content or if they wanted shorter and tighter articles. It ends up they never ran user testing and didn’t really know their audience’s preference for content length. Like many site owners, they were pretty much guessing that this was the right approach.

The site owner said, “I wish there was a way to determine how far people were getting into the content…” That’s when I responded quickly with “you can do that!” Google Analytics is a powerful tool, but many just use the standard setup. But if you leverage Google Tag Manager, you can set up some pretty interesting things that can be extremely helpful for understanding user engagement.

That’s when I recommended using a three-pronged approach for helping identify user engagement, content consumption, etc. I told my client we could triangulate the data to help identify potential problems content-wise. And the best part is that it doesn’t take long to set up and we used one of the most ubiquitous tools on the market – Google Analytics (with the help of Google Tag Manager).

Note, there’s nothing better than running actual user testing. That’s where you can watch users interacting with your site, receive direct feedback about what they liked or didn’t like, and more. It’s extremely powerful for truly understanding user happiness. But that shouldn’t stop you from leveraging other ways to understand user engagement. What I’ll explain below can be set up today and can provide some useful data about how people are engaging with your content (or not engaging).

Triangulating The Data
The three analytics methods I recommend using to help identify problematic content include Scroll Depth Tracking, Adjusted Bounce Rate (ABR), and then Average Time On Page. I’ll go through each of them below so you can get a feel for how the three can work together to surface potential issues.

Note, there isn’t one metric (or even three) that can 100% tell you if some piece of content is problematic. It’s part art and part science. There are times you can easily surface thin or low-quality content (like thousands of pages across a site that were mistakenly published containing one or two lines of text). But then you have other times where full articles need to be boosted since they are out of date or just not relevant anymore.

Therefore, don’t fully rely on one method to do this… Also, it’s not about word count, it’s about value to the user. Google’s John Mueller has explained this several times over the past few years. Here’s a post from Barry Schwartz covering John’s comments where he explains that it’s about value versus word count. Here’s the tweet that Barry is referring to:

And once you identify potential issues content-wise and dig in, you can figure out the best path forward. That might be to enhance or boost that content, you might decide it should be noindexed, or you might even remove the content (404).

Scroll Depth Tracking
In October of 2017, Google Tag Manager rolled out native scroll depth tracking. And the analytics world rejoiced.

Celebrate Scroll Depth Tracking!

Using scroll depth tracking, you could track how far down each page users were going. And you have control over the triggers percentage-wise. For example, you could track if users make it 10, 25, 50, 75, and then 100 percent down the page. And then you could easily see those metrics in your Google Analytics reporting. Pretty awesome, right?

Setting up scroll depth tracking in Google Tag Manager

For my client, this alone was amazing to see. Again, they wanted to make sure their core audience was reading each long-form article. If they saw that a good percentage of users stopped 25% down the page, then that wouldn’t be optimal… And if that was the case, then my client could adjust their strategy and potentially break those articles up and craft shorter articles moving forward.

I won’t cover the step-by-step instructions for setting up scroll depth tracking since it’s been covered by many people already. Here’s a great post from Simo Ahava on how to set up scroll depth tracking via Google Tag Manager.  It doesn’t take long and you can start collecting data today.

Here is a screenshot of the tag in Google Tag Manager when I set this up. Just remember to set Non-interaction hit to true so scrolling events don’t impact bounce rate. We’ll use Adjusted Bounce Rate (ABR) to address that instead:

Using Google Tag Manager to set up scroll depth tracking.

And here are two example of scroll depth tracking in action. The first is a post where many readers are engaged and a good percentage are making their way down the page. Note, the values are events and not sessions or users. That’s important to understand. Also, the screenshots below are from two different sites and each site owner has chosen different scroll depth thresholds.:

Engaged users via scroll depth tracking.

And on the flipside, here’s a piece of content where many aren’t making their way down the page. It’s a lower quality page that isn’t seeing much engagement at all. There’s clearly much less traffic as well.

Scroll depth tracking showing unengaged users.

Adjusted Bounce Rate (ABR)
Ah, an oldie but goodie. In 2014 I wrote an article about how to set up Adjusted Bounce Rate (ABR) via Google Tag Manager. You can check out that post to learn more about the setup, but ABR is a great way to get a stronger feel for actual bounce rate. My post explains the problems with standard bounce rate, which doesn’t take time on page into account. So standard bounce rate is skewed. ABR, on the other hand, does take time on page into account and you can set whatever threshold you like based on your own content.

For example, if you write longer-form content, then you might want to set the threshold to longer (maybe a minute or longer). But if you write shorter articles, then you might want to set the ABR threshold to shorter (like 30 seconds or less). Once the time threshold is met, Google Analytics will fire an event causing the session to NOT show up as a bounce (even if the person only visits one page).

It’s not uncommon to see Bounce Rate in Google Analytics drop off a cliff once you implement ABR. And that makes complete sense. If someone visits your article and stayed on the page for six minutes, then that shouldn’t really count as a bounce (even if they leave the page without visiting any other pages). The person was definitely engaged. Here’s what that drop looked like for a client that implemented adjusted bounce rate this summer:

Bounce rate drops when adjusted bounce rate is implemented.

Here is an example of two highly-engaged posts of mine about major algorithm updates. The adjusted bounce rate is just 12% for one and 13% for the other. Many people visiting these pages spend a lot of time reading them. So even if that’s the only page they read, it shouldn’t be counted as a bounce.

Adjusted Bounce Rate example

So, now we have two out of three metrics set up for helping gauge user happiness. Next, I’ll cover the third, which is Average Time On Page (a standard metric in Google Analytics). When combining all three, you can better understand if visitors are staying on a page for a certain amount of time, how far they are scrolling down the page, and then how long they are staying overall on that page.

Average Time On Page
I find there’s a lot of confusion about time metrics in Google Analytics. For example, why Average Time On Page might be one time, and then Average Session Length is shorter than that. How can that be? Well, Mike Sullivan from Analytics Edge wrote a post about this a while ago. I recommend reading that article to get a feel for how the metrics work. In a nutshell, Average Time On Page excludes bounces (one-page visits). That’s because Google Analytics needs a page hop to calculate how long somebody remained on a page. Remember, we are setting up scroll depth tracking to be a non-interaction hit, so it won’t impact bounce rate or time metrics

Therefore, Average Time On Page will tell you how long users are staying on a piece of content when they visit another page on the site. Sure, it excludes bounces (so it’s not perfect), but it’s still smart to understand time on page for users that click through to another page on the site.

As an example, here’s my post about the August 1, 2018 algorithm update. The Average Time On Page is 12:48 for the responsive page and 17:52 for the amp version. In web time, that’s an eternity.

Average time on page high for engaged posts.

And on the flip side, here’s a page from a different site that needs some help. It hasn’t been updated in a while and users are identifying that pretty darn quickly. Even for people that click through to another page, the Average Time On Page is just 0:55. That’s a major red flag for the site owner.

Low avg time on page.

Some final tips:
Now that I’ve covered three methods for better understanding user happiness and engagement, I wanted to cover some final tips. Once you are collecting data, you can slice and dice the information in Google Analytics several ways.

  • First, review all three metrics for each piece of content you are analyzing. If you find high adjusted bounce rate, low scroll depth, and low average time on page, then there’s clearly an issue. Dig in to find out what’s going on. Is the content old, is there a relevancy problem based on query, etc.?
  • You might find content where scroll depth looks strong (people are scrolling all the way down the page), but adjusted bounce rate is high. That could mean people are quickly visiting the page, scrolling down to scan what’s there, and then leaving before your ABR time threshold is met. That could signal a big relevancy problem.
  • You can use segments to isolate organic search traffic to see how users from Google organic are engaging with your content. Then you can compare that to other traffic sources if you want.
  • You can also segment mobile users and view that data against desktop. There may be some interesting findings there from a mobile perspective.
  • Heck, you could even create very specific segments to understand how each one is engaging with your content. For example, you could create a segment of female visitors ages 18-34 and compare that to male users. Segments in Google Analytics can be extremely powerful. I recommend reviewing that topic in detail (beyond just what I’m covering today with scroll depth tracking, ABR, etc.)

Summary – Using Analytics As A Proxy For User Engagement, User Happiness, and Content Quality
I always recommend conducting user studies to truly find out what your target audience thinks about your content. You can watch how they engage with your content while also receiving direct feedback about what they liked or didn’t like as they browse your site. But you can also use analytics as a proxy for engagement and user happiness (which can help you identify content quality problems or relevancy issues).

By combining the three methods listed above, you can better understand how users are engaging with your content. You’ll know if they are staying for a certain amount of time, how far they are scrolling down each page, and then you’ll see average time on page (excluding bounces). It’s not perfect, but it’s better than guessing.

And once you collect the data, you may very well choose to refine your content strategy. And the beautiful part is that you can start collecting data today. So go ahead and set up scroll depth tracking and adjusted bounce rate. Then combine that with average time on page so you can use the three-pronged approach I covered in this post. Leverage the power of Google Analytics and Google Tag Manager (GTM). You never know what you’re going to find.

GG

 

Measuring Infinity – How to identify, analyze, and fix an infinite spaces problem using a powerful SEO software stack

By Leave a Comment

Infinite spaces and SEO.

If you are working on a large-scale site, you need to be very careful that you don’t create infinite spaces. That’s when a site generates a near-endless list of urls that Google can end up crawling. Google does not want to churn through endless urls and it can cause problems on several levels SEO-wise. That’s why they detail infinite spaces in the search console help center and they also wrote a blog post specifically about the problem.

Google can end up wasting resources crawling many urls that are near-identical or low-quality. And that can flood Google’s index with thin and low-quality content.

During a recent audit on a site that has seen massive volatility over the past few years during major algorithm updates, I noticed a certain page type that I thought could be problematic. This was surfaced after the initial crawl (which was just a few hundred thousand urls out of 30+ million indexed). I saw enough of the problematic page type that I flagged it and then decided to dig in further.

The Core Problem: Autogenerating URLs
The core problem with the page type was that the site was autogenerating urls based on site searches, which ended up adding many thin or near-empty pages to the site (that were indexable). And even the urls that did contain some content didn’t really make sense to have on the site since they were so general (and even ridiculous in some cases). This created a near-infinite spaces situation with millions of urls being generated, and many of them with major quality problems.

Infinite spaces creating SEO problems.

I sent through initial findings to my client and we decided to get on a call to discuss the issue, along with a number of other important findings from my initial analysis. After speaking with my client and his tech lead, I found out the problem could be impacting up to 10 million urls. And with the site seeing major volatility during multiple major algorithms updates over the past several years, I couldn’t help but think the infinite spaces problem could be heavily contributing to that volatility.

To Infinity and… Behind? The Plan of Attack:
We quickly decided that I should dig into the situation full-blast to learn more about the autogenerated url problem. I literally left the call and started analyzing the pages using a number of tools. This was a process I’ve used a number of times before, so I thought it would be helpful to write a post covering it. It’s a strong way to use a powerful SEO software stack to surface and analyze an infinite spaces problem.

I’ll provide the process below, along with the SEO tools I used (which include both free and paid tools). The combination enabled me to tell a powerful story quickly and efficiently. My hope is that you can use this process, as well, in case you run across a problem that’s creating infinite spaces.

1) Starting with an enterprise crawl via DeepCrawl and Screaming Frog
The first step was running an enterprise crawl. The site has over 30 million pages indexed, but I almost never start by crawling millions of pages at once. You can definitely get a good feel for a site by crawling a few hundred thousand pages to start, and then perform surgical crawls based on problematic areas you surface. It’s a quicker and smarter way to crawl when you’re just starting an engagement.

The initial enterprise crawl helped surface many thin or near-empty pages, and those urls were the problematic page type I mentioned earlier. When digging into those urls, you could clearly see the infinite spaces problem, how the pages were being crafted, and how they were linking to more and more of the autogenerated urls.

I also ran a smaller crawl using Screaming Frog. I crawled 50K urls just to see what our amphibious friend would surface. And again, you could see the autogenerated results rearing its ugly head. So from a crawling perspective, there was a lot of evidence of the page type spawning many low-quality urls. Next up was to check traffic levels to the site for that page type.

Before moving on, I exported a filtered list of the problematic pages from the crawl data. You can do this in both DeepCrawl and Screaming Frog. You’ll need those urls for a step later in the process. More about that soon.

Export filtered list of urls from DeepCrawl.

2) Google Analytics for trending and landing page data
My next move was to track trending over time to the problem urls to view how much traffic was being delivered there via Google organic search. I wanted to see how many of the pages were low-quality, how many were driving traffic versus the number indexed, was there serious volatility for the page type during major algorithm updates, and so on.

When checking trending overall, there was a clear drop from the February 7, 2017 update (which was a massive update). I wrote a post detailing that update, based on seeing a lot of volatility on sites across industries and countries. And when I isolated the problematic page type, the drop was even more distinct.

Problematic page type getting hammered during Google algorithm update.

To isolate landing pages from Google organic, you can access Acquisition, All Traffic, Source/Medium, and then click on Google/Organic. Then you can dimension by landing page. But note, Google provides sampled data in this report for larger-scale sites. Just keep in mind that you are not seeing all of the data.

Dimension by landing page in Google Analytics.

To view unsampled data, you can access Acquisition, All Traffic, Channels, Organic Search, and then dimension by landing page. But just keep in mind this report contains all organic search traffic and not just Google organic (although Google is a majority of organic search traffic for most sites).

Dimension organic search channel by landing page in Google Analytics.

When checking landing pages from Google organic to the problematic page type, I found only 7K urls that were driving traffic from Google organic. That’s out of hundreds of thousands indexed in just one area of the site. That’s a huge red flag by the way. Google doesn’t believe the content is strong enough to rank and drive traffic to, yet those pages are clogging up the index with many low quality urls. Remember, this problem could be impacting up to 10 million urls when you take the entire site into account.

Export Time:
Also, it was important for me to gather as many landing pages as possible, so I could trigger a subsequent crawl of those urls. Therefore, I exported all of the problematic landing pages from Google Analytics (from organic search) for further analysis. For larger-scale sites, I use Analytics Edge which enables me to tap into the API and export urls in bulk. It’s an amazing solution that I use heavily. I’ve also written several posts about it over the years.

Exporting landing pages from Google Analytics via Analytics Edge.

Optional Step: You can also run a medieval Panda report to see the drop after specific algorithm updates. That will enable you to see the landing pages from organic search seeing the largest drop after the update rolled out. You can often find glaring quality problems on those pages. You can learn more about running a Panda report in my tutorial. And no, it’s not just tied to Panda. It can be used for any traffic drop you are seeing.

Running a Panda report to compare traffic before and after an algorithm update.

3) GSC – The NEW Search Analytics Report (with 16 months of data)
The next step I took was to dig into the new search console reporting. All site owners now have access to the new GSC and it contains some extremely powerful reporting. It’s not complete yet, which is why you also have access to the old GSC at the same time.

First, you now have 16 months of data to analyze in the Performance reporting! That’s a new name for the Search Analytics report from the old GSC. Having 16 months of data is important and can help you view trending over a much longer period of time versus the old GSC (which was limited to just 90 days). You can also compare timeframes over a longer period of time.

If you have an infinite spaces problem, and you can isolate the page type via url structure, then the you can view trending of impressions and clicks over the past 16 months for the page type. That can also help you identify impact during major algorithm updates.

Filtering the Performance report in GSC by url.

Exporting via the Search Analytics API (Using Analytics Edge):
In addition, you can export ALL of your landing pages for that page type via the GSC API. Remember, we’ll need those urls in order to create a master list of urls. I’ll cover the surgical crawl in a later step. Note, the UI in the Performance Report and Search Analytics report only lets you export one thousand urls, which is limiting for larger-scale sites. But using a solution like Analytics Edge enables you to fully export your landing pages. Again, you can read my tutorial to learn more.

Just understand that the Search Analytics API only goes back 90 days for now. I believe Google is working on extending that to the 16-month timeframe soon. But at least you can get a feel for how many landing pages from Google organic fit under the problematic page type that’s creating infinite spaces.

Exporting landing pages from GSC via Analytics Edge.

4) Index Coverage – Excluded and Valid
As part of the new GSC, Google provides one of the most powerful new tools for site owners and SEOs. It’s called Index Coverage and it’s the old Index Status report on steroids. I’m part of the GSC beta group and I’ve been testing this for a while before the official launch. I can tell you, the reporting is packed with actionable data.

For example, you can drill into the pages that are valid and indexed, you can view errors by category, and you can view urls that have been excluded by Google by category. Yes, you are getting a rare view into how Google is treating urls and page types across your site. We have been asking for this type of reporting for a long time and the Index Coverage report delivers – big-time!

For our purposes today, we’ll focus on the Excluded and Valid categories. Since I knew there were many thin and low-quality pages due to the infinite spaces problem, I wanted to see how many were showing as being excluded by Google (essentially letting me know that Google decided to not index the urls for some reason).

It didn’t take long to see the problematic page type showing up in a number of reports. For example, the Soft 404s report had many of the urls in them. That’s because there were many urls being autogenerated without any content.

Excluded urls in the new Index Coverage report in GSC.

In addition, there were many showing up in the “submitted, but not indexed” category. Again, the site is providing the urls to Google (via sitemaps and via the internal navigation), yet Google has decided not to index many of them. It’s just more ammunition to take to your client, internal teams, etc. about the infinite spaces problem (if you need more ammunition).

Beyond the Excluded category, you can check the Valid category in the Index Coverage reporting and filter by the problematic page type to see how many of those pages are indexed.

Valid urls via the new Index Coverage report in GSC.

Export Time: You can export urls per category in the new GSC. That’s awesome, but there are limitations you should be aware of. First, you can only export up to one thousand urls per report (unlike the Search Analytics API, which lets you export the whole enchilada). I would have to check with Google again, but I believe they are working on adding API access for the Index Coverage report. I’ll update this post after finding out more.

Second, your filters don’t stick when exporting, and that’s problematic given what we’re trying to do here. Since we are filtering by page type, it would be awesome for the export to isolate those pages. But it doesn’t right now. All of the top one thousand urls are exported per category versus just the problematic page types. I submitted feedback to the GSC product team about this, so we’ll see if the export functionality changes. But for now, the Index Coverage report is for analyzing the page type, while the Search Analytics API can be used for full exports.

Export limitations in the new GSC.

5) Deduping landing pages, preparing for the surgical crawl
At this point, you should have analyzed trending for the specific page type and you have exported urls along the way. Now it’s time to create a master list of problematic urls so you can perform a surgical crawl. The surgical crawl will enable you to get a close-up view of the problem, along with any other issues plaguing that page type.

Excel is your friend for this task. Create a new spreadsheet and copy all of the worksheets you exported into that document. For example, you’ll use the Move or Copy functionality to copy the worksheet to our new document. Just right click on a worksheet tab and you’ll see “Move or Copy”.

Move and Copy in Excel.

Then create a new worksheet that contains all of the urls listed together. Since there will be overlap, you want to dedupe that list before crawling the urls. Click Data, and the Remove Duplicates. If you have a header row, make sure to check that box. Once you click OK, Excel will remove any duplicate urls. Now you have your final list for the surgical crawl.

Dedupe in Excel.

6) Perform a surgical crawl of JUST problematic urls
Depending on how many urls you have, you can choose to run the crawl via an enterprise crawler like DeepCrawl or via a desktop crawler like Screaming Frog. You could also choose to run a large-scale crawl of all the urls via DeepCrawl while crawling a subset of the urls via Screaming Frog (just to get a look at the urls via both tools).

Once the crawls complete, you can dig into the data to surface problems.

For example, you might (and probably will) find massive quality problems, thin content, empty pages, canonical issues, duplication, and more. And remember, this is just a subset of the total pages indexed for the problematic page type! Again, this is more ammo for your conversation with the various teams at your company or with your client.

Surfacing problems via a surgical crawl.

Next Steps – Preparing for battle and crafting your strategy
At this stage, you should have a boatload of intelligence about your infinite spaces problem. Every step you took will help you document the problem from several angles. And once you convey the situation to your client, dev team, c-level executives, etc., you need to tackle the problem head-on.

That includes deindexing as many of those urls as possible and then stopping the problem from surfacing again. That last part could include multiple steps, including changing functionality on the site and handling the urls via robots.txt. It depends on what you find based on your analysis.

For my situation, there was clearly a problem with the site autogenerating many urls. And only a small fraction of the urls are receiving traffic. Many of those pages are thin or low-quality. And the site can generate a near-endless list of these urls. I’m working with my client now on the final strategy, which will undoubtedly include deindexing many urls, refining functionality on the site that’s creating infinite spaces, and then disallowing urls from being crawled in the future.

But there are some important points to understand about this process. First, watch out for simply disallowing via robots.txt. I know many would move to do that immediately, but that’s not necessarily the best move right out of the gates. If you want to deindex the urls via noindexing or 404s/410s, which you should, then Googlebot wouldn’t be able to see the meta robots tag using noindex (or the 404s/410s) if you disallow via robots.txt.

I recommend keeping the directory open and letting Google deindex them over the long-term. Then you can disallow via robots.txt once they have been removed. That can take a while, so be patient. You can read my case study about removing a rogue subdomain to learn more about that.

Also, if the urls are in specific directories, then you could add those directories to GSC as a property. Then you could use the new Index Coverage and the old Index Status reports to monitor indexation. Many still don’t know that you can add directories as properties in GSC. I recommend doing that.

Monitoring indexation via Index Status in GSC.

XML sitemaps can help:
Also, you could submit xml sitemaps with all the problematic urls you collected and then check the new Index Coverage report for indexation, errors, etc. This is another benefit of exporting and deduping all of the problematic pages from DeepCrawl, Screaming Frog, Google Analytics, Search Analytics in GSC, and then Index Coverage in GSC. It’s totally fine to temporarily submit a sitemap that leads to 404s, 410s, or pages being noindexed. That can help Google with discovery and could lead to quicker deindexation.

Clarifying the Remove URLs Tool in GSC:
You can also choose to remove the urls via the Remove URLs Tool in GSC (especially if they are in a specific directory). But be aware that the Remove URLs tool does not work the way that many think it does. It’s a temporary removal (90 days) and only removes the urls from the search results (and not Google’s index).

Using the Remove URLs Tool in GSC.

You still need to actually remove the pages via 404, 410, or the meta robots tag using noindex for the pages to truly be removed. That’s extremely important to know, or you can end up in the same situation you were in when you started if you don’t handle the urls at the root. For an infinite spaces situation, you could temporarily remove the urls via GSC so they don’t show in the search results, while at the same time handle them on the site via 404s, 410s, or by using the meta robots tag using noindex.

Summary – Don’t let infinite spaces get in your way SEO-wise
Again, creating infinite spaces can be a dangerous thing from an SEO perspective, as Google can end up crawling a near-endless list of low quality, thin, or similar urls. It’s important to surface the problem and the urls being generated in order to properly tackle the situation.

Using a powerful SEO software stack, you can identify, analyze, and then address the problem efficiently. If you feel you have an infinite spaces problem (or might have one), I recommend following the process I provided in this post soon. Don’t let infinite spaces negatively impact your site SEO-wise. You can start today by “measuring infinity”. Good luck.

GG

 

Beyond the UI – How to filter Google Search Console (GSC) data using regular expressions in Google Analytics (GA)

By Leave a Comment

Filtering GSC data in GA.

Yes, it’s possible to filter GSC data using regex. Like many of you, I’ve been asking for regex support in GSC for a long time. But as we know, the search analytics reporting unfortunately only provides basic filters for queries and landing pages. In addition, you can’t export more than one thousand rows in the GSC UI, which is limiting. And… you can’t export just filtered the data (which is a pain in the neck). It’s maddening.

But I’m here to show you a different way to slice and dice GSC data. And it’s been right under your nose the entire time. In this post, I’ll explain how to use regex to filter GSC data by using Google Analytics. And if you follow my Search Engine Land column, then you know I just wrote a post about filtering crawl data using advanced filters. So, you can consider this the sequel to that post. They say the sequel isn’t as good as the original, so let’s see if I can change that. Let’s rock and roll.

Requirement – Connecting GSC and GA
First, in order to do this, you need to connect Google Search Console to Google Analytics. To be honest, you should have done this already, but if you haven’t yet, better late than never. :)

I won’t cover how to connect the two, since there is solid documentation about how to connect them. Once you do, then you’ll begin seeing historical GSC data soon. Then you can start using regex in GA like I’m about to show you below. Note, you will still only be able to see the past ninety days of data. I’m hoping that changes at some point in the future, but we just have ninety days now.

Connecting GSC and GA.

Using regex in GA, it’s available and ready to go.
Once you connect GSC to GA, you will see the reporting under the Acquisition bucket of reports. There is a section labeled Search Console with a “NEW” tag. Within that set of reports, you will see landing pages, countries, devices, and queries. We’ll focus on queries and landing pages reports for this post.

GSC reporting in Google Analytics.

Let’s start by accessing the queries report. Once you click the link in the left navigation, you’ll see your queries listed in the report. Make sure to adjust the date to show you the past ninety days.

GSC Queries report in Google Analytics.

Now we’re ready to slice and dice data via regex. In order to filter the report using a simple text search, you can easily enter some text in the filter box. But don’t stop with a simple text filter. That’s the same type of lame filtering you get in GSC. Let’s take this a step further and use regex. Click the “advanced” link next to the search box to access advanced search filters.

Advanced filtering in Google Analytics.

After clicking the “advanced” link, make sure to keep “Include” and “Search Query” for the first two options, but you should change the next dropdown that defaults to “Containing” to “Matching RegExp”. That will enable you to enter a regular expression versus a simple text search.

Using regular expressions in Google Analytics.

Simple example: Filter queries using pipes (OR)
One of the easiest, but still powerful, regular expressions can be achieved by using pipe characters. A pipe {|} represents “or” in a regex. So if you were trying to filter the list of queries by three different text searches, you could enter them like this:

queryA|queryB|queryC

And when you do, GA will list only the queries in the report that match either of those conditions.

Using pipe characters in regex.

And as you can guess, you don’t need to limit the queries to simple text. You can use any regular expression for each entry in your statement. For example, let’s filter by any query that starts with query A or ends with query B.

Using regex to filter queries that start with or end with keywords.

You can go crazy here, and your own regular expressions will be based on your own analysis. The key point is that you can slice and dice GSC data in GA to your heart’s delight.

Layer on average position.
The other benefit you get when using GA to filter GSC data is the ability to layer on dimensions and/or metrics. Under your GA filters, you’ll see an option for “Add a dimension or metric”. When you click that dropdown, you can add other GSC metrics like Average Position, Clicks, CTR, and Position. So you can create more advanced filters quickly and easily.

Below, I’ll add a metric to a pipe-based regex to show us any query that matches the text we enter AND has an average position of less than 5.

Layering average position on regex filtering.

Layer on clicks and/or impressions.
And you can do the same with clicks or impressions. This will enable you to filter specific queries that also have a minimum or maximum number of impressions or clicks. For example, how about queries that contain certain keywords plus have at least 500 clicks over the past ninety days:

Adding filters for clicks and impressions in GA.

Add exclude vs. include to create advanced filters.
Previously, we kept “Include” as the first option for including the filters we were applying. But you can switch that to “Exclude” to hone your reporting. The exclude option when filtering by regex is powerful and enables you to drill down by excluding queries or landing pages that match your regex. I also mentioned this technique in my Search Engine Land post when explaining how to filter crawl data using DeepCrawl.

Excluding regex to hone reporting.

You can also filter landing pages using regex!
You can use a similar approach for filtering landing page data. If you want to find out if certain page types are gaining impressions and clicks, then you can use regex to surface them. For example, imagine you wanted to find all urls that have a certain parameter.

Filtering landing pages using regex in GA.

Or how about any landing page url containing certain keywords that have more than 3000 impressions?

Filtering landing pages by query and impressions.

You get the picture! The possibilities are endless.

Hunting featured snippets
Let’s go hunting for featured snippets by filtering the report by certain queries and then entering an average position of less than two. Featured snippets will rank #1 in GSC since they hold the top position. That was covered in the help documentation provided by Google about clicks and impressions. But you can enter “Less than 2” versus equaling one since the query will not always rank number one. It simply helps you capture more queries that might be yielding a featured snippet. Here I’m filtering by “how to” or “what is” queries with an average position of less than two.

Filtering for featured snippets in GA.

Export it!
As I mentioned earlier, the GSC UI limits your exports to just one thousand rows. That’s extremely limiting for many sites. In GA, you can export five thousand rows at a time by using the dropdown at the bottom of the report. In addition, you can export in stages by clicking the next page in the pagination and then exporting another five thousand rows. It’s not optimal, but better than an absolute limit of one thousand rows.

Exporting reports using advanced filters in GA.

Summary – Regex is available for GSC data (with the help of GA)
If you’re like me, then you’ve wanted regex support in GSC for a long time. But by using GA, you can essentially get that regex support, but just not in GSC proper. If you need to drill into your data, slice and dice query and landing page data, etc., then I recommend using the approach I listed above. I think you’ll dig it. Now brush up on your regex skills and dig in. :)

GG

 

How To Set Up Adjusted Bounce Rate on Accelerated Mobile Pages (AMP) Using Google Tag Manager

By 4 Comments

Adjusted Bounce Rate (ABR) for AMP Urls

Understanding if people engage with your content is important on several levels (including SEO-wise). For example, if someone searches Google, visits your page, spends 2 seconds on the page, and then returns to the search results, that can send horrible signals to Google. That’s called low dwell time and I’ve mentioned that many times before in my posts about Panda and Phantom.

So, to address the flaws of standard bounce rate, Google wrote a post in 2012 explaining the idea of “adjusted bounce rate” to get a more accurate feel for actual bounce rate. Using adjusted bounce rate (ABR), you can set a desired time threshold and fire an event after that time threshold is met. So if a user stays on the page for at least that amount of time, an event is fired via Google Analytics. And when an event is fired, that session will not be counted as a bounce. Cool workaround, right?

I’ve written several posts about setting up adjusted bounce rate. One covered the topic overall and then another focused on how to implement ABR via Google Tag Manager. But that’s for your standard website. Little did I know at the time another character would be entering the scene. Namely, AMP.

And Along Came AMP
As many of you know, Accelerated Mobile Pages (AMP) is becoming a big deal. Google is pushing AMP hard and many publishers are implementing AMP across their sites. Using AMP, you could create a lightweight version of your content using AMP HTML, Google will cache that page, and then it can be delivered to users on mobile devices very quickly.

The median load time for all AMP delivered by Google is under one second. Yes, in aggregate! That’s super-impressive. By the way, you’ll know a result is AMP when you see the AMP icon (a lightning bolt) in the SERP listing like below. And no, many still don’t’ know that. You can read my post about the quick AMP survey I conducted later. :)

AMP in the Top Stories Carousel:

AMP in Top Stories Carousel

AMP in the “10 Blue Links” (in the Mobile SERPs):

AMP in the 10 Blue Links

AMP Analytics and Google Tag Manager
With the release of AMP, tracking became a little tougher. So the AMP Project launched amp-analytics, which enables you to add tracking scripts from a number of popular analytics packages. That was a great start, but you still had to hack your WordPress theme a little to get everything to work. I know many business owners and webmasters were confused about the setup, and some hadn’t even set up tracking at all!

But then a big announcement was made that would make many people happy. Google Tag Manager now supports AMP! Using GTM, you can centrally manage all tracking scripts and then quickly deploy to all of your pages. So now with AMP, you can set up a separate container in Google Tag Manager, set up tracking tags, and click a button to deploy. Then poof, your latest tracking scripts will be deployed to your AMP urls. Awesome, right?

The announcement about GTM supporting AMP:

Google Tag Manager Now Supports AMP

Adjusted Bounce Rate For AMP URLs
Back to adjusted bounce rate (ABR) for a second. Now that GTM supports AMP, some interesting tracking opportunities were opened up. First, now you can implement adjusted bounce rate on AMP urls! That’s awesome and will enable you to get a stronger feel for true bounce rate. Again, you can set  the time threshold, and if users meet or exceed that time threshold on the AMP url, then an event is fired. Once the event is fired, the session isn’t counted as a bounce.

Below, I’ll walk you through how to set up adjusted bounce rate for your AMP urls. It’s a relatively quick process that will hopefully leave you loving Google Tag Manager, while also providing additional tracking data so you can analyze your accelerated mobile pages! Let’s begin.

How To Implement Adjusted Bounce Rate for AMP Using Google Tag Manager:

  1. Add a new container for AMP
    First, fire up Google Tag Manager and click the Accounts link in the navigation. You will see all of your accounts listed, along with the containers listed within them. Most people organize website or mobile applications by containers (so you will typically have one container per site or app). You need to set up a new container for your AMP tracking. Under the proper account, click the menu selector to the right (three dots) and select “New Container”. Once you do, name the container and select AMP under “Where to use container”.
    Create a container for AMP in Google Tag Manager.
  2. Install the Google Tag Manager (GTM) Code On Your Site
    First, copy the AMP Analytics script and paste it in the <head> of your AMP file. That’s the first snippet of code listed in the screenshot below. And if you’re using the AMP WordPress Plugin, then add the code to the “single.php” file within the AMP plugin. You can find that under Plugins, and then by selecting “Editor”. Then choose the dropdown to select the AMP plugin. Again, the file you are looking for is “single.php” once you select the AMP plugin from the dropdown. See below.
    Editing the AMP plugin single.php file.
    Install GTM code on AMP urls.
  3. Next, Add GTM Code After <body> Tag
    Next, copy the Google Tag Manager code (the bottom snippet from the screenshot above) and paste it right after the opening <body> tag on your page (or in the “single.php” file for the AMP WordPress plugin as mentioned above). Make sure you click Save to ensure the new code you added is saved in the plugin file.
    Adding the GTM code to the single.php file in WordPress.
  4. Set Up Pageview Tracking via GTM (default tracking)
    If you are already using Google Tag Manager to track your AMP urls, then you can skip ahead to step 8. You probably already added a pageview tracking tag when doing that (hopefully). :) If this is the first time you are setting up GTM for AMP, then click the Tags link in the left-side navigation.
    Create a new tag in GTM.
  5. Create A New Tag
    Then click “New” to create a new tag. Under Tag Configuration, click the tag icon and then select “Universal Analytics”.
    Select Universal Analytics tag type.
  6. Name Your Tag and Enter Tracking ID
    First enter a name for the new tag in the upper-left corner. Then enter your tracking ID (UA-XXXX-X) and keep “Page View” as the Track Type.
    Enter tracking ID and track type.
  7. Add A Trigger
    Under “Triggering”, click the trigger icon and select “All Pages”. You want pageview tracking to occur on each page so you can track all of your AMP urls.
    Add an
  8. Create An Adjusted Bounce Rate Tag
    Now let’s create the tag that will track adjusted bounce rate (ABR). Click “New” to create a new tag. Click the tag icon and select “Universal Analytics”. Name your new tag in the upper-left corner and enter your tracking ID. For Track Type, select Event from the dropdown. Then enter the event details, which will show up in GA when the event is fired. For category, you can enter something like “Dwell Time”, the Action could be “30 seconds” (or whatever time you set up), and Label could be “User stayed for X seconds on AMP url.”
    Add event tracking for Adjusted Bounce Rate.
  9. Create A New Trigger
    Under “Triggering”, click the trigger icon in the center of the page. Then click the + icon in the upper-right corner to create a new trigger. Then name the new trigger in the upper-left corner and click the trigger icon once again to set up the new trigger. Select “Timer” from the list of triggers.
    Add a Timer trigger.
  10. Set Timing For ABR
    Under Interval, enter the time to wait before firing the event. Since we’re tracking ABR, we only want to fire this once. So if you wanted to wait 30 seconds, then enter 30 in the Interval field. For Limit, enter the maximum number of seconds you want GA to fire the event. So if you set 30 for interval, I would enter something like 45 to ensure a second event isn’t fired. Also, uncheck “fire immediately when triggered”. This will ensure that GA waits for the selected interval to pass before firing. That’s what we want. And last, make sure “All Pages” is selected at the bottom where it says “This trigger fires on”.
    Enter the timer settings.
  11. Preview and Debug (Kind of…)
    When using Google Tag Manager, you would typically “preview and debug” to test out the tags that are firing before publishing to your site. But for some reason, this is not working for me with AMP. I’ll reach out to some people on the AMP team about this and will update my post when I hear back.So for now, you could click “Publish”, which will deploy your new tags to your AMP urls. Once that’s completed (in a few seconds), you can go and test out your AMP tracking setup.
    Publisher your changes.
  12. Congratulations! (but you’re not done yet…)
    You have deployed adjusted bounce rate tags to your AMP urls, but let’s make sure everything is working as expected.


Testing Your Adjusted Bounce Rate Setup Via Tag Assistant and Real-time Stats
There are several ways you can check to make sure your ABR tag is firing. Google Tag Assistant is a great way to do so! It’s a Chrome extension that enables you to check GA tagging on specific pages, which tags are installed, what’s firing, etc.

If you navigate to an AMP url on your site, you should see Tag Assistant light up with a number that shows how many tags are installed on the page. If you click that icon, then you will see details about pageviews firing, events that are firing, etc.

If you click the Google Analytics tag in Tag Assistant, you will see the pageview that fired, and if you wait 30 seconds (or whatever time you set for adjusted bounce rate), you should see an event fire. If you click that event, you’ll see the category, action, and label. And if you see that, then ABR is working as expected!

Testing ABR in AMP via Google Tag Assistant.

Real-time Stats in GA
Another way to check that ABR is firing on AMP urls is to fire up real-time stats in Google Analytics. Then go visit an AMP page, watch it show up in real-time stats, and then filter by events. Wait for your ABR event to fire and you should see the event show up in the reporting, along with the category, action, and label.

Testing ABR in AMP via Real-time Stats in Google Analytics.

Summary – You Can Now Track Adjusted Bounce Rate for AMP
Although many have set up adjusted bounce rate on their standard websites, there hasn’t been an easy way to do that for AMP. But now that Google Tag Manager supports AMP, you can set up ABR for your AMP urls. Using the approach I listed above, you can track adjusted bounce rate for AMP urls just like your other pages. Once you do, you can get a stronger feel for actual bounce rate on AMP urls (which takes dwell time into account). After checking adjusted bounce rates for AMP pages, you might find users are engaging with your content, or you might find they’re not. But you won’t know until you try. :)

GG

 

How To Bulk Export Top Landing Pages From Google Analytics Using Analytics Edge in Excel

By 10 Comments

Using Analytics Edge For Bulk Exports

I help a lot of companies with website redesigns or CMS migrations (from an SEO standpoint). As part of that process, it’s extremely important to download all of a website’s top landing pages so you can check them in staging and when the redesign or migration goes live. By doing so, you can test the pages to ensure they resolve correctly before you pull the trigger, and then right after you launch. Basically, you can nip serious SEO problems in the bud by crawling those urls.

I also help a lot of large-scale websites with redesigns or migrations. For example, sites with 500K, 1M, or more pages that need to be downloaded, crawled, and analyzed. For situations like that, it’s not simple to export the top landing pages from Google Analytics. Unfortunately, you cannot export urls in bulk from the UI. You are limited to 5K urls per report. Then you would need to click to the next page in the pagination to retrieve the next 5K rows. That’s not efficient, to say the least.

You could also tap into the GA API, but you need programming skills. That’s unless you leverage a tool or plugin that has the functionality built for you. More on that soon. :)

The GA rowCount Hack is Gone
There used to be a hack in Google Analytics that let you manually set the row count in your reports via the url in your browser. I loved that feature, since it enabled me to get around the issue I mentioned above. For example, I could add rowCount%3D15000 in the url, and boom, I had a report with 15K rows of data.

Well, Google Analytics removed the ability to do that and now the most you can get in one batch is five 5K rows. Sure, you can click to the second page of results and keep exporting, but that gets old quickly. Exporting up to 5K pages is fine for some smaller sites, but not if you have hundreds of thousands of pages, or more.

So, wouldn’t it be great if there was some plugin or add-in that could help with this? Well, there is. Read on!

Analytics Edge for Excel
While researching options last year, I came across an Excel add-in called Analytics Edge. The add-in is packed with functionality, including the ability to export pages from Google Analytics with ease. And not just export pages, but export them in bulk! That’s exactly what I was looking for.

Again, the plugin can do many things for you, but I’ll just focus on exporting top landing pages from Google Analytics. If you are going through a redesign or migration, and want to export all of the top landing pages from organic search, then this could be a great solution for you. It has worked extremely well for me.

Note, there is a free version of the add-in that contains the Google Analytics connector. You can also pay more for the “Core” add-in, which gives you even more functionality. The screenshots below are from the core add-in, so you might see slightly different options with the free version. Now let’s get started.

How To Export Top Landing Pages From Google Analytics (Beyond 5K)

1. Download and install the Analytics Edge add-in for Excel. Then register the add-in to get started.

Registering Analytics Edge in Excel

2. Click the Analytics Edge menu at the top of the worksheet to access the various options available to you.

Analytics Edge Ribbon in Excel

3. Click “Free Google Analytics” in the menu and then “Accounts”. You will need to connect the add-in to your Google account so you can access various properties and views in GA. You should enter the account that’s tied to your Google Analytics properties and views. Note, you can add several Google accounts for future access, if needed.

Entering An Account In Analytics Edge

4. Next, click “Free Google Analytics” and then “Analytics Reporting”. A small macro box will show up, which will capture the commands you are using via the add-in. Simply name your macro to move on.

5. Here’s where the magic takes place. This is where you will choose the settings for your new report. First, select a login and then a view. The options will match the Google account(s) you entered previously.

Select GA View in Analytics Edge

6. Next, choose the dimensions and metrics you want to see in your report. For this example, I’ll keep it simple. We’ll choose landing pages, sessions, and bounce rate.

Selecting Dimensions and Metrics in Analytics Edge

7. Instead of clicking finish, let’s select the Dates tab. There are some presets here like “Last 30 Days”, but you can enter a custom date as well. I’ll choose “Last 30 Days” to keep this simple.

Selecting a Date Range in Analytics Edge

8. If you click the “Sort” tab, you can sort by sessions (which is typically what we would want for top landing pages).

Sorting Data in Analytics Edge

9. Last, but not least, we want organic search data for this example. So head over to the “Segments” tab and select “Organic Traffic” in the list. This will limit the data to landing pages from organic search.

Choosing a Segment in Analytics Edge

10. Then click Finish. Analytics Edge will begin pulling the data from Google Analytics. Note, for larger sites, this could take a while. Be patient. You’ll notice the plugin says, “Running…” and you might see the Query Status window showing the number of rows downloaded.

Analytics Edge Query Status

11. Once completed, you’ll see a “Step Results” worksheet filled with data. You’ll also notice there are only 50 records in the sheet. This is where most people freak out and think the plugin screwed up. It didn’t. It’s simply showing you a sample of the data that was pulled. If all looks ok, then you need to write the data to a new worksheet.

Step Results in Analytics Edge

12. To write the data to a new worksheet, you need to click “File” in the Analytics Edge menu, and then “Write Worksheet”. You can name your new worksheet whatever you like and then click OK. Once you do, you’ll notice a new worksheet with all of your data. For the view I used, I retrieved 98K top landing pages from organic search over the past 30 days. Awesome.

Write Worksheet in Analytics Edge

Bonus: The only thing left to do here is to use the concatenate function to build the full url. Once you do, you can export that list and crawl it via Screaming Frog, Deep Crawl, etc. You can read more about checking top landing pages in a recent post of mine. There are some helpful tips in that post once you have a final set of urls.

Finalizing Landing Pages with Concatenation in Excel

Summary – Breaking Through The 5K Limit
For those of you that are working on large-scale sites, the process I documented above can help you export many more urls than you could via the UI in Google Analytics. By using an Excel add-in like Analytics Edge, you can export hundreds of thousands of urls, if needed (and all in one shot.) That will save you time, and your sanity.

So gather your intel now. Then crawl away. It’s a great way to check urls in bulk when going through a redesign or CMS migration. Good luck.

GG