Google analytics: mobile tag, asynchronous tag and other improvment
Saveria Maroselli
As you know, WMaker allows you to use different systems to measure the audience of your site. The internal system WM or external systems such as Google Analytics.
There are of course differences between the results given by the different measurement systems. And this is normal because the calculation methods are not the same. WM stats are calculated from the analysis of logs on the servers. Whenever a part of a page of your site is called (a picture for example), we record a "hit", that is to say, a solicitation of the server. Every night, depending on the number of hits recorded, a calculation is launched to give you the number of page viewed, visitors, unique visitors, etc..
On external systems such as Google Analytics, the mechanism is different. For the system to work, it is necessary to place on all pages of the site a few lines of javascript code. This code is called for each page display, and the details are sent to the external service that applies the method of calculation.
For more information, we recomend to this excellent note on the subject:
http://www.devonwebdesigners.com/2567/awstats-vs-webalizer-vs-google-analytics/
For more information, we recomend to this excellent note on the subject:
http://www.devonwebdesigners.com/2567/awstats-vs-webalizer-vs-google-analytics/
Google Analytics on the mobile version
When a visitor visits your site from a mobile phone, WMaker sends him automatically to the mobile version. Today, you have the option to record in an external tool (Google Analytics or similar) traffic from the mobile version.
For this, a new field showed up on the back office. This is the field "Mobile version" in the menu Statistics > Google Analytics. The code you will write in this field will be automatically added to all pages of the mobile version of your site.
Several options are available regarding the addition of Analytics tracking code:
1 / You can use the same code as the one used for the site. The information will then be consolidated into a single report. You will have to create custom reports to isolate the info on mobile traffic, in addition to the report proposed by default Google.
2 / You can create a new profile and add a tracking code only for the mobile version. Traffic of the mobile version will then be isolated in the reports related to this profile.
For this, a new field showed up on the back office. This is the field "Mobile version" in the menu Statistics > Google Analytics. The code you will write in this field will be automatically added to all pages of the mobile version of your site.
Several options are available regarding the addition of Analytics tracking code:
1 / You can use the same code as the one used for the site. The information will then be consolidated into a single report. You will have to create custom reports to isolate the info on mobile traffic, in addition to the report proposed by default Google.
2 / You can create a new profile and add a tracking code only for the mobile version. Traffic of the mobile version will then be isolated in the reports related to this profile.
Mobile sitmap is disappearing
Now, with the advent of smartphones and tablets, we can say that there is now only one index. When you go to Google from your iPhone, the results are from the same index that when you make a request from a computer. I've talked about it after going to SMX conference in Paris in June 2011. To send its results, Google's algorithm takes into account the terminal from which the request is made. That means that the priority for you is that your web version is well referenced because the user will be returned automatically to your mobile version.
Oldest WM users probably remember that, at one time, their mobile version was better referenced than their web version. It was probably Google merged both index (mobile and web). Users affected were those who had submitted their Google Webmaster Tools sitemap mobile. It is no longer much of interest today to submit that sitemap. Also, so you do not disturb the Google index pages with your mobile version, we do no longer provide in the back office the sitemap mobile url.
Asynchronous tracking code
Historically, Google Analytics tracking code provided was synchronous. To make a long story short, the synchronous code blocked the view in the browser of any part of the source code located below it, and so it did not get a response from Google. Google's servers are fast and powerful, but nevertheless, in order not to slow down the display of your pages, Google advocated placing the synchronous tracking code at the end of the pages. That's how we did it for years.
Then, the tracking code Google has evolved. It is now asynchronous, ie to communicate with Google's servers once the whole web page is loaded in the browser. Communication between the tracking code and Google's servers are therefore more likely to not disrupt the display of your pages.
Advocating for the positioning of asynchronous tracking code on a page is also changing. It is recommended to place asynchronous code at the beginning of the page, in the <head> tag. This allows to obtain more precise information about the bounce rate of your site pages.
The bounce rate is a very interesting information. It shows the percentage of people who, as soon as they arrive on a page, leave within 5 seconds by clicking the back button on their browser. If the bounce rate of a page is high (over 50%), this means that the page is not relevant in the eyes of those who land on it. Then you can work out the way your visitor used, find out what's not working and correct it.
We close this parenthesis on the bounce rate to return to the position of the asynchronous tracking code on the page. When google provided anasynchronous code, we hesitated to move it to the top of the page. First because at the time, Google was making available in Google Analytics both code: synchronous and asynchronous code. Then, also because the majority of WMaker users had a synchronous code on their site.
Subsequently, Google has finally abandoned the synchronous code, so that when you generate a tracking code in your Google Analytics interface, you have no choice but to use an asynchronous code. How to recognize it? Just check and identify the attribute ga.async = true. If this instruction is in your tracking code, then it's asynchronous code.
A quick query on our database told us that a small minority of users still have a synchronous code on their pages. The majority of you have updated your tracking code and use an asynchronous code. So we laced the Google Analytics tracking code in the <head> tag.
I would advise to the last ones who still use the synchronous code to choose the asynchronous code, in order to avoid slow performance display their pages.
We close this parenthesis on the bounce rate to return to the position of the asynchronous tracking code on the page. When google provided anasynchronous code, we hesitated to move it to the top of the page. First because at the time, Google was making available in Google Analytics both code: synchronous and asynchronous code. Then, also because the majority of WMaker users had a synchronous code on their site.
Subsequently, Google has finally abandoned the synchronous code, so that when you generate a tracking code in your Google Analytics interface, you have no choice but to use an asynchronous code. How to recognize it? Just check and identify the attribute ga.async = true. If this instruction is in your tracking code, then it's asynchronous code.
A quick query on our database told us that a small minority of users still have a synchronous code on their pages. The majority of you have updated your tracking code and use an asynchronous code. So we laced the Google Analytics tracking code in the <head> tag.
I would advise to the last ones who still use the synchronous code to choose the asynchronous code, in order to avoid slow performance display their pages.