About the Tracking Code
As mentioned in how google analytics works, Google Analytics uses a very common web analytics technology called page tags to identify visitors, track their actions, and collect the data. Each page on your website that you want to track must be “tagged” with a small snippet of Java-Script. If the tracking code is not on a page, that page will not be tracked.No tracking code, no data. It’s as simple as that.
The following is the GATC JavaScript snippet:
var _gaq = _gaq || [];
_gaq.push([‘_setAccount’, ‘UA-XXXXXX-YY’]);
_gaq.push([‘_trackPageview’]);
(function() {
var ga = document.createElement(‘script’); ga.type = ‘text/javascript’;
ga.async = true; ga.src = (‘https:’ == document.location.protocol ?
var s = document.getElementsByTagName(‘script’)[0];
s.parentNode.insertBefore(ga, s);
})();
This part of the tracking code does all of the work. It starts by creating a queue (named gaq), or list of Google Analytics commands. These commands are also called methods. When you want Google Analytics to do something, you add, or push, a command into the queue.
The standard page tag adds the first two methods to the queue for you. The first method is _set Account (). This method links the data collected from your site to your Google Analytics account using a unique number. The number is found directly after the “UA-”. Once the _set Account () method has been added, the tracking code knows where to send all of the data.
The second method, _track Page view() is the part of the code that collects information about the visitor, stores it in cookies, and sends the data back to Google. This is the true workhorse of Google Analytics.
Remember, this part of the tracking code is a queue of methods. Up to this point, the only thing that has happened is two methods have been added to the queue. The queue has not been processed and no data has been sent to Google Analytics.
Before any code can execute the ga.js file, which contains all of the Google Analytics logic, this code loads that logic into the browser and requests ga.js from a Google server. This file is geo-load-balanced across all of Google’s global data centers. This means the visitor’s browser will connect with the closest data center to reduce the time it takes to retrieve the file. The visitor’s browser caches this file, so it’s possible that it doesn’t even need to load from a Google data center. Once the browser has retrieved the file, the queue of commands begins to execute. Notice the ga.async = true part of the code. This part of the code tells the browser to load the ga.jsfile asynchronously. This means that the browser can load ga.js while it continues to render the page for the visitor. Even if there is a communication issue between the browser and Google’s Analytics servers and Google’s servers stop transmitting ga.js to the browser, the browser will continue to render the page for the visitor.
Not all browsers can load files asynchronously. At the time of this writing, Firefox 3.6 and later are the only browsers that support true asynchronous loading. For browsers that do not support asynchronous loading, the code is optimized to dynamically add the script directly to the Document Object Model (DOM). This more or less creates the asynchronous behavior for browsers that do not support true asynchronous loading.
When it comes time to place the code on your pages, Google suggests that you place the tracking code immediately before the tag of each page. If your website uses a content management system or some type of template engine, you can add the tracking code to template files or another mechanism that automatically generates common HTML elements. This is a fast, effective way to tag all website pages.
Google updates ga.js without notifying users. If you decide to host ga.js on your own servers, make sure you periodically check for updates. Google publishes a ga.js change log at http://troni.me/cUNRvq.
The Mobile Tracking Code
The Google Analytics tracking code relies on JavaScript and cookies to collect visitor data. While some mobile devices support these technologies, like iPhones and Android powered phones, there is a huge ecosystem of mobile devices that do not support either of these technologies. Google Analytics therefore needs a different way to collect data for visitors using a device that does not support cookies and JavaScript. Thus was born the mobile tracking code.
The mobile tracking code collects data at the server level rather than at the browser, or device, level. Because the mobile tracking code collects data at the server level, you must implement it in the language that you used to build your web application. Google provides four mobile tracking libraries to make the process easier: PHP, Java, ASP, and Perl. All of the libraries work in the same basic way. You can download the mobile tracking libraries from the Google Analytics code site at http://troni.me/bULXyd.
Regardless of the language you use to implement mobile tracking, the data collection process is the same. Let’s walk through the mobile tracking process using a PHP example, shown in fig 3.
To track a mobile site built in PHP, you must add a block of PHP code before the tag on all your mobile pages. You must also add a small block of PHP code immediately before the closing tag.
When the server processes the first block of PHP , it creates a URL containing information about the visitor. Then it places the URL that was generated in the first block of code in an HTML IMG tag (fig 3).
The image request is actually a request for the ga.php file. This file takes the requested URL, extracts the data, and sends the data back to the Google Analytics server. This image passes data back to your server, where a request for the __utm.gif image is made. This __utm.gif request is nearly identical to the __utm.gif request that the JavaScript makes.
Examining the first block of PHP code, you’ll notice that you need to add your account number to the top of the block. You’ll also need to change the path to the ga.phpfile to match your website architecture:
<?php
// Copyright 2009 Google Inc. All Rights Reserved.
$GA_ACCOUNT = “MO-XXXXXX-YY“;
$GA_PIXEL = “/ga.php”;
function googleAnalyticsGetImageUrl() {
global $GA_ACCOUNT, $GA_PIXEL;
$url = “”;
$url .= $GA_PIXEL . “?”;
$url .= “utmac=” . $GA_ACCOUNT;
$url .= “&utmn=” . rand(0, 0x7fffffff);
$referer = $_SERVER[“HTTP_REFERER”];
$query = $_SERVER[“QUERY_STRING”];
$path = $_SERVER[“REQUEST_URI”];
if (empty($referer)) {
$referer = “-“;
}
$url .= “&utmr=” . urlencode($referer);
if (!empty($path)) {
$url .= “&utmp=” . urlencode($path);
}
$url .= “&guid=ON”;
return str_replace(“&”, “&”, $url);
}
?>
The second block of PHP code is much simpler. It is simply two lines of PHP code that reference a function in the first block of code:
<?php
$googleAnalyticsImageUrl = googleAnalyticsGetImageUrl();
echo ‘
‘;?>
When both blocks of PHP work, the result is an image tag at the bottom of every page on your mobile website. The resulting HTML looks something like this:
<img src="/ga.php?utmac=MO-XXXXXX-YY&;utmn=669391585&;utmr=-&;
utmp=%2Ftesting%2Fmobile%2Findex.php&;guid=ON” />
It’s important to understand that Google Analytics not only collects mobile data in a different manner, but also processes it differently than data it collects using the standard tracking code. The reason is that Google cannot define certain visitor metrics when tracking a mobile site is because mobile phones don’t support cookies.
Another thing to notice is the account number. It’s in the utmac query-string parameter above. It starts with MO, not UA, as the standard tracking code. This helps Google Analytics identify data coming from a mobile device and send it to a different processing engine. Google Analytics uses a separate processing engine for mobile to deal with session definition. Once it processes the data from a mobile device, Google Analytics places it in the same profile as data it collects using the standard tracking code.
At this time, the mobile GATC can only track page view and event data. It cannot track any specialized data, like custom variables or e-commerce data. The methods to collect these other data types simply do not exist in the mobile tracking code.
If you have a mobile version of your website, it is worth the time to invest in tracking.
App Tracking
In addition to tracking mobile and standard websites, Google Analytics can also track mobile apps. Tracking apps is fundamentally different than tracking websites, because apps function differently than websites. The user experience (how people interact with the app) is completely different, because the device offers different ways to interact. There is no mouse and (potentially) no keyboard. With many devices, people use their finger to interact with the app. This change in how people interact with content leads to new and different types of data.
While Google Analytics has the capability to track apps, it uses the standard web measurement data model. This means it uses page views and visits to measure apps. Both software developer kits (SDKs) also support tracking events in apps. While it’s useful to useful to have app tracking, it can be confusing to force the data into a web metrics paradigm.
App tracking is currently available for iPhone and Android applications. Those interested in tracking apps can download the SDK from the Google code site at http://troni.me/aOnRye.
App tracking has many unique features that are specific to apps and mobile devices. For example, the SDK includes a feature called dispatch. This feature allows the developer to cache, or hold, requests for the __utm.gif image and send multiple requests at the same time. This can help reduce the bandwidth the device uses.
The (Very) Old Tracking Code: urchin.js
For those of you who have been using Google Analytics for a long, long time, you may have noticed that the GATC has changed dramatically. The original version of the Google Analytics tracking code was named urchin.js. While urchin.js is still supported, it is recommended that all users migrate to the current version of the tracking code. The current version of the tracking code will load faster in the visitor’s browser, contains new functionality, and is continuously updated by Google.
When planning a conversion from urchin.js, consider your implementation. Do you use e-commerce tracking? Does your website span multiple domains? Are you tracking Flash or Ajax? All of these things complicate the migration from urchin.js, because they are customization of the tracking code. While I do recommend migrating from urchin.js, I recommend that you take the time to plan your migration carefully.
Understanding Page views
The most important part of the GATC is track Page view (). This method collects visitor data, stores that data in cookies, and sends the data to the Google Analytics server. The track Page view () portion of the GATC is shown in bold in the following code:
var _gaq = _gaq || [];
_gaq.push([‘_setAccount’, ‘UA-XXXXXX-YY’]);
_gaq.push([‘_trackPageview‘]);
(function() {
var ga = document.createElement(‘script’); ga.type = ‘text/javascript’;
ga.async = true; ga.src = (‘https:’ == document.location.protocol ?
var s = document.getElementsByTagName(‘script’)[0];
s.parentNode.insertBefore(ga, s);
})();
Every time _track Page view () executes, a page view is created by sending the data to Google Analytics. Remember, each page view includes many, many dimensions, like the visitor’s IP address, city, country, region, etc. The actual page the visitor was looking at is captured in a dimension called page. You can use the page dimension to create many of the reports in the Content section of Google Analytics. (Fig 4). Shows some sample data from the Top Content report.
During the data collection process, _track Page view () copies the information from the location bar of the visitor’s browser. It modifies the value by removing the domain name and domain extension. The only things left are the directories, file name, and query string parameters. This becomes the Request URI field or page dimension, and it is created during data processing.
That’s the default behavior of _track Page view (). You can override this behavior and specify how _track Page view () names a page view by passing a value to _track Page view (). For example, to change the way the page view for /index.php appears in Google Analytics, modify track Page view () on the /index.php page as follows:
gaq.push([‘_trackPageview’, ‘/index page’]);
This modification forces track Page view () to name the page view /index page rather than /index.php. The deeper effect of this change is that the value for the Request URI field and the page dimension is not /index.php, but index page. This will have an impact on other configuration settings, like goals and funnels, which we’ll discuss in another article.
You can execute track Page view () anywhere you can execute JavaScript. So, if you place track Page view () to the on click attribute of an image, a page view will be created in Google Analytics when a visitor clicks on the image. How will the page view appear in Google Analytics? By default, it will use the request URI value. However, if you pass it a value, you can name the click anything you want.
You can use this technique to track visitor clicks, actions, and other browser events. For example, to track clicks on links to other websites (called outbound links), simply add the _track Page view () method to the on click attribute of the appropriate anchor tags. Don’t forget to pass track Page view () a value so the visitor click is identifiable.
Every time track Page view () executes, a new page view is created in Google Analytics. By using this technique, you can greatly distort the actual number of page views for a website, which is bad! You can use a feature in Google Analytics called Event Tracking to track visitor actions and, in fact, this feature is more appropriate for tracking clicks and actions.
seoexpertknowledge 
