Your blog is firing Google Analytics events that aren’t coming from this plugin…
After looking into it, it looks like it’s coming from this plugin: https://wordpress.org/plugins/reduce-bounce-rate/
That plugin is not necessary/redundant with Better Analytics because the “User Engagement” options under the “General” settings tab already does that for you.
Thread Starter
jshare
(@jshare)
Thanks for troubleshooting this. Really appreciate it.
Actually, when I first installed BGA, I enabled User Engagement and deactivated Reduce Bounce Rate, but reversed the changes after 3 days.
While both plugins measure bounce rate more accurately, RBR fires Time events to measure how long people are really staying on the site, and Scroll events to measure how far down the page they scroll, and I missed those two things when I tried out User Engagement.
But if you think it’s RBR that’s generating the Bad Event Tracking Codes, I’ll create a new thread over there
I don’t think it’s a direct conflict, but rather an indirect timing issue. When I visited the page myself, the events were flowing properly. It could cause an indirect issue though because the “Reduce Bounce Rate” plugin starts firing events immediately and the Better Analytics plugin was loading JavaScript asynchronously. What that means is that if a user had an issue with part of your site loading, the Reduce Bounce Rate plugin could start firing events before the main JS from Better Analytics had finished loading (it would be rare, but I suppose an issue with a single user could cause the notice you saw).
Either way, it might be moot because one of the changes to Better Analytics 1.0.10 was the removal of the asynchronous loading. It was causing some other timing issues when users were using other Analytics systems that piggyback the primary. So rather than deal with support issues (like this), we already switched it back to synchronous loading… So if you upgrade to 1.0.10, it most likely isn’t going to require any updates from the author of Reduce Bounce Rate.
This should have been fixed with the 1.0.10 update, so going to close this issue.
On a side note, 1.1.0 has two new event tracking features that came about because of what you were trying to measure here:
- Time On Page – (not a recurring firing of events every 10 seconds like you have now), rather it’s a one-time event recording when the user leaves the page with the exact number of seconds they spent on the page.
- Scroll Percent – A measurement of the percentage of the page the user scrolled down to before exiting the page.
Thread Starter
jshare
(@jshare)
Just updated to 1.1.0, enabled the new features and deactivated RBR. We’ll see how it goes!
Thread Starter
jshare
(@jshare)
Still happening, even though RBR is deactivated:
The Landing Pages report has a (not set) entry. Verify that tracking code for property https://jobmob.co.il sends a _trackPageview hit and that it does this before sending any events.
Do they give you a sample of the page it’s happening on by chance? Checking the main page manually everything looks in order. Events are never firing before the pageview tracking method when I check it manually.
Thread Starter
jshare
(@jshare)
I think this is related to how you (do/don’t) handle bots.
If I limit the period from Aug. 31-Sep 3 (after I deactivated RBR) and check the Landing Pages report, the most common Event Action by far for these bad events was ‘Comment’ (1840 times out of 1978).
I wish I’d had that many comments this week!
If I check Antispam Bee’s stats, these were the spam comment counts during that time:
Sep. 3: 471
Sep. 2: 587
Sep. 1: 452
Aug. 31: 404
Total: 1914
Which is pretty close to 1840, and I assume the discrepancy comes from the difference in timing between Google Analytics and Antispam Bee.
It’s possible I suppose, but if that’s the case then I’d say Google Analytics is giving you an incorrect notification warning.
Comment events are sent to Google via the Google Analytics Measurement Protocol (which is why it would also include things like bots).
I suppose it could be possible to not send comment events for clients that don’t have a Google Analytics Client ID cookie already set, which would prevent data from bots, but it would also prevent data from users who deleted their cookies or have privacy systems in place.
Not sure which is the “less bad” way to do it. You might not get the notification about “(not set)”, but you would also potentially lose out on legitimate data in some cases.
Thread Starter
jshare
(@jshare)
Yeah, the classic false positive dilemma.
I have Google Analytics configured to ignore bots so I’d rather leave things the way they are, although maybe this is proof that they’re not doing such a good job 🙁
I’m going to ignore it for now.
Thanks for the help
