Welcome to the Q&A Forum

Daniel is making all the right points.  One important thing to remember that conceptually FB clicks and GA visits are calculated differently.  For FB, a click is a click.  It's going through their system so it's easy for them to accurately track clicks.  On the GA side, a visit is contingent on a user having JS/cookies enabled.  Although almost most devices will meet that requirement, GA also has to be told what source they came from.  FB ads (and other ad networks) will commonly use redirects because it's their method of tracking clicks before sending the user to the destination.  These redirects might cause issues because it may confuse the referrer being passed.  That's why building GA campaign tagged URLs will help alleviate that.

Although web hosting location is one factor that the search engines will look at for localisation, they will also look at domain registration contact info, published contact address on your website and other signals that may provide a clue of 'where' you do business. I had a Canadian client a while ago that intended to do business primarily in the US. Despite the fact that their site was hosted on a US machine, the site was suspiciously ranking low for some key phrases despite their good optimization efforts. After further review everything about their business (domain contact info, business address) would lead you to think that they do business in Canada, not the US (They showed up page 1 for Google.ca searches).  It wasn't until we went into Google Webmaster Tools and set the geotargeting to the United States that we saw their key search phrases jump up into page 1 for Google.com searches.

My opinion... although server location is a factor, I've seen other factors have a bigger weight.

Looks like your GA code is running when people are viewing the Google cache of your page.  Do a search for anything that you rank for and click on the 'Cached' link.  When viewing the cached page you'll notice that the query string parameters are similar to the first example you gave.

You can set a filter to Include ONLY traffic coming from your domain OR Exclude traffic from specific domains like webcache.googleusercontent.com.

You can also add a setDomainName() method to your GA tracking code and set it to 'domain.com' except use your actual domain.  This will allow GA to ONLY run when the domain in browser contains what you set in setDomainName.  GA is a 1st party cookie solution so it won't run on domains that conflict with what you set in setDomainName.

This is an expected 'oddity' of the site: operator. Here is a video of Matt Cutts explaining the imprecise nature of the site: operator.

watch?v=2ix3mHeL7hg

When the ReachLocal site loads the frame actually holding the site content, it will actually treat the parent window as the referral.  If you look at the _utm.gif hit going to the Google Analytics servers, look at the utmr parameter (the referring URL that GA will recognize) it has a value of "http://namgrass.rtrk.co.uk/".  Also, the utmz source/medium is set to "namgrass.rtrk.co.uk/referral" which is what you'll see in the Google Analytics reports.

So, what's happening is that the framed ReachLocal site IS getting traffic.  It could be organic, email, PPC.... anything but we wouldn't know because the frames are dropping the real attribution and forcing a referral from namgrass.rtrk.co.uk. So, although the site may not be ranked, remember that it could get traffic through other means.

You can use tools like Fiddler or a Firefox extension called FireBug to monitor the Google Analytics _utm.gif hits and see what information is passed to the GA servers.

bit.ly and many other link shortener services will perform a 301 redirect to the destination page and will pass the referrer (if available).  If somebody clicks your bit.ly link from their twitter feed on the twitter.com web site, then twitter.com/referrer will be the source/medium.  But if somebody clicks a bit.ly link from a non-browser interface (i.e. desktop Tweetdeck or Outlook Express email) then no referrer info is passed in the headers, resulting in a 'direct/(none)' for the source/medium since GA couldn't identify a specific source.

As lhutt mentioned, you can use GA campaign tagging to specify campaign information. You can use Google's URL Builder to create campaign tagged URLs for GA:

http://www.google.com/support/analytics/bin/answer.py?answer=55578

As Ryan mentioned, this would be a workable option.  I've seen 1 second be sufficient time for the _utm.gif hits to complete communication with the GA/GWO servers. Another option would be to track the conversion upon click of the link or form submission, but rather than get to the details of that I'd say just stick with your meta refresh option

Google will not treat to similar-yet-translated content as duplicate content. Here's a video where Matt Cutts clarifies:

http://www.youtube.com/watch?v=XNnMaYViYHc

Though it's technically possible for a german user to find your swiss site via a Google search (or vice versa) you can help instruct Google on the geotargeting preferences of those sites by either using specific geotargeted TLDs for each site, or by setting the Geotargeting settings appropriate in Google Webmaster Tools for each site.

Some of the metrics re: Site Speed is available via the Google Analytics Export API.  You can use some commonly used Excel plugins that are great at pulling in GA API data into your Excel doc to manage your data over time.  Excellent Analytics is free (http://excellentanalytics.com/) and Next Analytics (http://excel.nextanalytics.com/) has a free trial but the license costs money (but it's a great product)

If you associate your website with a FB app account, you can post updates via the FB Graph API that will appear on the news feeds of users who have 'liked' a page on your website. Read the 'Publishing' section on the Open Graph documentation: https://developers.facebook.com/docs/opengraph/

This gives you both social SEO signals for your website AND engagement with readers via Facebook.

You pages are setting 'nosnippet' in the META robots tag, meaning the search engines are instructed to not display a description for the page and to suppress the cache link. Remove that setting and you should see a difference after Google updates your page in the index.

Remember that Google will crawl and index your site based on its own schedule so you will have to be a little patient.

You can use the canonical URL tag (i.e. rel="canonical") to instruct the search engines what the primary URL should be and avoid any duplicate content issues. You can also setup query parameter exclusions with the different search engine webmaster tools to instruct them to ignore these affiliate query parameters.

Regarding link juice, there is a video from Matt Cutts that suggests that there may a fractional loss of link juice with Canonical URL references, but nothing to be worried about.  So to answer your question, you will still have link juice passed when using the canonical URL tag.

watch?v=zW5UL3lzBOA

Set up an Advanced Segment using a metric of 'Goalx Completions' (where x is the goal slot) and a condition of greater than 0.  Apply the segment and you'll be able to view your GA reports focused on this segment and see what countries they came from, keywords typed, etc.

This is actually a fairly crude attempt of loading AJAX content.  I say 'crude' because it's not quite using Google's documented AJAX protocol using the hashbang (#!).  There was an SEOmoz post about Google's protocol a while back that had some good examples:

http://www.seomoz.org/blog/how-to-allow-google-to-crawl-ajax-content

For this specific website, there actually is a JavaScript redirect involved. The original URL will load, then some JS will do some work and eventually do a document.location.replace() to do the redirect to the URL with the hash.  As far as GoogleBot is concerned it won't necessarily do the redirect and will index the original page.

One thing I want to caution is to again remember that this site is not exactly adhering to Google's recommendations on AJAX content. Coupled with the fact that there is a JS redirect going on I would say that there might be a risk of cloaking.  On the front end, the content looks the same and I would kinda hope that Google would just treat this scenario similar to their hashbang solution because this site is not intending to do some tricky stuff here.  But we can't trust that Google will always give a free pass.

This is a common problem that is still being worked on.  View the status here:

http://www.google.com/analytics/status#rm=1&di=14&ddo=1&hl=en

The name of the subfolder by itself should not make a difference.  Regardless of the subfolder name, if that area is really targeted for UK users then one recommendation is to go into Google Webmaster Tools and set the geographic targeting of that subfolder to 'United Kingdom'. And yes, you can setup GWT profiles by subfolder and apply this setting for just that subfolder.

Bing Webmaster Tools does not have a geographic targeting setting.  One recommendation is to use the following meta tag to define content language/audience on all the UK-specific pages in that subfolder portal:

For Yahoo one additional thing you can do is submit a business listing to Yahoo! Local for another geo-targeting signal.

The framed page is actually loading content from "namgrass-px.rtrk.co.uk" which could have been a dupe issue, but the are using a meta robots "noindex, nofollow" so I wouldn't be concerned since this should not appear in the search engine index.

Because of the framed referral issue, you should expect a 100% correlation between # of visits to ReachLocal page and # of visits in GA referral reports for that site.  So if ReachLocal sends 1000 visits to that page, you'll see about 1000 in GA.

The 'Default URL' field in a Property Settings screen will do a few different things:

• Prefill a setDomainName value for your tracking code if you select tracking for multiple subdomains or domains.  I'm just noting in here, since none of what you described would be a cookie domain issue.
• The Default URL would be would be prepended to the content URI when you are viewing content reports and click the icon to view the page in a new window.

What I'll emphasize is that your Default URL value will have no effect on your data collection. It's simply not used in any data processing.  There are many use cases for having an empty Default URL, for example, if you are doing a hostname injection into your content URIs and you don't need another hostname prepended when you attempt to open a content URI in a new window, like I described in the 2nd option.

Hope this helps.