Concrete5 + Google Analytics
Permalink
I thought I'd bring this back up for public debate...
Concrete5 needs to change how it implements tracking.
At present, it seems the 'standard' when coding up a template is to enter the tracker implementation code (that connects to what gets entered in the dashboard) just before the closing </body> tag.
See attachment.
Google changed the game a few months ago, and I think it's time to adjust Concrete5 to follow through here - not so much technically (just updating a couple of lines of text right) but the 'training' or the 'way we do things here').
End of the day, Google wants it's tracking code in the header.
I want to enter this through the Dashboard (it's easy to do this!).
No go at present.
Thoughts? Appreciate some comment from Concrete5 core team here as well.
Concrete5 needs to change how it implements tracking.
At present, it seems the 'standard' when coding up a template is to enter the tracker implementation code (that connects to what gets entered in the dashboard) just before the closing </body> tag.
See attachment.
Google changed the game a few months ago, and I think it's time to adjust Concrete5 to follow through here - not so much technically (just updating a couple of lines of text right) but the 'training' or the 'way we do things here').
End of the day, Google wants it's tracking code in the header.
I want to enter this through the Dashboard (it's easy to do this!).
No go at present.
Thoughts? Appreciate some comment from Concrete5 core team here as well.
update the theme submission guidelines.
To say what, exactly? We're talking about a core modification to allow users the same functionality in the Dashboard -> Sitewide Settings -> Tracking Code, just placing an option for Additional Header Code as well as Additional Footer Code.
Theme developers shouldn't need to worry about tracking codes, since the end-user supplies them, not the theme developer.
Theme developers shouldn't need to worry about tracking codes, since the end-user supplies them, not the theme developer.
well I was thinking that that would probably need some developer code to make it changeable.
Yeah...
Just my notes. We should keep
As on footer, and there are other tracking codes that still required to be at the bottom of the page (correct me if I'm wrong).
Perhaps, we could have "global header" section and rename the existing "tracking code" to "global footer"...
Noo.. this confuses newbies...
Grrrrr....
Just my notes. We should keep
<?php Loader::element('footer_required'); ?>
As on footer, and there are other tracking codes that still required to be at the bottom of the page (correct me if I'm wrong).
Perhaps, we could have "global header" section and rename the existing "tracking code" to "global footer"...
Noo.. this confuses newbies...
Grrrrr....
Correct, often we give marketing access to the Dash, where they do SEO, enter the tracking code via the Dash etc
Katz, I think you and I are talking about the same thing.
We need two spots in the Dashboard to add tracking or other code:
1. Additional Header Code
2. Additional Footer Code
We already have calls in the templates for header_required and footer_required. Let's just get a spot to add to the header.
Seems to me that would solve the issue at hand.
We need two spots in the Dashboard to add tracking or other code:
1. Additional Header Code
2. Additional Footer Code
We already have calls in the templates for header_required and footer_required. Let's just get a spot to add to the header.
Seems to me that would solve the issue at hand.
what about a scrapbook area? the area could be created on install, theme devs input the code for their footer and header, people change it through dashboard- probably need some documentation on how to set it up for people tho. or am i thinking down the wrong path?
I think that's the point. We need it to be easier for new users to go to some tracking site, see the area where they give you the code and tell you to "paste this into the header of your website".
The user would then have an easier time going to Sitewide Settings and adding it to Additional Header Code.
That's my thought, at least.
The user would then have an easier time going to Sitewide Settings and adding it to Additional Header Code.
That's my thought, at least.
i was just thinking of ways to make it possible now, with the current verion of c5. but it would be a good feature for a future release.
You can use the code at the following link to put GA code in the header:
http://www.concrete5.org/community/forums/usage/adding_google_analy...
If you actually look in the footer_required.php file, you'll see that it's pretty minimal. When using this code, it's more semantic and you can put it wherever you want.
As a side note, Paul Irish noted in his HTML5 boilerplate sceencast that he continues to put GA code in the footer because he doesn't count a partial page load as a page view.
Hope this helps.
http://www.concrete5.org/community/forums/usage/adding_google_analy...
If you actually look in the footer_required.php file, you'll see that it's pretty minimal. When using this code, it's more semantic and you can put it wherever you want.
As a side note, Paul Irish noted in his HTML5 boilerplate sceencast that he continues to put GA code in the footer because he doesn't count a partial page load as a page view.
Hope this helps.
I've yet to hear anyone complain that google tracking doesn't work when you leave it where they wanted it for years and years..
just sayin.
just sayin.
Second that..
This new script placement will just help Google report more impressions, since much can go wrong between <head> and </body> tags.
Wonder who that benefits?
This new script placement will just help Google report more impressions, since much can go wrong between <head> and </body> tags.
Wonder who that benefits?
Well, I agree with that, however my point isn't just about Google. Is there any harm in allowing users to add code to both the header and footer from the dashboard?
Like you, I'd like as much flexibility as possible.
But in my own experience, clients won't install this sort of script themselves, which for me makes it a mute point - if you as the developer end up having to do it for them you might as well stick the script in your theme file(s).
Users happy dealing with code/script are probably also able to use Drupal, Joomla backends too. I know that's a massive generalisation, but I put my clients on C5 as they are not at all techy but can still get stuff done on C5 despite that. Script installation isn't on the agenda.
But in my own experience, clients won't install this sort of script themselves, which for me makes it a mute point - if you as the developer end up having to do it for them you might as well stick the script in your theme file(s).
Users happy dealing with code/script are probably also able to use Drupal, Joomla backends too. I know that's a massive generalisation, but I put my clients on C5 as they are not at all techy but can still get stuff done on C5 despite that. Script installation isn't on the agenda.
That is sounding more and more like a textarea in the backend that would enable you to update your theme file.
Much like Wordpress's "Edit Themes" option:
http://developer.practicalecommerce.com/uploads/images/0001/4103/1-...
That would be a neat addition to the core or an awesome add on for the marketplace. (hint hint nudge nudge ;-)
Much like Wordpress's "Edit Themes" option:
http://developer.practicalecommerce.com/uploads/images/0001/4103/1-...
That would be a neat addition to the core or an awesome add on for the marketplace. (hint hint nudge nudge ;-)
I totally agree with the google comments! The new script placement will only benefit google. The Wordpress "Edit Themes" options is good, I agree. it would be more than neat to have that additionally :)
As I understand it, to reliably track events with Google, you have to include the code in the head. Otherwise there is a real risk of events being fired, or links being clicked on, before the tracking code has been loaded. I believe Google has always advocated placing their tracking code in the head of the page for this purpose. It was only ever supposed to be in the footer to ensure it didn't slow the loading of your page, but with Googles current CDN's, that should no longer be an issue.
I always put the tracking code in the head.
Jon
I always put the tracking code in the head.
Jon
Nah they used to advocate the end, now it's the head. Just as an aside I think it should be clear that google is just going to have to deal as there are millions if not billions of pages out there that arent going to change any time soon. Just. Because google techs want something new doesn't mean the earth stands still..
That being said, yeah the form in the dashboard that is geared specifically for your tracking code should probably have a drop down next to it asking if you want it in the header or footer. I thunk that's more graceful to a mom than spattng fields for everywhere all over
The idea of having a code editor in the dashboard for themes is interesting for separate reasons, particularly if it can be controlled with permissions and workflow.. But that's probably a bigger conversation.
That being said, yeah the form in the dashboard that is geared specifically for your tracking code should probably have a drop down next to it asking if you want it in the header or footer. I thunk that's more graceful to a mom than spattng fields for everywhere all over
The idea of having a code editor in the dashboard for themes is interesting for separate reasons, particularly if it can be controlled with permissions and workflow.. But that's probably a bigger conversation.
Two very good ideas. Would love to see them.
Agreed ^. I think it can wait till the next c5 release.
FYI, working on a theme editor right now. Just implementing permissions and it should be set for PRB review soon.
is there something we can do to set up themes for added moding?
That's great to hear! I'm guessing this is going to be a paid add on...?
Google Webmasterprograms lets you verify ownership by using the GA trackingcode. BUT: it needs to be in the <head> instead of <body>. So yes: there is need for a sitewide header option.
that thing only needs to be on the home page for google to verify once
I believe.
Just a heads up.
best wishes
Franz Maruna
CEO - concrete5.org
http://about.me/frz
I believe.
Just a heads up.
best wishes
Franz Maruna
CEO - concrete5.org
http://about.me/frz
if you guys absolutely must have this right now, you can actually do this with page events, in this case on_page_view would be applicable.
function addTrackingCodeInHead($page){ if(!$page->isEditMode()){ $v = View::getInstance(); $v->addHeaderItem('<script type="text/javascript"">whatever here</script> ');
There is a brief FAQ Entry about this over at the HTML5 Boilerplate site:http://html5boilerplate.com/docs/#FAQs%E2%98%85why-is-the-analytics...
Short version: Leave the code at the bottom.
Short version: Leave the code at the bottom.
Having the code in the head helps the page to load faster, and is better (even mandatory) for event tracking features.
I would hope to see C5 implement something as has been suggested to allow simple input of code snippets, etc, into the header as they currently do in the footer.
I would hope to see C5 implement something as has been suggested to allow simple input of code snippets, etc, into the header as they currently do in the footer.
Most templates do honor a meta extra attribute that puts whatever you want in header... However those are on a page by page basis. It's unlikely were going to change over 300 themes to put the anaytics code in the header instead of the footer. Perhaps changing the guidelines for future themes makes sense tho
Best wishes,
(Pecked out on a mobile device...)
http://about.me/frz
Best wishes,
(Pecked out on a mobile device...)
http://about.me/frz
All I have to say on this issue (considering I posted last year) is stop discussing it and hurry up and implement space for both header code insertion in addition to the current footer, so we coding templates can easily slap it in.
Just get on and do it.
Just get on and do it.
I'm not saying we have to go back and change the existing themes ... but if we add support for a global "add to head" field then existing themes can be updated over time, at the discretion of the theme creators.
Google's not going to change their requirements any time soon, especially since that:
1) they are convinced this leads to faster load times
2) they say the code has to be in the head to support some of their GA event features
We all want C5 to be as appealing to users as possible - on that we agree :) Since GA is such a widely used and endorsed product, and since other non-Google products also require JS to be placed globally in the head, why not make the option available and make this as easy for users as possible?
Google's not going to change their requirements any time soon, especially since that:
1) they are convinced this leads to faster load times
2) they say the code has to be in the head to support some of their GA event features
We all want C5 to be as appealing to users as possible - on that we agree :) Since GA is such a widely used and endorsed product, and since other non-Google products also require JS to be placed globally in the head, why not make the option available and make this as easy for users as possible?
I'm not against it. Is there a reason new themes shouldn't just be calling the same function in the header instead of the bottom? Two fields sounds potentially confusing
Best wishes,
(Pecked out on a mobile device...)
http://about.me/frz
Best wishes,
(Pecked out on a mobile device...)
http://about.me/frz
@StriderSEO
Actually. It doesn't load faster. From a performance point of view any https calls are bad news.....especially in the head.
Miser has had the option to move the code into the head from day dot. However the default is to keep it at the bottom since it was shown in benchmarks to impact performance.
From a tracking point of view. I personally think it's a bit anal. If a visitor clicks away before your page has loaded then they are unlikely to have seen any adverts or content. If you want to rack up numbers so your site looks popular to potential advertisers-then put it in the head. But I prefer to make a site more interesting so users linger.
Actually. It doesn't load faster. From a performance point of view any https calls are bad news.....especially in the head.
Miser has had the option to move the code into the head from day dot. However the default is to keep it at the bottom since it was shown in benchmarks to impact performance.
From a tracking point of view. I personally think it's a bit anal. If a visitor clicks away before your page has loaded then they are unlikely to have seen any adverts or content. If you want to rack up numbers so your site looks popular to potential advertisers-then put it in the head. But I prefer to make a site more interesting so users linger.
1) Yes, it does load faster, as JS in the Body impacts the loading of other page elements. That's why many scripts and services (not just GA) are moving JS into the Head.
2) HTTPS called are necessary sometimes. If a page loads under HTTPS and a JS element uses HTTP the page won't be completely secure. Chrome and FF give subtle hints about this, IE throws an ugly warning message defaulting to blocking the unsecured elements. The Google JS loads conditionally in HTTP or HTTPS depending on how the page is called.
3) There are plenty of scenarios where a user may click away before a page loads - especially if you have some other element (non-GA JS loading from a 3rd party server, slow ad platform, poorly optimized images, etc) that can leave a page >90% loaded for an extended period of time.
2) HTTPS called are necessary sometimes. If a page loads under HTTPS and a JS element uses HTTP the page won't be completely secure. Chrome and FF give subtle hints about this, IE throws an ugly warning message defaulting to blocking the unsecured elements. The Google JS loads conditionally in HTTP or HTTPS depending on how the page is called.
3) There are plenty of scenarios where a user may click away before a page loads - especially if you have some other element (non-GA JS loading from a 3rd party server, slow ad platform, poorly optimized images, etc) that can leave a page >90% loaded for an extended period of time.
@StriderSEO
1. Many GA scripts are being moved into the head not because it is faster. But to bump up page hits on partial loads. ESPECIALLY for those sites that pop-up those annoying adverts on page loading when people know it is an ad and close it before it is complete. It is only achievable now that it is an asynchronous call and no longer blocks (anywhere, including the body). Therefore it makes zero difference where you put it on a page for load times. So no. Your site won't load faster with the asynchronous GA in the head as opposed to the footer, only that a request pipe is used for a long time because it is an https call when it could be being used to show content. But if you want to prove it. I'm open to seeing the numbers. I'll then make the default for Miser to move it into the head. But from experience (and actually running benchmarks like those below, rather than listening to opinions). It does not make the page load faster, only gets a hit registered more quickly.
GA at end of body:
http://www.webpagetest.org/result/110504_VA_HSEG/...
GA in Head
http://www.webpagetest.org/result/110504_QW_HSFJ/...
2. Of course it is necessary. But many sites don't use it at all apart from GA (paypal is another). In those cases, it is better that the https call doesn't lock up a request pipe until everything else interesting has loaded.
3. Then you have bigger problems than worrying about an extra page hit or two.
But it brings up an interesting discussion about page hits. From goggles point of view as soon as a link is clicked they want the number. From my point of view, I want "quality" statistics. By that I mean, I want to know who has actually seen what and what is the most effective. Having 100,000 page hits means nothing to me if no-one is actually looking at my content (i.e adverts etc) since it will not generate clicks. I (personally) would rather see 10 hits and work to increasing it further rather than 100,000 (to get 10 real views) and raising it to 200,000 to get 20.
But, of course. If your selling a site. You just want bigger numbers to make it look more popular than it really is. thats why I think the GA loyalty and time on site are better indicators than hit-count.
1. Many GA scripts are being moved into the head not because it is faster. But to bump up page hits on partial loads. ESPECIALLY for those sites that pop-up those annoying adverts on page loading when people know it is an ad and close it before it is complete. It is only achievable now that it is an asynchronous call and no longer blocks (anywhere, including the body). Therefore it makes zero difference where you put it on a page for load times. So no. Your site won't load faster with the asynchronous GA in the head as opposed to the footer, only that a request pipe is used for a long time because it is an https call when it could be being used to show content. But if you want to prove it. I'm open to seeing the numbers. I'll then make the default for Miser to move it into the head. But from experience (and actually running benchmarks like those below, rather than listening to opinions). It does not make the page load faster, only gets a hit registered more quickly.
GA at end of body:
http://www.webpagetest.org/result/110504_VA_HSEG/...
GA in Head
http://www.webpagetest.org/result/110504_QW_HSFJ/...
2. Of course it is necessary. But many sites don't use it at all apart from GA (paypal is another). In those cases, it is better that the https call doesn't lock up a request pipe until everything else interesting has loaded.
3. Then you have bigger problems than worrying about an extra page hit or two.
But it brings up an interesting discussion about page hits. From goggles point of view as soon as a link is clicked they want the number. From my point of view, I want "quality" statistics. By that I mean, I want to know who has actually seen what and what is the most effective. Having 100,000 page hits means nothing to me if no-one is actually looking at my content (i.e adverts etc) since it will not generate clicks. I (personally) would rather see 10 hits and work to increasing it further rather than 100,000 (to get 10 real views) and raising it to 200,000 to get 20.
But, of course. If your selling a site. You just want bigger numbers to make it look more popular than it really is. thats why I think the GA loyalty and time on site are better indicators than hit-count.
1) Interesting - when I look at your links, the GA in Head link shows a faster load time (3.926 seconds vs 4.342 in the body).
I'm not a JS programmer but from my reading one of the benefits of asynchronous JS is that the actual action script (ex: registering of the visit (not hit - that's different)) is run after the page loads. Therefore the position of the code wouldn't increase the visitor count. Anecdotally, of the literally hundreds of sites we manage I haven't seen any kind of blip or jump in visits after converting users to the newer GA code.
2) But many sites DO use those features - including ecommerce sites that want to track events and purchases accurately. Isn't C5 about flexibility, ease of use and customization?
3) Note: I should have been clearer earlier when I mentioned scenarios where users click prior to a full page load... I'm not aware of this happening on any of our sites, but I was merely citing a common example.
Let's be clear - you're the one that made this about hits (but I think you mean visits). I don't sell ads on our sites ... in fact, only one site we operate has ads and that's an internally run ad platform where ads aren't sold on an impression basis, so it makes no difference to me at all.
My business is online marketing - so we want the most accurate stats, and we want the best performance. We use whatever means are necessary to get the GA code in the proper place. What I'm advocating is having C5 give non-tech-savvy users the same opportunity.
I'm not a JS programmer but from my reading one of the benefits of asynchronous JS is that the actual action script (ex: registering of the visit (not hit - that's different)) is run after the page loads. Therefore the position of the code wouldn't increase the visitor count. Anecdotally, of the literally hundreds of sites we manage I haven't seen any kind of blip or jump in visits after converting users to the newer GA code.
2) But many sites DO use those features - including ecommerce sites that want to track events and purchases accurately. Isn't C5 about flexibility, ease of use and customization?
3) Note: I should have been clearer earlier when I mentioned scenarios where users click prior to a full page load... I'm not aware of this happening on any of our sites, but I was merely citing a common example.
Let's be clear - you're the one that made this about hits (but I think you mean visits). I don't sell ads on our sites ... in fact, only one site we operate has ads and that's an internally run ad platform where ads aren't sold on an impression basis, so it makes no difference to me at all.
My business is online marketing - so we want the most accurate stats, and we want the best performance. We use whatever means are necessary to get the GA code in the proper place. What I'm advocating is having C5 give non-tech-savvy users the same opportunity.
Okay, in version 5.5 we will add both - a "content to include in header" section to compliment the one that already exists for end of page.
after further discussion it became clear that this should actually jive with old themes too..
so ta-da.
after further discussion it became clear that this should actually jive with old themes too..
so ta-da.
@StriderSEO
1. Indeed. there is always "jitter". You will notice that the time to first byte is less in the second case and that in the first case (in the footer) GA took 2x longer to return!. I'd much rather GA took longer when my page was visible than before. A better "benchmark" is the document complete rather than completely loaded. But if you point me to some real numbers showing significant improvements by putting GA in the head-then by all means post them.
I guess it's a real issue for you. But for me it's just changing a define in site.php So considering I don't think it makes any difference in page load times, it's an arbitrary choice and having it at the bottom is of no consequence.
Saying that though. I do agree that it would be useful to have the capability to stuff things into the head in the same way you can in the footer. The only issue (as I see it) is that people will abuse it and could cause all sorts of problems with clashes in javascript and dependency ordering. Should it go before all other head javascript? After?
The addheaderItems seems a much more logical and controlled method and prevents all that although it does require a bit of extra effort.
1. Indeed. there is always "jitter". You will notice that the time to first byte is less in the second case and that in the first case (in the footer) GA took 2x longer to return!. I'd much rather GA took longer when my page was visible than before. A better "benchmark" is the document complete rather than completely loaded. But if you point me to some real numbers showing significant improvements by putting GA in the head-then by all means post them.
I guess it's a real issue for you. But for me it's just changing a define in site.php So considering I don't think it makes any difference in page load times, it's an arbitrary choice and having it at the bottom is of no consequence.
Saying that though. I do agree that it would be useful to have the capability to stuff things into the head in the same way you can in the footer. The only issue (as I see it) is that people will abuse it and could cause all sorts of problems with clashes in javascript and dependency ordering. Should it go before all other head javascript? After?
The addheaderItems seems a much more logical and controlled method and prevents all that although it does require a bit of extra effort.
For the time being, I'm sure a savvy add-on dev could whip up a hack "package" that does what you're asking, or rather we could educate users on how to do this via the editing the theme.
Also would appreciate thoughts from the core on this.