Google's explanations regarding: landing page tracking code, visitor browser preferences, unable to load code and redirects in landing pages.
Landing Page Tracking Code
"If the landing page for your ads is not being tracked, your campaign information will not be passed to Analytics. Please ensure that you are tracking all landing pages for your AdWords ads."
Web analytics systems know how you got to a page by asking your browser what page you were on previously. Your browser has a built-in capability to report this. This is known as the 'referrer field' and it has been around on the web since Day One. The referrer field contains the full URL of the page containing the link you clicked to get to the current page.
On the other hand, the browser can only report the referrer field for the page it is actually on. There's no way to ask the browser for the referrer field for something three pages back. Therefore the only way to tell where someone came from is at the point of entry. This means you have to get the referrer field for the first page in your site that they land on. If you don't get it then, you can never tell where they came from. You have to ensure all landing pages contain tracking, and that tracking needs to get the referrer field.
To many of us, this seems self-evident. However, the fact that Google needs to mention it suggests many people are not aware of this. It suggests that at least some people creating online marketing material may not be aware of the site's tracking system. I've seen this happen myself when outside agencies are producing the online material, especially if they're hosting it themselves. You need to ensure that everyone who creates pages for the site is fully briefed on the tracking requirements.
If you're not tracking landing pages fully, your own numbers will be under AdWords. The more successful the campaign, the greater the discrepancy.
Another factor that can create the same problem is that some users can prevent their browser from providing the referrer field when asked for it. Some anti-spyware products do this, and it is an option in a few browsers. However, in my experience the percentage of people doing so is rarely more than one percent. It largely depends on the audience; if you run a conspiracy theory site for paranoid techies, it could be higher.
Visitor Browser Preferences
"Visitors entering through AdWords may have JavaScript, cookies, or images turned off. If this is the case, Google Analytics won't be able to report these visitors, but they will be reported through AdWords. In order for Google Analytics to record a visit, the visitor must have JavaScript, images, and cookies enabled for your website."
Most page-based tracking systems work in the same way-- they use some JavaScript code embedded in the page to call an image from the tracking server. That image call includes information about the visitor, such as the page they are on, the page they just came from, the type of browser and so on. The tracking server or the JavaScript will set a cookie so that the system can identify this person as they move from page to page. If any one of these elements is disabled on the browser, the visit won't be counted. By contrast, Google AdWords is recording activity within the Google servers, so there is no way the person can prevent the AdWord click being recorded.
This can, and probably does, contribute to some discrepancy between AdWords and your analytics system. However, I have personally conducted extensive research into how common this type of blocking is. Among people using Linux-based browsers, it's around 10 percent. Approximately 0.5 percent of PC users and less than 0.25 percent of Mac users also block tracking in this way. In total, the discrepancy in numbers between your system and AdWords as a result of browser preferences is unlikely to exceed one percent.
Unable to Load Code
"Clicks reported on Google AdWords but not on Google Analytics may be the result of obstruction between the Google AdWords click event and the ability to load the tracking code on the landing page. If this is the case, ensure that your web hosting servers are functioning properly, the page is loading for all possible users and IPs, and the tracking code is installed correctly on your web pages."
This issue was first brought to my attention some years ago by Matthew Tod, one of the UK's premier web analysts, who runs the consultancy Logan Tod. Where, and how, you place the JavaScript component of the tracking code in the HTML of the page can affect the accuracy. Things take time on the internet, and it is possible for people to click away from a page before the analytics system has a chance to track them. If the code is called from the tracking server via a <LINK> tag in document head, as is the case with Google Analytics, that code may not have arrived before the visitor has clicked and moved on.
Alternatively, the sequence of "image call -- server response -- cookie setting" may not have completed before the visitor leaves the page. It can depend on the location of the visitor and the tracking server. Tracking servers in the northern hemisphere can have problems with visitors in Australia or parts of Asia. This very much depends on the number of hops the signals must go through and the speed and quality of the networks involved. I have seen situations where additional tracking servers had to be placed closer to the user-base to handle this.
Other problems can occur if the code does not run correctly on some browsers. In theory all JavaScript commands terminate with a semi-colon (;). This means you should be able to write multiple commands on the same line. In practice a few browsers ignore semi-colons and treat line-breaks as command terminators. If the code is written without carriage returns, a few browsers won't run it.
While these situations will be the cause of discrepancies between AdWords and other systems, the number of times such things will occur is fairly low. As with browser preferences, the variation from such cases is extremely unlikely to exceed one percent.
Redirects in Landing Pages
"Redirects in landing pages can often obstruct the Google Analytics code from launching and properly identifying the visit as coming from a paid search campaign. For example, if your ad leads to http://www.mydomain.com/index.html, but you've created a 301, 302, or JavaScript redirect from that URL to http://www.mydomain.com/page2.html, the campaign information that was originally appended to the landing page will be lost upon redirection."
This is not necessarily true, although the reason depends on the type of redirect. 30x redirects are produced by the server. When a specific page is requested, the server sends a message back to the browser saying "page not here, get it at XYZ." The browser has to then try to get the page from the new location. RFC 2616, which defines HTTP 1.1, doesn't specifically state how referrers should or should not be handled by 30x redirects. However, since the referrer is the page that generated the original request, the fact the server redirected does not mean the page from which the click originated has changed. Browsers will maintain the originating referrer during a redirect. Provided the page the visitor lands on contains tracking code, you will still accurately attribute that visitor to the AdWord.
A JavaScript redirect happens once the page has been loaded. Once loaded, the page runs some JavaScript which calls for a new page. This process may be seen by the visitor or not, depending on how the code is written. Provided the first page contains tracking code, and that code gets a chance to run, you will still accurately detect the visit.
In both the above cases, you need to ensure the tracking code runs correctly. It should be obvious that if your code doesn't run, your numbers will be off. Beyond that, there's no valid reason why redirection should cause differences between your analytics package and AdWords.