-
Notifications
You must be signed in to change notification settings - Fork 800
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Google Analytics Tracking Code Placed Incorrectly #9129
Comments
The code on or about line 328 (bottom of the <!-- Jetpack Google Analytics -->
<script type='text/javascript'>
var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-123456789-1']);
_gaq.push(['_trackPageview']);
(function() {
var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
ga.src = ('https:' === document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
})();
</script> which doesn't line up with the output of the jetpack/modules/google-analytics/classes/wp-google-analytics-universal.php Lines 40 to 84 in d34545c
but does match the jetpack/modules/google-analytics/classes/wp-google-analytics-legacy.php Lines 56 to 118 in 74e6013
which is run in the footer --
The legacy is run instead of the universal code, as evaluates to false: jetpack/modules/google-analytics/wp-google-analytics.php Lines 53 to 57 in 2bcd0a0
which came from #8182 by @allendav to add support for the newer universal analytics js. The linked article in the original issue is for gtag.js tracking, which I think is yet another form of google analytics that we may not be explicitly supporting? I'm unsure, but would defer to @allendav on that. |
As far as I know, gtag.js is simply the 'latest and greatest' version of the tracking code. |
Looks like gtag is inclusive of a number of other google stuff as well, such as Google Tag Manager -- https://www.lunametrics.com/blog/2017/12/12/what-is-gtag-google-analytics/ As such, it may be a "do not ever ever ever run on WordPress.com sites" tag as it can allow the inclusion of arbitrary Javascript and lead to XSS attacks on user accounts from malicious wp.com subdomains running nasty custom js that we ordinarily would block. |
My desire is to have the GA code inserted in the head, not necessarily to have the use of gtag. When the GA code is not in the head, Search Console will not validate the domain. While there are other ways to validate a domain, when one is already using GA, it makes sense to also validate with GA. I only recently discovered that this was an issue when Search Console tried to automatically revalidate a couple of dozen of domains that we manage and they all failed because I had switched them to Jetpack's GA module (away from the GA Google Analytics plugin). I believe there may be other issues with GA code not being in the head. I encountered an error message (which I failed to save - doh!) that seemed to be telling me that, because the GA code ran after another code, it failed to recognize the page view and thus could not record its results properly. |
@allendav Would it be bad to have non-eCommerce ways to switch a site to using the universal tag? I suppose we could also just do something like add_filter( 'option_jetpack_wga', 'force_jetpack_ga_to_universal' );
function force_jetpack_ga_to_universal( $value ) {
if ( is_array( $value ) ) {
$value['enh_ec_tracking'] = true;
}
return $value;
} ); |
I see @jeherve marked this low priority. Of course, I don't know how you determine bug priority, but I just want to reiterate that this issue makes Jetpack's GA module useless to me. |
@georgestephanis wrote
It would not be bad. Besides a filter like yours, we also have to allow analytics.js to be added when WooCommerce isn't present. I am also trying to remember why I set the priority for wp_head for Jetpack_Google_Analytics_Universal so high (as @rtrevellyan noted it should be near the top, not near the bottom of the head ). Will have a patch shortly to allow for all this. Sorry for the delay. cc @rtrevellyan |
@georgestephanis @rtrevellyan @joendotcom - feedback welcome - #9333 |
I'm puzzled by the choice being between ga.js and analytics.js, instead of between analytics.js and gtag.js. If there's a need to support the legacy ga.js, perhaps that's the version that should be enabled by a filter.
from https://developers.google.com/analytics/devguides/collection/gajs/ |
Hi @rtrevellyan - the jetpack module used to be ga.js only, and then in Jetpack 5.6 I was asked to port the analytics.js code for eCommerce from another one of our plugins to Jetpack. At the time, I wasn't even aware of gtag.js's existence. Perhaps a future version of this module will add gtag.js support and/or support enabling analytics.js without the filter - please feel free to create such issues if you'd like. |
This issue has been marked as stale. This happened because:
No further action is needed. But it's worth checking if this ticket has clear reproduction steps and it is still reproducible. Feel free to close this issue if you think it's not valid anymore — if you do, please add a brief explanation. |
Still an issue. |
Summary
User reports that this issue causes trouble with Google Analytics tracking.
Referenced in 1036031-zen.
Steps to reproduce the issue
<!-- Jetpack Google Analytics -->
What I expected
Google Analytics tracking code is shown as outlined in this article:
What happened instead
Google Analytics code is not inside
<head>
and instead appears on line 328 (on the test site).The text was updated successfully, but these errors were encountered: