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

 

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 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

 

Panda Analysis Using Google Analytics Segments – How To Isolate Desktop, Mobile, and Tablet Traffic From Google

By Leave a Comment

Segments in Google Analytics to Isolate Traffic

In previous posts about Panda analysis, I’ve mentioned the importance of understanding the content that users are visiting from Google organic. Since Google is measuring user engagement, hunting down those top landing pages can often reveal serious content quality problems.

In addition, I’ve written about understanding the devices being used to access your site from the search results. For example, what’s the breakdown of users by desktop, mobile, and tablets from Google organic? If 50% of your visits are from smartphones, then you absolutely need to analyze your site through that lens. If not, you can miss important problems that users are experiencing while visiting your website. And if left unfixed, those problems can lead to a boatload of horrible engagement signals being sent to Google. And that can lead to serious Panda problems.

Panda Help Via Segments in Google Analytics
So, if you want to analyze your content by desktop, mobile, and tablet users through a Panda lens, what’s the best way to achieve that? Well, there’s an incredibly powerful feature in Google Analytics that I find many webmasters simply don’t use. It’s called segmentation and enables you slice and dice your traffic based on a number of dimensions or metrics.

Segments are non-destructive, meaning that you can apply them to your data and not affect the source of the data. Yes, that means you can’t screw up your reporting. :) In addition, you can apply new segments to previous traffic (they are backwards compatible). So you can build a new segment today and apply it to traffic from six months ago, or longer.

For our purposes today, I’m going to walk you through how to quickly build three new segments. The segments will isolate Google organic traffic from desktop users, mobile users, and tablet users. Then I’ll explain how to use the new segments while analyzing Panda hits.

 

How To Create Segments in Google Analytics
When you fire up Google Analytics, the “All Sessions” segment is automatically applied to your reporting. So yes, you’ve already been using segments without even knowing it. If you click the “All Sessions” segment, you’ll see a list of additional segments you can choose.

Google Analytics All Sessions Segment

You might be surprised to see a number of segments have been built for you already. They are located in the “System” category (accessed via the left side links). For example, “Direct Traffic”, “AdWords”, “Organic Traffic”, and more.

Google Analytics System Segments

 

We are going to build custom segments by copying three system segments and then adding more dimensions. We’ll start by creating a custom segment for mobile traffic from Google organic.

1. Access the system segments by clicking “All Sessions” and then clicking the link labeled “System” (located on the left side of the UI).

 

Google Analytics System Segments

 

2. Scroll down and find the “Mobile Traffic” segment. To the far right, click the “Actions” dropdown. Then choose “Copy” from the list.

 

Copying a System Segment in Google Analytics

 

3. The segment already has “Device Category”, “exactly matches”, and “mobile” as the condition. We are going to add one more condition to the list, which is Google organic traffic. Click the “And” button on the far right. Then choose “Acquisition” and the “Source/Medium” from the dimensions list. Then choose “exactly matches” and select “google/organic” from the list. Note, autocomplete will list the top sources of traffic once you place your cursor in the text box.

 

Creating a Segment by Adding Conditions

 

4. Name your segment “Mobile Google Organic” by using the text box labeled “Segment Name” at the top of the window. It’s easy to miss.

 

Name a Custom Segment in Google Analytics

 

5. Then click “Save” at the bottom of the create segment window.

 

Save a Custom Segment in Google Analytics

 

Congratulations! You just created a custom segment.

 

Create The Tablet Traffic Segment
Now repeat the process listed above to create a custom segment for tablet traffic from Google organic.  You will begin with the system segment for “Tablet Traffic” and then copy it. Then you will add a condition for Google organic as the source and medium.

 

Desktop Traffic (Not a default system segment.)
I held off on explaining the “Desktop Traffic” segment, since there’s an additional step in creating one. For whatever reason, there’s not a system segment for isolating desktop traffic. So, you need to create this segment differently. Don’t worry, it’s still easy to do.

We’ll start with the “Mobile Traffic” segment in the “System” list, copy it, and then refine the condition.

1. Click “All Sessions” and the find “Mobile Traffic” in the “System” list. Click “Actions” to the far right and then click “Copy”.

 

Copying a System Segment in Google Analytics

 

2. The current condition is set for “Device Category” exactly matching “mobile”. We’ll simply change mobile to “desktop”. Delete “mobile” and start typing “desktop”. Then just select the word “desktop” as it shows up.

Creating a Desktop Segment in Google Analytics

 

3. Since we want Desktop traffic from Google Organic, we need to add another condition. You can do this by clicking “And” to the far right, selecting “Acquisition”, and then “Source/Medium” from the dropdown. Then select “exactly matches” and enter “Google/Organic” in the text box. Remember, autocomplete will list the top sources of traffic as you start to type.

 

Creating a Google Organic Desktop Segment in Google Analytics

 

4. Name your segment “Desktop Google Organic” and then click “Save” at the bottom of the segment window to save your new custom segment.

 

Quickly Check Your Segments
OK, at this point you should have three new segments for Google organic traffic from desktop, mobile, and tablets. To ensure you have these segments available, click “All Sessions” at the top of your reporting, and click the “Custom” link on the left. Scroll down and make sure you have all three new segments. Remember, you named them “Desktop Google Organic”, “Mobile Google Organic”, and “Tablet Google Organic”.

If you have them, then you’re good to go. If you don’t, read through the instructions again and create all three segments.

 

Run Panda Reports by Segment
In the past, I’ve explained the importance of running a Panda report in Google Analytics for identifying problematic content. A Panda report isolates landing pages from Google organic that have dropped substantially after a Panda hit. Well, now that you have segments for desktop, mobile, and tablet traffic from Google organic, you can run Panda reports by segment.

For example, click “All Sessions” at the top of your reporting and select “Mobile Google Organic” from the “All” or “Custom” categories. Then visit your “Landing Pages” report under “Behavior” and “Site Content” in the left side menu in GA. Since you have a specific segment active in Google Analytics, the reporting you see will be directly tied to that segment (and filter out any other traffic).

Creating a Google Panda Report Using Custom Segments

 

Then follow the directions in my previous post to run and export the Panda report. You’ll end up with an Excel spreadsheet highlighting top landing pages from mobile devices that dropped significantly after the Panda hit. Then you can dig deeper to better understand the content quality (or engagement) problems impacting those pages.

Combine with Adjusted Bounce Rate (ABR)
User engagement matters for Panda. I’ve documented that point many times in my previous posts about Panda analysis, remediation, and recovery. The more poor engagement signals you send Google, the more bamboo you are building up. And it’s only a matter of time before Panda comes knocking.

So, when analyzing user engagement, many people jump to the almighty Bounce Rate metric to see what’s going on. But here’s the problem. Standard Bounce Rate is flawed. Someone could spend five minutes reading a webpage on your site, leave, and it’s considered a bounce. But that’s not how Google sees it. That would be considered a “long click” to Google and would be absolutely fine.

And this is where Adjusted Bounce Rate shines. If you aren’t familiar with ABR, then read my post about it (including how to implement it). Basically, Adjusted Bounce Rate takes time on page into account and can give you a much stronger view of actual bounce rate. Once you implement ABR, you can check bounce rates for each of the segments you created earlier (and by landing page). Then you can find high ABR pages by segment (desktop, mobile, and tablet traffic).

Combining Adjusted Bounce Rate with Custom Segments

 

Check Devices By Segment (Smartphones and Tablets)
In addition to running a Panda report, you can also check the top devices being used by people searching Google and visiting your website. Then you can analyze that data to see if there are specific problems per device. And if it’s a device that’s heavily used by people visiting your site from Google organic, then you could uncover serious problems that might lie undetected by typical audits.

GA’s mobile reporting is great, but the default reporting is not by traffic source. But using your new segments, you could identify top devices by mobile and tablet traffic from Google organic. And that’s exactly what you need to see when analyzing Panda hits.

Analyzing Devices with Custom Segments in Google Analytics

For example, imagine you saw very high bounce rates (or adjusted bounce rates) for ipad users visiting from Google organic. Or maybe your mobile segment reveals very low engagement from Galaxy S5 users. You could then test your site via those specific devices to uncover rendering problems, usability problems, etc.

 

Summary – Isolate SEO Problems Via Google Analytics Segments
After reading this post, I hope you are ready to jump into Google Analytics to create segments for desktop, mobile, and tablet traffic from Google organic. Once you do, you can analyze all of your reporting through the lens of each segment. And that can enable you to identify potential problems impacting your site from a Panda standpoint. I recommend setting up those segments today and digging into your reporting. You might just find some amazing nuggets of information. Good luck.

GG

 

How To Check If Google Analytics Is Firing On Android Devices Using Remote Debugging With Chrome [Tutorial]

By Leave a Comment

How To Debug Google Analytics on Mobile Devices

We all know that having a strong analytics setup is important. Marketing without measurement is a risky proposition for sure. But in a multi-device world, it’s not as easy to make sure your setup is accurately tracking what you need – or tracking at all. And if your analytics code isn’t firing properly across smartphones, tablets, and desktop computers, your data will be messy, incomplete, and inaccurate. And there’s nothing that drives a marketer crazier than flawed data.

A few weeks ago, Annie Cushing tweeted a quick question to her followers asking how everyone was testing their Google Analytics setup via mobile devices. This is something many digital marketers grapple with, especially when you are trying to track down problems. For example, I do a lot of algorithm update work and often dig into the analytics setup for a site to ensure we are seeing the full drop in traffic, conversion, revenue, etc.

My knee-jerk response was to check real-time reporting in Google Analytics while accessing specific pages to ensure those visits were being tracked, in addition to events. That could work, but it’s not as granular or isolated as you would want. I also mentioned to Annie that using a chrome extension like User Agent Switcher could help. That wouldn’t document the firing of analytics code, but would let you see the source code when accessing a webpage via a specific type of smartphone or tablet. But again, you couldn’t see the actual firing of the code or the events being tracked. And that’s obviously an important aspect to debugging analytics problems.

A Solution – Remote Debugging on Android with Chrome
So I did what I typically do when I run into a tricky situation. I find a solution! And for Android devices, I found a solid one. Many of you might be familiar with Chrome Developer Tools (on your desktop computer). It holds some outstanding functionality for debugging websites and web applications. But although it’s extremely helpful for debugging desktop webpages, it didn’t really address the problem at hand (out of the box), since we want to debug mobile devices.

So I started to research the issue and that’s when I came across a nifty technique which would allow you to connect your Android device to your desktop computer and then debug the Chrome tabs running on your mobile device from your desktop computer. And since I could use Chrome Developer Tools to debug the tabs on my desktop computer, I could check to see if Google Analytics was indeed firing when accessing webpages via my Android device. Awesome.

So, I spent some time testing this out and it does work. Sure, I had to jump through some hoops to get it to run properly, but it finally did work. Below I’ll cover what you’ll need to test this out for yourself and how to overcome some of the problems I encountered. Let’s get started.

 

What You’ll Need
In order to debug GA code running on your mobile device, you’ll need the proper setup both on your desktop computer and on your Android device. In its simplest form, you’ll need:

  • Chrome installed on your desktop (version 32 or later).
  • Android 4.0 or later.
  • A USB Cable to connect your device to your computer.
  • Android SDK {this will not be required for some of you, but others might need to install it. More on that situation below}.

If you run into the problems I ran into, you’ll need the Android SDK installed. I already had it installed since I’ve been testing various Android functionality and code, so it wasn’t a big deal. But you might need to install it on your own. I wouldn’t run to do that just yet, though. If the straight setup works for you, then run with it. If not, then you might need to install the Android SDK.

If you are confident you have the necessary setup listed above, then you can move to the tutorial listed below. I’ll walk you through how to debug Chrome tabs running on your mobile device via Chrome on your desktop computer. And yes, we’ll be isolating Google Analytics code firing on our Android devices to ensure you are tracking what you need.

How To Debug Google Analytics on Your Android Device – Step-By-Step Instructions

  1. Enable USB Debugging on Your Android Device
    Access your settings on your Android device and click Developer Options. On my device, that was located in the more “More” grouping of my settings and under System Manager. If you don’t see Developer Options, then you need to enable it.You can do that by accessing Settings, tapping About Phone or About Device and tapping Build Number seven times. Yes, that sounds extremely cryptic, but that’s what you need to do. Once you do, Developer Options will show up in under System Manager in your phone’s settings.

    Enable USB Debugging on Android Device

    Then you can check the box to enable USB Debugging on your device. You will need to do this in order to debug Google Analytics in Chrome on your device.

  2. Enable USB Discovery in Chrome (on your desktop)
    Next, type chrome:inspect in a new tab in Chrome on your desktop. Ensure “Discover USB devices” is checked on this screen.

    Enable USB Discovery in Chrome Desktop

  3. Connect Your Phone To Your Computer via USB
  4. Allow USB Debugging
    When you connect your phone to your computer, you should see a dialog box on your phone that asks you if you want to allow USB debugging. Click OK. Note, if you don’t see this dialog box, debugging your mobile device from Chrome on your desktop will not work. I provide instructions for getting around this problem later in the tutorial. If you are experiencing this problem, hop down to that section now.

    Allow USB Debugging on Android Device

  5. Fire up Chrome On Your Mobile Device
    Start Chrome on your Android device and access a webpage (any webpage you want to debug).
  6. Inspect With Chrome on your Desktop
    Once you open a webpage in Chrome on your mobile device, access Chrome on your desktop and visit chrome:inspect. Once you do, you should see your device listed and the various tabs that are open in Chrome on your Android device.

    Inspect Chrome Tabs on Desktop Computer

  7. Click Inspect To Debug The Mobile Tab
    When you click “inspect”, you can use Chrome Developer Tools on your desktop to debug the mobile web view. You can use all of the functionality in Chrome Developer Tools to debug the webpage open on your mobile device.
  8. Click the Network Tab in Chrome Developer Tools
    By accessing the Network Tab, you can view all network activity based on the webpage you have loaded in Chrome on your mobile device. That includes any resources that are requested by the webpage. Then reload the webpage on your mobile device to ensure you are seeing all resources.
  9. First Check for GA.js
    When you load a webpage on your mobile device, many resources will be listed in the network tab. But you should look for ga.js to see if the Google Analytics snippet is being loaded.Tip: You can use the search box and enter “ga.js” to filter all resources by that string. It’s an easy way to isolate what you are looking for.

    Check for ga.js in Network Tab in Developer Tools

  10. Next Check for utm.gif
    After checking for ga.js, you should look for the tracking pixel that’s sent to GA named utm.gif. If that is listed in the network panel, then your mobile webpage is tracking properly (at least basic tracking). Again, you can use the search box to filter by utm.gif.

    Check for utm.gif in Network Tab in Developer Tools

  11. Bonus: Advanced Tracking
    If you are firing events from mobile webpages, then you can see them listed here as well. For example, you can see an event being fired when a user stays on the page for more than 30 seconds below. So for this situation, we know that pageviews are accurately being tracked and the time on page event is being tracked via mobile. Nice.

    Check event tracking in Chrome for Android

 

A Note About Troubleshooting
I mentioned earlier that if you don’t see the “Allow USB Debugging” dialog on your mobile device when you connect your phone to your computer, then this setup won’t work for you. It didn’t initially work for me. After doing some digging around, I found the legacy workflow for remote debugging on Android.

By following the steps listed below, I finally got the prompt to show up on my mobile device. Then I was able to debug open Chrome tabs on my Android device.

 

  1. Install the Android SDK (if you don’t already have it installed)
    You can learn more about the SDK here and download the necessary files.
  2. Kill the ADB Server
    Use a command prompt to access the “platform-tools” folder in the SDK directory and then issue the following command: adb kill-server. Note, you should use the cd command to change directory to the folder containing adb. That’s the platform-tools folder in your Android SDK directory.

    Kill ADB Server

  3. Revoke USB Debugging on Your Android Device
    Disconnect your phone from your computer. Then go back to Developer Options on your Android phone and tap Revoke USB debugging authorization.

    Revoke USB Debugging

  4. Start the ADB Server
    Now you must restart the adb server. Use a command prompt, access the platform-tools folder again, and enter the following command: adb start-server.

    Start ADB Server

  5. Reconnect Your Device To Your Computer
    Once you reconnect your device, you should see the “Allow USB Debugging” dialog box. Click “OK” and you should be good to go. This will enable you to debug Chrome tabs running on your mobile device via Chrome running on your desktop.
  6. Open Chrome on Your Android Device
    Go ahead and open a webpage that you want to debug in Chrome on your Android phone. Once it’s loaded in Chrome in Android, you can follow the instructions listed earlier for using the network panel to debug the GA setup.

 

Summary – Know When Google Analytics is Firing on Mobile Devices
So there you have it. There is a way to debug the actual firing of GA code on your Android devices and it works well. Sure, you may need to go the extra mile, use the legacy workflow, and install the Android SDK, but you should be able to get it working. And once you do, you’ll never have to guess if GA is really working on Android devices. You’ll know if it is by debugging your Chrome tabs on Android via Chrome running on your desktop. Good luck.

GG