thompsonpaul

Had a chance to look at your specific page code. No event is, in fact, being sent. You’re using the newest Global Site Tag for tracking which requires different syntax for sending events to GA, so you’re going to need to adjust your eventlistener sending code a bit.
https://developers.google.com/analytics/devguides/collection/gtagjs/sending-hits

Hope that solves the problem!

Paul

Hey Dave – the event is firing from the page (you can ignore the test form I submitted).

If the event data isn’t showing up in GA, then the first thing to check is that there isn’t a filter in place. For example, if you’re the one testing, need to make sure you’re not logged in (Many GA analytics plugins block Analytics for logged in admins) and make sure you don’t have an IP address filter blocking the network you’re checking from.

And I know this is going to sound insulting but… ?? You have at least 24 Properties in your GA account? Make absolutely certain you’re looking at the correct property and View.

First step is to determine why your events aren’t recording in GA. If the event doesn’t record, the Goal doesn’t have anything to report on. So first things first.

Yea, if the event isn’t being recorded in the Analytics dashboard, there’s nothing for the Goal to report on.

First thing to confirm is how you’re testing. Remember, if you have an IP address filter to block your own network, you’ll need to use a new View without the filter applied. Also remember that most WP Analytics plugins remove tracking for logged in admins, so you’ll need to be logged out or incognito for your own testing. Also remember some ad blockers blog Analytics too. Just need to be sure that there’s nothing blocking the transmission of data as the problem.

Try testing the form submission when you’re not logged into your site, Dalton.

Can you see the events recorded in the Analytics Dashboard? (Behaviour > Events)

Have you set up Event tracking for the form submission itself? Can you see that the events are being recorded in your Google Analytics dashboard? (Behaviour > Events)

That’s a limitation of your email provider’s spam filtering, @5live (though most ISPa are now implementing this level of spam protection for email sent by websites as opposed to mailservers.)

The solution is to set up SMTP for your site – it can be done through Gmail if you use that, or you set up something like Mailgun.

Google has been very clear that redirecting all the “not found” pages to the home page is a very poor user experience and so will treat those redirects as a “not found” anyway (soft 404).

If you think like a user, it makes sense. Why would they end up on a home page instead of the page they asked for? That’s the whole purpose of an actual 404 error page. To let them know what they are specifically looking for is no longer there, and then to offer suggestions for how they might find additional info that would be of use.

Hope that helps;

Paul

Actually, it is pretty widespread if you read through other issues posted here in the support forum. This issue came up 6 weeks ago when it was considered a conflict with Yoast SEO and is again being reported.

I’ve confirmed that the issue exists even when Analyticator is the ONLY plugin active on the site. It appears to have re-emerged as an issue after a recent WP update?

Can you deactivate all plugins except Analyticator and confirm whether you still see the broken Widget behaviour, Brian?

I can confirm that running ONLY Analyticator plugin with ALL other plugins deactivated, I’m unable to edit Widgets. On both 4.6.1 and 4.4.5

Yup – another with the same issue. No widget editing available when Analyticator enabled.

No errors in Chrome Developer Console that I can see.

Just in case you’re still trying to accomplish this, @andiedk – Adwords Conversion Tracking is not part of Google Analytics tracking. You have to add the stand-alone Adwords Conversion tracking code to the conversion pages of your site seperately. (e.g. your thank you page, cart checkout success page, etc.)

This will be the case regardless of what GA tracking plugin you use.

Hope that helps?

Paul

There’s some confusion in this question between an account’s overall sample rate, and the specific sample rate set for tracking speed of individual pageviews, which are two totally different settings.

By default, the GA Universal tracking code only tracks the speed of 1% of pageviews, even if the overall account is set to 100% Sample Rate (which applies to all data, not page speed specifically.)

The OP (and I) would like the plugin to allow addition and customising of the siteSpeedSampleRate in the on-page tracking code, which is necessary to override the 1% default. This is accomplished by editing the default ga_create call to include the ‘siteSpeedSampleRate parameter. So the default Create call of

ga('create', 'UA-XXXXXXXX-1', 'auto');

is adjusted to:

ga('create', 'UA-XXXXXXXX-1', 'auto', {'siteSpeedSampleRate': 100});

or whatever percentage up to 100% the account owner specifies to stay withing the 10,000 max. pageviews per day which applies to this functionality.

It’s a critical adjustment needed to make the RUM (Real User Monitoring) of pagespeed in GA become useful for small and medium traffic sites, as a 1% sample size is simply worthless for these sites. This kind of RUM measurement of page speed is going to become absolutely critical as mobile speed is poised to become a significant ranking factor for Google Search and mobile page speed can only be effectively tracked this way. Because it takes into account all the variables of actual visitors’ mobile network speed, latency, geographic distance, phone OS, browser etc.

This capability is already available in for example Google Analytics Dashboard for WordPress plugin and it would be wonderful if it could be implemented here to further enhance the additional data-gathering that this plugin already includes.

Can this be implemented?

Paul

P.S Google’s documentation of this data collection customisation can be found at:
https://developers.google.com/analytics/devguides/collection/analyticsjs/field-reference

So, Garrett – you’re saying the plugin has been updated to address this security issue, but there’s absolutely nothing in the changelog to indicate this.

Can you confirm that the 6.4.9.3 is secure from this issue?

And for heaven’s sake, please include these things in changelog in future? This is one of the main reasons for having a changelog in the first place, for those of use who maintain multiple client sites.

For example – I saw the 6.4.9.3 update and checked the changelog. Since it only mentioned a re-enabling of a functionality none of my clients use, there was no urgency to update, and I just slated it for the next regular update I do every 2 weeks. If it had been flagged to include a security issue, I would have taken the time and trouble to update immediately.

Paul

Thanks, I’ll experiment with that. The strange thing is – the plugin has been working fine for many months. Just noticed the problem the other day.

Will let you know if I find anything.

P.