Fixing missing Google Analytics after MonsterInsights Gtag update

We’ve all been there–you check your Google Analytics and notice a massively shocking drop in traffic. But what if your traffic drops to near-zero overnight? Yeah, that’s frightening, and it just happened to one of our sites last week. Thankfully, it wasn’t the actual traffic that we lost, just the reporting of that traffic.

Verifying loss of traffic vs loss of reporting

After the initial panic struck and we could breathe again, we needed to determine whether it was actually a loss of traffic and basically being dropped off the SERPs or if Google Analytics was at fault.

This was pretty easy because we monetize that site with ads from Ezoic, and they have their own analytics suite. It’s still Google Analytics, we believe, but they funnel the raw data into their “Big Data Analytics” views which have slightly different processing than GA proper.

Phew! This was a major relief knowing that it wasn’t our traffic–and SERPs rankings–that were affected (this time lmao), so it’s a code issue, most likely. Alright, let’s get to it.

Checking for broken plugin updates

If anything goes wrong within WordPress, it’s most likely due to either a bad WordPress core update or a bad plugin update. The latter much more common than the former. This is also why you should never update in PROD before updating in STAGE–but we’re just not that dedicated, nor are our operations that large to where a bit of downtime won’t massacre us.

We do have auto-updates enabled for our sites (with a few problematic themes/plugins excluded), and we get email alerts every time an update is performed. Annoying, yes, but at least it’s an automatically provided log of updates that we don’t have to manually mess with other than archiving an email.

Alright, so now we’ve checked for all the updates around this time frame, and what do you know, there’s a MonsterInsights update on 2/11/21. Coincidence? Probably not! But just in case, we also checked for any plugins updated around that time frame:

Investigate the updated plugins

So now that we have a primary suspect, we checked the plugin for the basic GA settings we normally expect to see within MonsterInsights, such as Gtag.js or Analytics.js, etc. We were using it in the Analytics.js mode previously.

Looking at the settings, however, well… They’re missing. Completely gone.

Well, that’s weird. Okay, perhaps they updated everything to GA4 property support? After checking, no, they didn’t force GA4–but they did force the switch to Gtag.js. Analytics.js is no longer an option.

With that said, we checked the WordPress.org support forums for MonsterInsights to see if others were reporting the issue as well.

There isn’t too much here, just a few things that may or may not be related, but almost everything gets redirected to their Lite support page.

So we did that, and received an email back stating that the issue seemed to be because of Ezoic’s caching. Pretty unlikely in our opinion, but just for funsies, we sent in a ticket with them as well. It’s possible that their caching and/or script delays could affect Gtag differently, but it seems odd that it would.

Ezoic did get back to us and pretty much confirmed our original thought–Gtag shouldn’t be affected any differently. They did, however, add in specific script delays for GA files to see if that resolved the issue, which it didn’t. So now it’s time to start looking for conflicts.

Disabling plugins and caches

As with all things IT, have you tried turning it off and on again? We all hate doing this part, but it’s necessary. So we started with the caches. We cleared our WP caches (WP Rocket and RunCloud Hub), along with the Ezoic caches (Site Speed Accelerator and the general Ezoic cache) with no change in behavior.

Next, we started disabling the plugins updated in that time frame. We absolutely love the Plugin Toggle plugin that lives in the Admin toolbar for quick access to toggle plugins off and on, and it makes this process way easier. It could definitely use an update, but it’s a simple enough program we’re okay with running it as of now.

We disabled Ezoic completely for the site on all platforms and turned off each recently updated plugin within the time frame of the issue, but nothing caused any change in behavior. Uh oh.

Testing different Google Analytics code methods

At this point, is it the GA code itself that’s causing the problem, or just the MonsterInsights plugin? Easy way to test that–use another plugin, or just add in the code manually.

We grabbed our property’s Gtag code and pasted it into Ad Inserter‘s Header code section. Easy enough, for sure. (If you’re not using Ad Inserter for advanced ad placement and other cool stuff, you’re missing out, btw!)

Now that we have that in, we’ve cleared any caches not already disabled and checked within Incognito mode–and we have traffic! Alright, so now we know that the code itself is good, and it’s MonsterInsights that is (at least mostly) causing the issue. So there’s a plugin conflict with MonsterInsights somewhere.

Finding the plugin conflicts

We’ve ruled out the plugins that were updated around the same time as MonsterInsights, so what else can be causing the issue? We checked the rendered source code and noticed that it’s still being intercepted by CAOS, a very cool little plugin that lets you host Google Analytics scripts locally to help reduce outbound connections as well as do some other cool tricks.

CAOS does require a compatibility mode to be enabled when using MonsterInsights (or other GA plugins, mostly all now owned by MonsterInsights anyways). We know that this was working previously, but perhaps it somehow got reset or broken when MonsterInsights updated. So we’ll check those settings within CAOS.

Well now… The “Which file to download?” setting was set to Analytics.js. This is because we were using Analytics.js within MonsterInsights until that plugin forcibly switched ALL of their users/installs over to Gtag.js with the update on 2/11/21.

Is it really that simple? Only one way to find out. We commented out our manually added code from Ad Inserter and re-enabled MonsterInsights. Then we switched CAOS over to Gtag.js, cleared caches, checked in Incognito mode, and BAM–traffic in Google Analytics!

Final testing and confirmation

Now we can re-enable all of our disabled plugins, turn back on WP Rocket and test before bringing Ezoic back in the mix. All our traffic is now registering as expected within our install, so let’s go further.

We can now turn back on Ezoic. With all our plugins, caches, and Ezoic traffic now re-enabled (all caches cleared, of course), we’re still registering our traffic. We also removed the script delay for Google Analytics, and we’re still all good–traffic is now reporting nearly in real-time.

Conclusion

In the grand scheme of things, this isn’t a big issue. It just happened to fall at a very inopportune time for us, as we had a billion other things to deal with last week. While there were several hours of investigation that went into this (clearing caches takes a lot of time lmao), the fix definitely was massively simple, which we’re glad for.

But this does highlight something that some developers occasionally do, and that’s making a huge change to a plugin or piece of code that forces a user into a change that unexpectedly or unknowingly creates a very easily avoidable problem. And MonsterInsights forcing everyone on to Gtag.js definitely is that sort of problem.

More novice WordPress users may have just given up, or not even noticed the issue until they were missing a month of analytics. Not great, but in all reality, not the end of the world.

Developers are only human, of course, and they have a lot going on. We would have liked to see someone–whether it was MonsterInsights or CAOS–highlight that this change was coming and that it may cause issues.

Perhaps that notice was out there and we just somehow missed it. We’re not going to say that we are 100% up on these changes either, but if there was a notice, we definitely didn’t see one.

Either way, we’re just glad to see that this issue had an easy fix, but getting more communication from big developers with massive install bases wouldn’t be a bad thing to strive for in the future.