The Internet Marketing Driver

Archives for November 2016

November 10, 2016 Google Algorithm Update – Was It A Core Ranking Update, The Mobile-first Index Being Tested, or Both? (Updated)

By 33 Comments

November 10, 2016 Google Algorithm Update

{Update: Saturday, November 19, 2016 – I saw reversals starting yesterday, November 18 (both recoveries and drops), which supports my theory that this was the mobile-first index being tested. I have provided more information below at the end of this post about what I’m seeing — including screenshots.}

The fall of 2016 has been one of the most volatile ones I have seen in a long time algorithm update-wise. We started with a local spam update and a quality update on 8/31 (simultaneously), then we had Penguin 4 roll out in multiple stages in September and early October, and then I picked up two more core ranking updates (which I hope to write about soon). But now we have another update that started around 11/10, and some sites are seeing significant movement (either up or down).

I’ve been digging into sites that have been impacted in order to analyze each situation. Here are some screenshots of the movement I’m seeing search visibility-wise:

Surge during November 10, 2016 Google Algorithm Update

Drop during the November 10, 2016 Google Algorithm Update

Drop during the November 10, 2016 Google Algorithm Update

When checking the search history of various sites that have been impacted, I am seeing a lot of connection to previous quality updates. For example, here is a site impacted on 11/10/16 that was also impacted by several other quality updates.

The connection between the November 10, 2016 update and other quality updates.

Now, based on what I’ve seen, it’s hard to say if this was just a quality update, or if there is another component at work. One thing is for sure, I kept surfacing an interesting finding across sites that were impacted – and it involved mobile. And with Google announcing on 11/4 (just days before we saw this update) that they were beginning to test a mobile-first index, the timing is very, very interesting.

The Connection Between Mobile Problems and Negative Impact
So, during the June quality update, I mentioned that I saw sites recovering that had improved their mobile setup. I speculated that maybe Google was handling the mobile version of the urls differently than the desktop (which would be a huge change). Here’s that segment from my June post:

Interesting Situation -> Desktop Horrible, Mobile OK
I checked one site that saw a major increase during the June update that got hit by the November 2015 update. When checking the desktop version of the site, it looked like minor changes had been made. That had me wondering why the site recovered. In other words, it still wasn’t a great user experience. But, checking on mobile yielded a much smoother, less aggressive approach. I’m not saying this was 100% why they surged back, but we know mobile is incredibly important, and their user experience and advertising situation was much, much better on mobile than desktop. Just an interesting side note.

Well, when checking pages that dropped across sites negatively impacted by the November 10, 2016 update, I saw a lot of mobile problems. That included popups, interstitials, render problems, UIs breaking, thinner and disorganized content on mobile urls, and more.

For example, here’s a nice one that smacked me in the face when checking the page on mobile:

Mobile interstitial.

And if you’re thinking, hey, Google’s coming out with a mobile popup algo on January 10, so that can’t be the case now! Think again. With the mobile-first index, Google will index the mobile page as the canonical url, and if you’re providing a popup or interstitial, Google can see that as your primary content. I confirmed that with Google’s John Mueller last night. See the tweet below.

John Mueller about mobile interstitials.

Beyond popups and interstitials, I came across numerous situations where the mobile UI was breaking. For example, the content would render, but the user could move that entire block of content around (by swiping). That was clearly a tech problem. And when you did that, here’s what the viewport could look like:

Mobile UI problems.

Anyway, I saw enough mobile problems on sites negatively impacted that it had me thinking we could be seeing the mobile-first index in action. I can’t say for sure that’s the case, but the timing makes sense, the problems I’m seeing make sense, etc.

Sites Seeing Positive Movement = Solid Mobile Setup
On the flip side, I analyzed a number of sites seeing positive movement during the 11/10/16 Google update, and they provided a clean and strong mobile setup. Many were responsive, did not provide crazy popups or interstitials, did not have UI problems, etc.

Here is the search visibility from a site seeing an increase during this update (and it provides a solid mobile setup):

Site with solid mobile setup surging during November 10, 2016 Google algorithm update.
And here is an example of rankings jumping for another site seeing positive movement based on the update. Some rankings jumped +80, +41, +31, etc.

Rankings increase based on the November 10, 2016 algorithm update.


———————————–
Important Update: Reversals Starting On Friday, November 18:
I have seen reversals of the impact from the November 10, 2016 algorithm update starting on Friday, November 18. Sites that surged are dropping back down and sites that dropped are recovering. This supports my theory that the mobile-first index was being tested. Here are two examples of reversals:

A large drop on November 10 and then recovery on November 18

A surge on November 10 and then a drop on November 18.

A drop on November 10 and then a recovery on November 18.

So if this test tells us anything it’s that the mobile-first index can indeed cause significant movement in the SERPs. I highly  recommend checking your mobile setup (as I explain below) and making sure your mobile pages contain sufficient content, don’t have render issues, etc. We don’t know the exact date of the full rollout of the mobile-first index, but it’s clearly getting close. Stay tuned.
———————————–

Core Ranking Update, Mobile-first Index, or Both??
With the amount of volatility this fall, it’s hard to say that the November 10, 2016 update is ONLY the mobile-first index in action. But, it very well could be part of what’s going on. For example, there could have been a core ranking algo update, in addition to, more testing of the mobile-first index. And maybe the sites I’m seeing with major mobile problems are being impacted by the mobile-first piece. Again, hard to say for sure.

I’ll try and post more as I analyze additional sites impacted by the 11/10 update. In the meantime, I recommend checking your stats to see if you’ve been impacted (either positively or negatively). And if you’ve been negatively impacted, check your mobile setup. Are there barriers, broken UIs, content problems, or other issues you are presenting to users? And content-wise, make sure you are providing the full content on your mobile page (if you are using separate mobile urls).

One thing is for sure, this has been a very interesting update to analyze. The timing, and findings, lead me to think we just might be seeing the mobile-first index in action. Stay tuned. :)

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