Hostname injection is when you add the hostname value to the beginning of the content URI.  Instead of seeing just '/index.html' in the content URI reports, you would see 'www.mysite.com/index.html'.  This is helpful when you are tracking across multiple subdomains and you need to tell the difference between files on your different subdomains.  You would see the following, as an example:

www.mysite.com/index.html
blog.mysite.com/index.html
store.mysite.com/index.html

3 different pages on different subdomains.  Without adding the hostname, they would have rolled up into a single '/index.html' line and it would be difficult to know which subdomains they are from.

More info on setting up the filter can be found here:

https://groups.google.com/a/googleproductforums.com/forum/#!category-topic/analytics/discuss-issues-related-to-your-accounts-reports-and-data/wEoiR4kQStQ

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.

Campaign tagging is always the failsafe method to essentially 'hardcode' the campaign attribution into your links.  If the link is shared using some widget you have on your site and you have control over the code, just have these share links use campaign tagged URLs.

If somebody visits one of your page and just decides to copy and paste the URL from their browser address bar, then you'll get some directs or misc. web-based referrers.  Not too many ways to combat that. You can create some JavaScript that 'could' catch some of the web-based referrers and force some campaign attribution, but it won't catch the non-browser based clicks so it's not a perfect solution anyway.

If you are tagging those bit.ly links AND still seeing 'direct' visits from those links then that would suggest a tegging error?  Is that what you're seeing? If so, can you include an example bit.ly link to review?

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

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

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

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

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.